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

[Paolo Bonzini <pbonzini@redhat.com>]

On 08/03/2018 15:45, Eric Blake wrote:
> 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
>>> layer.
>>
>> TRIM requests should not need FUA since they're just advisory.
> 
> 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.

But if power fails, after restart you cannot see the difference between
a TRIM command that chose to did nothing, and one that chose to change
the disk contents but failed to persist the changes.  This is why I
thought there is no need for FUA in my opinion.

I suppose in principle you could detect the change by reading the
TRIMmed sectors and writing to another disk.  So TRIM would have to be a
Schroedinger command that is persistent once you read the sectors, and
that makes little sense.  The problem is, SCSI doesn't have a FUA flag
either...

Paolo