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
