Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!decwrl!mcnc!duke!george.mc.duke.edu!bet
From: bet@george.mc.duke.edu (Bennett Todd -- gaj)
Newsgroups: comp.sys.sgi
Subject: Re: filling /dev/null
Keywords: EFBIG
Message-ID: <21906@duke.cs.duke.edu>
Date: 23 Jan 91 19:45:22 GMT
References: <1617@contex.UUCP>
Sender: news@duke.cs.duke.edu
Reply-To: bet@orion.mc.duke.edu
Organization: Duke University Medical Center, Durham, NC
Lines: 34
Nntp-Posting-Host: george.mc.duke.edu

In article <1617@contex.UUCP> frank@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@orion.mc.duke.edu