On 10/11/10 16:07, Pádraig Brady wrote: > On 10/11/10 15:29, Pádraig Brady wrote: >> On 10/11/10 10:22, Lucia Rotger wrote: >>> I see this behavior in Solaris, Linux and BSD dd: if I send a big enough >>> file they all read it short at the end of the stream. >>> >>> This works as expected: >>> >>> # cat /dev/zero | dd bs=512 count=293601280 | wc >>> >>> I get the expected results, dd reads exactly 293601280 blocks and wc >>> sees 150323855360 characters, 140 GB >>> >>> Whereas substituting cat for zfs send doesn't: >>> >>> # zfs send <backup> | dd bs=512 count=293601280 | wc >> >> different write sizes to the pipe mean >> in the later case, dd will get short reads. >> IMHO dd is doing the wrong/most surprising thing here, >> but it can't be changed for compatibility reasons. >> You can get coreutils dd to do what you want with: >> >> dd iflag=fullblock > > BTW here are my notes on some possible changes in this area: > > `dd conv=sync` seems to do the wrong thing with pipes. > I.E. it pads out short reads. Why would one ever want that? > > Should sync for pipes imply fullblock? > > Should sync for pipes without fullblock give a warning? > > Should specifying a count (and bs I suppose) without fullblock > when reading from pipes give a warning?
This looks like another candidate to auto enable fullblock for. https://bugzilla.redhat.com/show_bug.cgi?id=614605 I.E. oflag=direct cheers, Pádraig.
