frank@contex.UUCP (Frank Perdicaro) (01/22/91)
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! -- Frank E Perdicaro, Systems Admin, etc. Xyvision Design Systems LEGALIZE Guns, drugs and cash...today. 101 Edgewater Drive inhouse: frank@bugs Wakefield MA outhouse: contex!frank@uunet.uu.net 018801285
bet@george.mc.duke.edu (Bennett Todd -- gaj) (01/24/91)
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