Messages in this thread | | | From | Paul Gortmaker <> | Subject | Re: Dumping /dev/zero to the console | Date | 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.
| |