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