On Tue, Jul 02, 2024 at 07:30:19AM +0200, Christoph Hellwig wrote: > On Mon, Jul 01, 2024 at 06:02:36PM -0700, Darrick J. Wong wrote: > > Therefore, we created a second implementation that will walk the bnobt > > and perform the trims in block number order. This implementation avoids > > the worst problems of the original code, though it lacks the desirable > > attribute of freeing the biggest chunks first. > > > > On the other hand, this second implementation will be much easier to > > constrain the system call latency, and makes it much easier to report > > fstrim progress to anyone who's running xfs_scrub. Skip the first block > > of each AG to ensure that we get the sub-AG algorithm. > > I completely fail to understand how skipping the first block improves > performance and is otherwise a good idea. What am I missing? Actually, I think this patch doesn't have a good reason to exist on its own anymore. The goal of this patch and the next one is to improve responsiveness to signals and smoothness of the progress bar by reducing the number of bytes per FITRIM call, but I think limiting that to 11GB per call is sufficient without the "skip the first block" games. Those games once was the magic method for getting the kernel to use the by-block discard algorithm instead of the by-length algorithm, but most of the deficiencies in both algorithsm have been fixed now. So in the end the only reason for this patch to continue existing is so that we only issue one log force and lock one AGF per FITRIM call. The next patch exists to constrain latencies. I think I'll combine these two patches into a single patch that avoids having FITRIM requests cross AGs and breaks the requests into 11G chunks to improve latency. --D
