]> git.apps.os.sepia.ceph.com Git - xfsprogs-dev.git/commit
Merge tag 'scrub-fstrim-phase-6.10_2024-07-29' of https://git.kernel.org/pub/scm...
authorCarlos Maiolino <cem@kernel.org>
Tue, 6 Aug 2024 13:47:46 +0000 (15:47 +0200)
committerCarlos Maiolino <cem@kernel.org>
Tue, 6 Aug 2024 13:47:46 +0000 (15:47 +0200)
commit3dab1af58bdd37db30021c4dead55402248bd65b
tree1e62bce66b4de63ddf660e239d4fed26d8cf0a46
parent8dfca6229488ae855270251a347a7d7ed6e34399
parent5ccdd24dc9987b50333332b7381ff1a305e67ef7
Merge tag 'scrub-fstrim-phase-6.10_2024-07-29' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev into for-next

xfs_scrub: move fstrim to a separate phase [v30.9 12/28]

Back when I originally designed xfs_scrub, all filesystem metadata
checks were complete by the end of phase 3, and phase 4 was where all
the metadata repairs occurred.  On the grounds that the filesystem
should be fully consistent by then, I made a call to FITRIM at the end
of phase 4 to discard empty space in the filesystem.

Unfortunately, that's no longer the case -- summary counters, link
counts, and quota counters are not checked until phase 7.  It's not safe
to instruct the storage to unmap "empty" areas if we don't know where
those empty areas are, so we need to create a phase 8 to trim the fs.
While we're at it, make it more obvious that fstrim only gets to run if
there are no unfixed corruptions and no other runtime errors have
occurred.

Finally, reduce the latency impacts on the rest of the system by
breaking up the fstrim work into a loop that targets only 16GB per call.
This enables better progress reporting for interactive runs and cgroup
based resource constraints for background runs.

This has been running on the djcloud for months with no problems.  Enjoy!

Signed-off-by: Darrick J. Wong <djwong@kernel.org>