Displaying 3 results from an estimated 3 matches for "ac3f294a".
2018 Jan 18
1
Re: [PATCH 9/9] filters: Move rdelay/wdelay from file plugin to new delay filter.
On Wed, Jan 17, 2018 at 08:01:35PM -0600, Eric Blake wrote:
> Actually, thinking about this more:
>
> When I added zero support, I documented in commit ac3f294a that for the
> file plugin, wdelay is indeed doubled on systems lacking efficient zero
> support. But the fallback for handling EOPNOTSUPP is currently done at
> the plugins.c level (ie. it is part of next->zero()) - so a filter
> should never see a plugin returning EOPNOTSUPP. Or...
2018 Jan 17
4
Re: [PATCH 9/9] filters: Move rdelay/wdelay from file plugin to new delay filter.
On 01/17/2018 02:53 PM, Richard W.M. Jones wrote:
> Previously the file plugin supported ‘rdelay’ and ‘wdelay’ parameters
> for injecting delays (for testing) into read and write requests. This
> moves the functionality to a new delay filter so that it can be used
> with any plugin.
> ---
> +/* Write data. */
> +static int
> +delay_pwrite (struct nbdkit_next *next, void
2018 Jan 18
0
Re: [PATCH 9/9] filters: Move rdelay/wdelay from file plugin to new delay filter.
...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?
Actually, thinking about this more:
When I added zero support, I documented in commit ac3f294a that for the
file plugin, wdelay is indeed doubled on systems lacking efficient zero
support. But the fallback for handling EOPNOTSUPP is currently done at
the plugins.c level (ie. it is part of next->zero()) - so a filter
should never see a plugin returning EOPNOTSUPP. Or put another way,
you...