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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
