On Mon, Oct 09, 2023 at 11:18:33AM -0700, Darrick J. Wong wrote: > The storage advertises SCSI UNMAP support, but it is of the variety > where the UNMAP command returns immediately but takes its time to unmap > in the background. Subsequent rereads are allowed to return stale > contents, per DISCARD semantics. > > When the fstests cloud is not busy, the old contents disappear in a few > seconds. However, at peak utilization, there are ~75 VMs running, and > the storage backend can take several minutes to commit these background > requests. Umm, that is not valid behavior fo SCSI UNMAP or any other command that Linux discard maps to. All of them can do one of the two options on a per-block basis: - return the unmap pattern (usually but not always 0) for any read following the unmap/trim/discard - always return the previous pattern until it is overwritten or discarded again Changing the pattern some time after unmap is a grave bug, and we need to blacklist the device.
