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
