Re: [PATCH V8 08/19] xfs: Introduce XFS_SB_FEAT_INCOMPAT_NREXT64 and associated per-fs feature bit

From: Chandan Babu R <chandan.babu@oracle.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH V8 08/19] xfs: Introduce XFS_SB_FEAT_INCOMPAT_NREXT64 and associated per-fs feature bit
Date: Fri, 25 Mar 2022 11:31:05 +0530	[thread overview]
Message-ID: <875yo2y3j2.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20220324214030.GT8224@magnolia>

On 25 Mar 2022 at 03:10, Darrick J. Wong wrote:
> On Fri, Mar 25, 2022 at 08:37:19AM +1100, Dave Chinner wrote:
>> On Mon, Mar 21, 2022 at 10:47:39AM +0530, Chandan Babu R wrote:
>> > XFS_SB_FEAT_INCOMPAT_NREXT64 incompat feature bit will be set on filesystems
>> > which support large per-inode extent counters. This commit defines the new
>> > incompat feature bit and the corresponding per-fs feature bit (along with
>> > inline functions to work on it).
>> > 
>> > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
>> > Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
>> > ---
>> >  fs/xfs/libxfs/xfs_format.h | 1 +
>> >  fs/xfs/libxfs/xfs_sb.c     | 3 +++
>> >  fs/xfs/xfs_mount.h         | 2 ++
>> >  3 files changed, 6 insertions(+)
>> > 
>> > diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
>> > index b5e9256d6d32..64ff0c310696 100644
>> > --- a/fs/xfs/libxfs/xfs_format.h
>> > +++ b/fs/xfs/libxfs/xfs_format.h
>> > @@ -372,6 +372,7 @@ xfs_sb_has_ro_compat_feature(
>> >  #define XFS_SB_FEAT_INCOMPAT_META_UUID	(1 << 2)	/* metadata UUID */
>> >  #define XFS_SB_FEAT_INCOMPAT_BIGTIME	(1 << 3)	/* large timestamps */
>> >  #define XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR (1 << 4)	/* needs xfs_repair */
>> > +#define XFS_SB_FEAT_INCOMPAT_NREXT64	(1 << 5)	/* large extent counters */
>> >  #define XFS_SB_FEAT_INCOMPAT_ALL \
>> >  		(XFS_SB_FEAT_INCOMPAT_FTYPE|	\
>> >  		 XFS_SB_FEAT_INCOMPAT_SPINODES|	\
>> > diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c
>> > index f4e84aa1d50a..bd632389ae92 100644
>> > --- a/fs/xfs/libxfs/xfs_sb.c
>> > +++ b/fs/xfs/libxfs/xfs_sb.c
>> > @@ -124,6 +124,9 @@ xfs_sb_version_to_features(
>> >  		features |= XFS_FEAT_BIGTIME;
>> >  	if (sbp->sb_features_incompat & XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR)
>> >  		features |= XFS_FEAT_NEEDSREPAIR;
>> > +	if (sbp->sb_features_incompat & XFS_SB_FEAT_INCOMPAT_NREXT64)
>> > +		features |= XFS_FEAT_NREXT64;
>> > +
>> 
>> Shouldn't enabling the feature be the last patch in the series, once
>> all the infrastructure to support the feature is in place? i.e. if
>> someone does a bisect on a XFS_FEAT_NREXT64 enabled filesystem, they
>> can land in the middle of this series where the fs tries to use
>> XFS_FEAT_NREXT64 but the functionality is not complete.
>
> The last patch of the series does exactly that, by adding NREXT64 to
> XFS_SB_FEAT_INCOMPAT_ALL.
>

If a bisection lands on the current patch, the "Unknown incompat feature"
check would cause the filesystem mount to fail. Hence, I think the code is
safe since it does not allow partially implemented NREXT64 feature to be
executed.

-- 
chandan