[Libguestfs] [PATCH 9/9] filters: Move rdelay/wdelay from file plugin to new delay filter.

[Eric Blake]

On 01/18/2018 02:47 AM, Richard W.M. Jones wrote:
> On Wed, Jan 17, 2018 at 04:38:04PM -0600, Eric Blake wrote:
>>> +/* Zero data. */
>>> +static int
>>> +delay_zero (struct nbdkit_next *next, void *nxdata,
>>> +            void *handle, uint32_t count, uint64_t offset, int may_trim)
>>> +{
>>> +  write_delay ();
>>> +  return next->zero (nxdata, count, offset, may_trim);
>>
>> If next->zero() fails with EOPNOTSUPP, that means we will delay once in
>> trying the underlying command, and again for each iteration of the
>> fallback loop as it calls delay_pwrite().  Is that okay, or do we want
>> to reproduce some fallback logic here and directly call next->pwrite on
>> EOPNOTSUPP so as to only have a single write delay in that case?
> 
> Good point.  How about this, it seems simpler:
> 
>   static int
>   delay_zero (struct nbdkit_next *next, void *nxdata,
>               void *handle, uint32_t count, uint64_t offset, int may_trim)
>   {
>     int r = next->zero (nxdata, count, offset, may_trim);
> 
>     if (r != -1)
>       write_delay ();

It changes the semantics from an up-front delay to a delay only on
success (failures are reported immediately).  In fact, there may be
reasons to make it configurable on whether you want front- or
back-loaded delays, as a workflow where errors are reported instantly is
different from a workflow where everything is delayed.

But if we document that the plugin backend will never let EOPNOTSUPP
escape, and that filters must not fail with EOPNOTSUPP (ie. the fallback
to write can only be done by the plugin), then keeping the unconditional
up-front delay should be fine without doubling up when a fallback to
write is needed.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180118/01f95eda/attachment.sig>