Re: [PATCH 1/3] xfs/178: don't fail when SCRATCH_DEV contains random xfs superblocks

Christoph Hellwig
2023-10-10T07:01:41Z

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.