Re: [Qemu-devel] [PATCHv3] Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA.

[Alex Bligh]

Paolo,

On 5 Apr 2016, at 15:30, Paolo Bonzini <address@hidden> wrote:

>> * Document that sending FUA for commands that do nothing is permissible, but
>>  'SHOULD NOT' be done; an existing client does this.
> 
> Can you send a pointer to the discussion?  FUA on reads definitely does
> *something* in SCSI (it ensures that the data is moved out of the
> volatile cache prior to the read, similar to what QEMU implements).

Sure. I got a solitary one reply that referenced the kernel, which
was copied to this list - see below.

I don't have strong feelings either way, but the safer option would
be to not REQUIRE the server to rely on any FUA read behaviour (I'm
already saying they should ignore the bit on reads). Qemu can't
currently RELY on FUA on reads, as it's not documented anywhere
and with the reference NBD server did nothing until recently; recently
it started errorring the read! See below.

On that basis I chose to go with 'FUA on read does nothing'.

If the kernel actually does something on read perhaps we should
reconsider.

Alex

Begin forwarded message:

> From: Jeff Moyer <address@hidden>
> Subject: Re: Block layer - meaning of REQ_FUA on not write requests
> Date: 1 April 2016 17:06:09 BST
> To: Alex Bligh <address@hidden>
> Cc: "address@hidden" <address@hidden>, address@hidden, Eric Blake 
> <address@hidden>
> 
> Alex Bligh <address@hidden> writes:
> 
>> I am trying to clean up the documentation of the NBD protocol. NBD's
>> support for Force Unit Access (FUA) was modelled on the linux kernel
>> block layer. When I added support a few years ago, I omitted to find
>> out exactly what types of request it applies to. Obviously it applies
>> to write requests, but how about others (e.g. read)?
> 
> Any request with REQ_FUA set will be treated as a flush by the block
> layer.  As such, we do not expect reads to have this bit set.
> 
> Cheers,
> Jeff

-- 
Alex Bligh