bug#7362: dd strangeness

[Pádraig Brady]

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.