[Libguestfs] [nbdkit PATCH] sh: Prefer dd bs=1 over iflag=count_bytes

Eric Blake eblake at redhat.com
Tue Aug 18 15:11:11 UTC 2020


On 8/18/20 9:58 AM, Richard W.M. Jones wrote:
> On Mon, Aug 17, 2020 at 11:35:39AM -0500, Eric Blake wrote:
>> While iflag=count_bytes combined with bs > 1 allows for more efficient
>> operation, it is a feature of GNU dd, and not present on other
>> implementations such as BSD.  Sticking to just POSIX features makes
>> things more portable.
> 
> I'm not very convinced by this.  Maybe we should persuade
> the BSD folk to implement this useful feature instead?

Wouldn't hurt to try.

> 
> As one example:
> 
>> diff --git a/docs/nbdkit-loop.pod b/docs/nbdkit-loop.pod
>> index 055b5750..b21c2212 100644
>> --- a/docs/nbdkit-loop.pod
>> +++ b/docs/nbdkit-loop.pod
>> @@ -120,7 +120,7 @@ creates a disk which contains a bad sector:
>>                echo EIO Bad block >&2
>>                exit 1
>>            else
>> -             dd if=/dev/zero count=$3 iflag=count_bytes
>> +             dd bs=1 if=/dev/zero count=$3
>>            fi ;;
>>        *) exit 2 ;;
>>    esac
> 
> this change could be a killer for performance since the suggested size
> of the disk is 64M.

Another thing we could do: I've got a proposal out to let plugins 
advertise block size preferences.  Once that is in place, a shell script 
that uses dd could advertise minimum block size of 512, leave bs=512 
(the default), and compute count/skip/seek by $(($3 / 512)) when the 
script must be portable to BSD dd.  Performance will then not be 
penalized, at the expense that the user would have to use the 
--filter=blocksize to get sub-block read/writes.

But yeah, given the definite slowdown to the testsuite for 
heavy-hitters, I'm thinking the best we can do without a minimum block 
size advertisement is documentation of why we prefer GNU dd features, 
and the slower fallback possible on BSD.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




More information about the Libguestfs mailing list