Am 06.04.2016 um 15:28 hat Paolo Bonzini geschrieben: > > > On 06/04/2016 15:14, Kevin Wolf wrote: > >>> > > > >>> > > 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. > >> > > >> > This is what already happens though, isn't it? > > You mean because in practice discard requests aren't even cached, so we > > always behave as if FUA were specified? That's probably right, but is > > there a fundamental reason why some storage backend couldn't have a > > writeback cache for discards? > > No, there isn't. Does qcow2's discard get cached? I wouldn't be > surprised (and SCSI actually says nowhere that WRITE SAME is durable > without a subsequent SYNCHRONIZE CACHE!).
For qcow2, yes and no. It has a cache for coalescing discards within a single request, but that cache is flushed before completing the operation. So it's not visible for the caller. > > It probably wouldn't make sense to introduce FUA for this if it didn't > > already exist elsewhere, but now that we do have it, I'd allow it for > > TRIM, too, for the sake of consistency and symmetry. > > Yes, that's fine. Kevin
