[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, 10 Nov 2010 16:07:18 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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?


reply via email to

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