[nylug-talk] questions about /dev/null

[Peter C. Norton]

On Mon, Nov 05, 2007 at 02:43:48PM -0500, Alex Pilosov wrote:
> On Mon, 5 Nov 2007, Peter C. Norton wrote:
> 
> > Run again, this time with ">", which still gives the process a file
> > descriptor that leads to /dev/null:
> <snip>
> 
> > So that's the slowdown for a simple, simple, simple program like "cat"
> > to read buffere stdin and to throw it out. A >50% slowdown. The kernel
> > or the C library simply has to stat() the file being written to, and see
> > if it matches the st_rdev of /dev/null on the current system (yes, it's
> > not codified anywhere that these device numbers must be uniform across
> > platforms or releases).
> No, you are so very wrong. 
> 
> The difference is because of unix pipe()s having 4kb buffer. In other 
> words, when dd is reading 1Mbyte blocks, you have 0 context switches. In 
> case of dd | cat, you have two context switches every 4kb. Context 
> switches are not cheap. 

Yes, you're right, I'm glossing over the pipe size as part of the
context switch overhead and the overhead of what I believe to be a
shortcut to /dev/null behavior on various platforms eg on solaris I
believe I've seen times that make it appear that dd doesn't appear to
even bother to read the file, it just returned. However, I can't
reproduce that behavior now, so now I have to attribute it to sleep
deprivation memories.

It seems on linux this isn't the case, and I stand corrected.

If we do this:

spacey at spacey:~$  sudo dd if=/dev/md0  bs=4k count=10000 | perl -ne '0;'
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 0.712025 seconds, 57.5 MB/s

Then we get limited by pipe speed.

Thanks for the correction Alex,

-Peter


-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.