bug#7362: dd strangeness

[Pádraig Brady]

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?

cheers,
Pádraig