[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7362: dd strangeness

From: Pádraig Brady
Subject: bug#7362: dd strangeness
Date: Wed, 02 Feb 2011 13:23:46 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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.
I.E. oflag=direct


reply via email to

[Prev in Thread] Current Thread [Next in Thread]