[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 3/5] raw_bsd: Don't advertise flags not supporte
Re: [Qemu-block] [PATCH 3/5] raw_bsd: Don't advertise flags not supported by protocol layer
Fri, 8 Jul 2016 13:05:19 +0200
Am 21.06.2016 um 01:39 hat Eric Blake geschrieben:
> The raw format layer supports all flags via passthrough - but
> it only makes sense to pass through flags that the lower layer
> actually supports.
> Thanks to the previous patch, the raw format layer now attempts
> to fragment writes at the max_transfer limit it inherits from
> the NBD protocol layer, recently set to 32m. An attempt to do
> 'w -f 0 40m' to an NBD server that lacks FUA thus changed from
> flushing once (after NBD fragmented a single 40m write itself)
> to instead flushing twice (the format layer sees BDRV_REQ_FUA
> in supported_write_flags, so it sends the flag on to both
> fragments, and then the block layer emulates FUA by flushing
> for both the 32m and 8m fragments at the protocol layer).
> This patch fixes the performance regression (now that the
> format layer no longer advertises a flag not present at the
> protocol layer, the flush to emulate FUA is deferred to the
> last fragment).
> Note that 'w -f -z 0 40m' does not currently exhibit the same
> problem, because there, the fragmentation does not occur until
> at the NBD layer (the raw layer has .bdrv_co_pwrite_zeroes, and
> the NBD layer doesn't advertise max_pwrite_zeroes to constrain
> things at the raw layer) - but that problem is latent and would
> have the same problem with too many flushes without this patch
> once the NBD layer implements support for using the new
> NBD_CMD_WRITE_ZEROES and sets max_pwrite_zeroes to the same 32m
> limit as recommended by the NBD protocol.
> Signed-off-by: Eric Blake <address@hidden>
Should this be moved before patch 2 so that we never get a regression in
the first place?
- Re: [Qemu-block] [PATCH 3/5] raw_bsd: Don't advertise flags not supported by protocol layer,
Kevin Wolf <=