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

[Kevin Wolf <kwolf@redhat.com>]

Am 01.04.2016 um 09:43 hat Paolo Bonzini geschrieben:
> 
> 
> On 31/03/2016 22:17, Alex Bligh wrote:
> >> > In qemu, read+FUA just triggers blk_co_flush() prior to reading; but
> >> > that's the same function it calls for write+FUA.
> > That's harmless, but unnecessary in the sense that current documented
> > behaviour doesn't require it. Perhaps it should?
> > 
> > I suppose TRIM etc. should support FUA too?
> 
> TRIM is an advisory operation, so it doesn't make sense to force access
> to the medium.

I think it does make sense. It means that on completion there is no
pending discard operation (i.e. either there wasn't a discard or if
there was, it has completed) and other readers will see the final state
of the blocks.

> The closest you could get would be to add FUA to WRITE_ZEROES.  But
> since WRITE_ZEROES is not a particularly common operation there isn't
> much to gain compared to FLUSHing after the write has completed; in
> fact SCSI doesn't have a FUA bit on its WRITE SAME command.

Right, I guess this would mostly be for consistency when FUA is
supported more or less everywhere else.

Kevin