On 31 Mar 2016, at 20:33, Eric Blake <ebl...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
