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!). > 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. Paolo
