Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

[Alex Bligh <alex@alex.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]


On 31 Mar 2016, at 20:33, Eric Blake <eblake@redhat.com> wrote:

> Qemu's nbd-client is setting NBD_CMD_FLAG_FUA during a flush command,
> but the official NBD protocol documentation doesn't describe this as
> valid (it merely states that flush must not have a reply until all
> acknowledged writes have hit permanent storage).  Does this flag make
> sense (what semantics would the flag add, and we need to fix the NBD
> docs as well as relax the reference implementation to allow the flag),
> or is it a bug in qemu (and the recent tightening of NBD to throw EINVAL
> on unsupported flags will trip up qemu)?

As the original author of that particular mess, the intent was that
they should reflect exactly the Linux kernel's semantics for FLUSH
and FUA, not only in terms of whether they can be used together,
but also exactly what they mean.

This turned out to be an easier way of describing the operations
than describing them semantically (in particular FLUSH, where I
couldn't get an entirely consistent answer of what it required
of inflight requests, specifically whether it required all
requests inflight at the time of making the request to be written
to disk prior to answering, or all requests inflight prior to the
time of replying to be written to disk prior to answering, though
I believe the former).

FUA just requires that particular request to be persisted to
disk, and does not require other requests to be persisted to disk

So in answer to your question, my understanding is that FLUSH requires
(some subset) of otherwise potentially non-persisted requests to
be persisted to disk. In that sense it implies FUA. It is permitted
to set FUA (as it is permitted, I believe, in the linux block layer)
but it will make no difference.

I once thought FUA on read should bypass any local read cache, though
that is not part of the spec currently.

--
Alex Bligh





[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]