filling /dev/null

[Bennett Todd -- gaj]

In article <1617 at contex.UUCP> frank at contex.UUCP (Frank Perdicaro) writes:
>While testing a few things on a 4D35, I decided to see how the added memory
>bandwith would effect kernel data movement activities.  Just for a lark, 
>I tried
>   dd if=/dev/zero of=/dev/null bs=256k count=256k
>All went well for a while.  Then, I got a EFBIG exception from dd.  
>Somehow this is both not surprising, and not appropriate.  Considering
>the special way /dev/null is handled by the kernel, should it not
>be exempt from this type of accounting?  Anybody care to comment?
>
>It really seems odd that one can 'fill' /dev/null!

It does indeed seem odd. I tried it. Here is the output I got (4D/320VXG,
Irix 3.3.1):

	$ dd if=/dev/zero of=/dev/null bs=256k count=256k
	dd: read error: File too large
	8192+0 records in
	8192+0 records out
	$ 

Inasmuch as it says "read error" I imagine the problem isn't filling up
/dev/null, it is emptying /dev/zero (not much improvement:-).

I find the offset at which it croaked interesting -- 8K * 256K == 2G.
Consider the offset argument to lseek(2)....

/dev/zero might not actually run out of zeros, but the OS interface through
which you are reading *thinks* it is a file -- and so it is keeping track
of the offset internally, in case you should want to seek on it. It seems to
be using a signed 32 bit integer.

-Bennett
bet at orion.mc.duke.edu