On Wed, Oct 28, 2020 at 05:03:32PM -0700, Darrick J. Wong wrote: > On Wed, Oct 28, 2020 at 01:29:25PM -0400, Brian Foster wrote: > > On Mon, Oct 26, 2020 at 04:33:38PM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > > > Enable users to upgrade their filesystems to support inode btree block > > > counters. > > > > > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > --- > > > db/sb.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++- > > > db/xfs_admin.sh | 4 ++- > > > man/man8/xfs_admin.8 | 16 +++++++++++ > > > 3 files changed, 94 insertions(+), 2 deletions(-) > > > > > > ... > > > diff --git a/man/man8/xfs_admin.8 b/man/man8/xfs_admin.8 > > > index 8afc873fb50a..65ca6afc1e12 100644 > > > --- a/man/man8/xfs_admin.8 > > > +++ b/man/man8/xfs_admin.8 ... > > > @@ -103,6 +105,20 @@ The filesystem label can be cleared using the special "\c > > > " value for > > > .IR label . > > > .TP > > > +.BI \-O " feature" > > > +Add a new feature to the filesystem. > > > +Only one feature can be specified at a time. > > > +Features are as follows: > > > +.RS 0.7i > > > +.TP > > > +.B inobtcount > > > +Upgrade the filesystem to support the inode btree counters feature. > > > +This reduces mount time by caching the size of the inode btrees in the > > > +allocation group metadata. > > > +Once enabled, the filesystem will not be writable by older kernels. > > > +The filesystem cannot be downgraded after this feature is enabled. > > > > Any reason for not allowing the downgrade path? It seems like we're > > mostly there implementation wise and that might facilitate enabling the > > feature by default. > > Downgrading will not be easy for bigtime, since we'd have to scan the > whole fs to see if there are any timestamps past 2038. For other > features it might not be such a big deal, but in general I don't want to > increase our testing burden even further. > Well it's not something I'd say we should necessarily support for every feature. TBH, I wasn't expecting an upgrade mechanism for inobtcount in the first place since I thought we didn't tend to do that for v5 filesystems. ISTM it's simple enough to support and perhaps that's good enough reason to do so, but if we're going to move the "test burden" line anyways it seems rather arbitrary to me to support one direction and not the other when they are presumably of comparable complexity. Just my .02 of course, and I don't feel strongly about whether we support upgrade, downgrade, or neither... Brian > I'll ask the ext4 folks if they know of people downgrading filesystems > with tune2fs, but AFAIK it's not generally done. > > --D > > > Brian > > > > > +.RE > > > +.TP > > > .BI \-U " uuid" > > > Set the UUID of the filesystem to > > > .IR uuid . > > > > > >
