Re: [PATCH 2/2] xfs: don't extend the FITRIM range if the rt device does not support discard

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Aug 19, 2024 at 02:44:07PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2024 at 02:50:17PM -0700, Darrick J. Wong wrote:
> > Is there more to this than generic/260 failing?
> 
> The only other users of the detection is generic/251, which doesn't
> seem to care about the exact value.
> 
> > And if not, does the
> > following patch things up for you?
> 
> This works.  OTOH it will break again with the zoned RT subvolume
> which can't support FITRIM even on devices that claim it.  And for
> actual users that care (and not just xfstests) these kinds of hacks
> don't seem very palatable..

What does discard do on a zoned device?  Is that how you reset the write
pointer?  And does that mean that either you tell the device to discard
everything it's written in a zone, or it will do nothing?

I see that this test really just puts a lower bound on how much FITRIM
can report that it discarded from an empty fs.  That number is already
rather meaningless on XFS because the amount "discarded" is roughly
(free space - (amount of pending gc work + discard work already in
progress)) and the user has no visibility into the amount of pending gc
work.  And you can repeatedly FITRIM and it reports the same number
since we have no idea if the device actually *did* anything.

Hmm.  No manpage for FITRIM.  Why don't we return the number of bytes
in the space map that we iterated as range.len?  Or perhaps leave it
unchanged?

--D