On Fri, Mar 19, 2021 at 07:55:36AM +1100, Dave Chinner wrote:

On Thu, Mar 18, 2021 at 12:17:06PM -0400, Brian Foster wrote:

quoted

perag reservation is enabled at mount time on a per AG basis. The
upcoming in-core allocation btree accounting mechanism needs to know
when reservation is enabled and that all perag AGF contexts are
initialized. As a preparation step, set a flag in the mount
structure and unconditionally initialize the pagf on all mounts
where at least one reservation is active.

I'm not sure this is a good idea. AFAICT, this means just about any
filesystem with finobt, reflink and/or rmap will now typically read
every AGF header in the filesystem at mount time. That means pretty
much every v5 filesystem in production...

They already do that, because the AG headers are where we store the
btree block counts.

We've always tried to avoid needing to reading all AG headers at
mount time because that does not scale when we have really large
filesystems (I'm talking petabytes here). We should only read AG
headers if there is something not fully recovered during the mount
(i.e. slow path) and not on every mount.

Needing to do a few thousand synchonous read IOs during mount makes
mount very slow, and as such we always try to do dynamic
instantiation of AG headers...  Testing I've done with exabyte scale
filesystems (>10^6 AGs) show that it can take minutes for mount to
run when each AG header needs to be read, and that's on SSDs where
the individual read latency is only a couple of hundred
microseconds. On spinning disks that can do 200 IOPS, we're
potentially talking hours just to mount really large filesystems...

Is that with reflink enabled?  Reflink always scans the right edge of
the refcount btree at mount to clean out stale COW staging extents, and
(prior to the introduction of the inode btree counts feature last year)
we also ahad to walk the entire finobt to find out how big it is.

TBH I think the COW recovery and the AG block reservation pieces are
prime candidates for throwing at an xfs_pwork workqueue so we can
perform those scans in parallel.

Hence I don't think that any algorithm that requires reading every
AGF header in the filesystem at mount time on every v5 filesystem
already out there in production (because finobt triggers this) is a
particularly good idea...

Perhaps not, but the horse bolted 5 years ago. :/

--D

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com