All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/9] xfs_db: add inobtcnt upgrade path
Date: Thu, 29 Oct 2020 08:42:50 -0700	[thread overview]
Message-ID: <20201029154250.GL1061252@magnolia> (raw)
In-Reply-To: <20201029120905.GA1657878@bfoster>

On Thu, Oct 29, 2020 at 08:09:05AM -0400, Brian Foster wrote:
> 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@oracle.com>
> > > > 
> > > > Enable users to upgrade their filesystems to support inode btree block
> > > > counters.
> > > > 
> > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > > ---
> > > >  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.

We've not been especially consistent with that -- I think you can
"upgrade" to meta_uuid; at one point Christoph had a series to make it
possible to upgrade to reflink; but all the other features don't support
upgrades.

I picked inobtcount for the initial v5 upgrade support because it seemed
like a small enough feature that people could theoretically backport the
feature to old kernels.  That was supposed to go in ahead of y2038
support (which is my real motivation for allowing some upgrades) but
then they both landed at the same time. ;)

> 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...

I think the only features that we've supported downgrading are attr2 ->
attr1 and (in the old days) unwritten extents.

--D

> 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 .
> > > > 
> > > 
> > 
> 

  reply	other threads:[~2020-10-29 15:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 23:33 [PATCH v4 0/9] xfsprogs: add a inode btree blocks counts to the AGI header Darrick J. Wong
2020-10-26 23:33 ` [PATCH 1/9] xfs: store inode btree block counts in " Darrick J. Wong
2020-10-26 23:33 ` [PATCH 2/9] xfs: use the finobt block counts to speed up mount times Darrick J. Wong
2020-10-26 23:33 ` [PATCH 3/9] xfs: support inode btree blockcounts in online repair Darrick J. Wong
2020-10-26 23:33 ` [PATCH 4/9] xfs_db: support displaying inode btree block counts in AGI header Darrick J. Wong
2020-10-28 17:28   ` Brian Foster
2020-10-26 23:33 ` [PATCH 5/9] xfs_db: add inobtcnt upgrade path Darrick J. Wong
2020-10-28 17:29   ` Brian Foster
2020-10-29  0:03     ` Darrick J. Wong
2020-10-29 12:09       ` Brian Foster
2020-10-29 15:42         ` Darrick J. Wong [this message]
2020-11-16 21:13   ` [PATCH v2 " Darrick J. Wong
2020-11-18 21:05     ` Eric Sandeen
2020-11-20  1:05       ` Darrick J. Wong
2020-11-20  4:10         ` Eric Sandeen
2020-10-26 23:33 ` [PATCH 6/9] xfs_repair: check inode btree block counters in AGI Darrick J. Wong
2020-10-28 17:29   ` Brian Foster
2020-10-29  1:01     ` Darrick J. Wong
2020-11-16 17:19   ` [PATCH v2 " Darrick J. Wong
2020-11-16 20:29     ` Eric Sandeen
2020-10-26 23:33 ` [PATCH 7/9] xfs_repair: regenerate " Darrick J. Wong
2020-10-28 17:30   ` Brian Foster
2020-10-26 23:33 ` [PATCH 8/9] mkfs: enable the inode btree counter feature Darrick J. Wong
2020-10-28 17:30   ` Brian Foster
2020-10-29  1:02     ` Darrick J. Wong
2020-10-26 23:34 ` [PATCH 9/9] xfs: enable new inode btree counters feature Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201029154250.GL1061252@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.