[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] nbd/server: Honor FUA request on NBD_CMD_TRIM

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH] nbd/server: Honor FUA request on NBD_CMD_TRIM
Date: Thu, 8 Mar 2018 08:45:20 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/08/2018 12:50 AM, Paolo Bonzini wrote:

The NBD spec states that since trim requests can affect disk contents,
then they should allow for FUA semantics just like writes for ensuring
the disk has settled before returning.  As bdrv_[co_]pdiscard() does
not (yet?) support a flags argument, we can't pass FUA down the block
layer stack, and must therefore emulate it with a flush at the NBD

TRIM requests should not need FUA since they're just advisory.  On
the other hand, WRITE ZEROES requests need to support FUA.

It looks like qemu's NBD implementation properly supports FUA on WRITE ZEROES requests. The block layer in bdrv_co_do_pwrite_zeroes checks for FUA support for both an actual zero request to the driver, as well as any fallback write requests, and does a followup flush if any driver request did not support BDRV_REQ_FUA. Even when BDRV_REQ_MAY_UNMAP is passed through to the driver and allows the zeroes to be written by a trim, then either that trim must also honor FUA semantics (block/nbd{,-client}.c does this), or the driver can't advertise FUA support on zeroes (block/iscsi.c does this) and the block layer fallback kicks in. So I think we're fine on that front.

Still, while you argue that TRIM is advisory (which I agree), if it does nothing, then you've (implicitly) honored FUA (that transaction didn't affect persistent storage, so you didn't have to wait any longer for anything to land); but if it DOES change the disk contents, then waiting for that change to land IS worth supporting, hence why the NBD protocol requires the FUA flag to be honored on trim.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]