Re: Dumping /dev/zero to the console

Paul Gortmaker (gpg109@rsphy6.anu.edu.au)
Tue, 23 Jul 1996 00:23:55 +1000 (EST)


-- From "Andrew E. Mileski " at Jul 22, 96 01:52:27 am

> > >> On linux console, even as a non-priv user, do a:
> > >>
> > >> % dd if=/dev/zero bs=1024k
> > >
>
> For what it's worth, this has absolutely no effect on my machine when
> using a block size of 1024 (not 1024k). I let it run for quite a while
> (forgot it was running), and stopped it after about 90Gb.

Of course. That is why I said 1024k and not 1024. There is a big
difference. Or do you consider a factor of approx 1000 insignificant?

Try using a fairly large block, but not so large as to push your machine
into swap activity, or you won't see anything exciting. The bigger
the better, but even 1MB will do. On one console, do a:

% date ; sleep 10 ; date

and then quickly switch to another VC (in less than 10 sec) and launch

% date ; dd if=/dev/zero bs=8192k count=1 ; date

if you have 8MB of RAM avail. without swapping; othrwise use 2048 or 4096.
Now switch back and wait (and wait, and wait) for the second "date"
to appear on the screen which should happen shortly after the 10 seconds
have elapsed. But it won't appear until the write(1, buf, 8*1024*1024)
call finishes, or at least it doesn't here. I also tested it on a virgin
RedHat 3.03 box with 2.08 as well, just to make sure I wasn't going nuts.
On that machine (486-33, 8MB), with a 4800k block (the largest I can use
without touching swap), I see this:

-----------------------------------------console 1-------------
[paul@ratbag paul]$ date ; sleep 10 ; date
Mon Jul 22 23:50:34 EST 1996
Mon Jul 22 23:51:40 EST 1996
[paul@ratbag paul]$
-----------------------------------------console 2-------------
[paul@ratbag paul]$ date ; dd if=/dev/zero bs=4800k count=1 ; date
Mon Jul 22 23:50:35 EST 1996
1+0 records in
1+0 records out
Mon Jul 22 23:51:40 EST 1996
[paul@ratbag paul]$
---------------------------------------------------------------

Hrmm, that sure was a long 10 seconds before the second date command got
scheduled for a slice of CPU. As you can see it didn't get scheduled
until 1:05 later, exactly when the write(1, ...) that dd was doing finished.
In fact nothing appears to get scheduled during that period. Not good.

Paul.