Hi Jim, I'm actually not concerned with the SIGPIPE and expect it. What concerns me is that the final counts reported by *dd* are wrong. It should report 1024 records copied, but instead reports a seemingly random and variable amount.
Why is dd closing its stdin earlier than I asked it to? Why is dd transfering a random amount of data? --Robb On Sun, 22 Feb 2009 19:37:34 +0100 Jim Meyering <j...@meyering.net> wrote: > Robb Matzke wrote: > > I'm seeing some strange behavior with dd. The first two commands work and > > report the expected number of records transferred (1024): > > > > dd if=/dev/zero bs=1MB count=1024 of=/dev/null > > dd bs=1MB count=1024 </dev/zero >/dev/null > > > > But these report a random number of records, usually somewhere around 200, > > but as few as 0 or as many as 1005: > > > > cat /dev/zero |dd bs=1MB count=1024 of=/dev/null > > cat /dev/null |dd bs=1MB count=1024 >/dev/null > > > > An strace on dd shows that the last read/write pair both succeed and then dd > > inexplicably closes both files. None of the reads return zero or failure. > > An strace on cat shows that its last write to stdout gets a sigpipe, so it > > really is trying to send the data to dd and it's dd that's closing the pipe. > > That's expected and in fact required. > You're telling dd to exit after reading 1024*1MB. > Once dd exits, it closes its side of the pipe, but cat is still writing > to the other end. Writing to a closed pipe provokes a SIGPIPE, by default. > How much cat actually writes before it's killed by the > SIGPIPE depends on kernel buffering, hence the variability. > > > Replacing /dev/null with a real file exhibits the behavior one would expect. > > Substituting some other I/O-counting command for dd works fine. -- Robb Matzke L-159 | Ph: 812-967-6325 | I/O, I/O, it's off to disk we go, Lawrence Livermore | Fax: 812-967-6326 | A petabyte to read or write, National Laboratory | Hrs: 3am-11am PDT | I/O, I/O.
