On Fri, Jun 17, 2022 at 05:32:36PM -0700, Alli wrote: > On Thu, 2022-06-16 at 16:03 +1000, Dave Chinner wrote: > > On Sat, Jun 11, 2022 at 02:41:57AM -0700, Allison Henderson wrote: > > > [dchinner: forward ported and cleaned up] > > > [achender: rebased and added parent pointer attribute to > > > compatible attributes mask] > > > > > > Signed-off-by: Mark Tinguely <tinguely@xxxxxxx> > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > > Signed-off-by: Allison Henderson <allison.henderson@xxxxxxxxxx> > > > Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > --- > > > fs/xfs/libxfs/xfs_format.h | 14 +++++++++----- > > > fs/xfs/libxfs/xfs_fs.h | 1 + > > > fs/xfs/libxfs/xfs_sb.c | 2 ++ > > > fs/xfs/xfs_super.c | 4 ++++ > > > 4 files changed, 16 insertions(+), 5 deletions(-) > > > > > > diff --git a/fs/xfs/libxfs/xfs_format.h > > > b/fs/xfs/libxfs/xfs_format.h > > > index 96976497306c..e85d6b643622 100644 > > > --- a/fs/xfs/libxfs/xfs_format.h > > > +++ b/fs/xfs/libxfs/xfs_format.h > > > @@ -83,6 +83,7 @@ struct xfs_ifork; > > > #define XFS_SB_VERSION2_OKBITS \ > > > (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \ > > > XFS_SB_VERSION2_ATTR2BIT | \ > > > + XFS_SB_VERSION2_PARENTBIT | \ > > > XFS_SB_VERSION2_PROJID32BIT | \ > > > XFS_SB_VERSION2_FTYPE) > > > > No need for a v4 filesystem format feature bit - this is v4 only. > Ok, I ended up having to add this in the rebase or we get an "SB > validate failed". I think it has to go over in > xfs_sb_validate_v5_features next to the manual crc bit check. Will > move Ah, I meant that parent pointers are a v5 only feature, and so we don't need a "v4 only" feature bit for it. As it is, we can't use that specific bit because SGI shipped a version of parent pointers on v4 filesystems on IRIX under that feature bit that was broken and subsequently recalled and killed. Essentially, that means XFS_SB_VERSION2_PARENTBIT is blacklisted and cannot ever be used by upstream kernels. > > > @@ -353,11 +354,13 @@ xfs_sb_has_compat_feature( > > > #define XFS_SB_FEAT_RO_COMPAT_RMAPBT (1 << 1) /* > > > reverse map btree */ > > > #define XFS_SB_FEAT_RO_COMPAT_REFLINK (1 << 2) /* > > > reflinked files */ > > > #define XFS_SB_FEAT_RO_COMPAT_INOBTCNT (1 << 3) /* > > > inobt block counts */ > > > +#define XFS_SB_FEAT_RO_COMPAT_PARENT (1 << 4) /* > > > parent inode ptr */ > > > #define XFS_SB_FEAT_RO_COMPAT_ALL \ > > > - (XFS_SB_FEAT_RO_COMPAT_FINOBT | \ > > > - XFS_SB_FEAT_RO_COMPAT_RMAPBT | \ > > > - XFS_SB_FEAT_RO_COMPAT_REFLINK| \ > > > - XFS_SB_FEAT_RO_COMPAT_INOBTCNT) > > > + (XFS_SB_FEAT_RO_COMPAT_FINOBT | \ > > > + XFS_SB_FEAT_RO_COMPAT_RMAPBT | \ > > > + XFS_SB_FEAT_RO_COMPAT_REFLINK | \ > > > + XFS_SB_FEAT_RO_COMPAT_INOBTCNT| \ > > > + XFS_SB_FEAT_RO_COMPAT_PARENT) > > > > I'm not sure this is a RO Compat feature - we added an attribute > > namespace flag on disk, and the older kernels do not know about > > that (i.e. we changed XFS_ATTR_NSP_ONDISK_MASK). This may result in > > parent pointer attrs being exposed as user attrs rather than being > > hidden, or maybe parent pointer attrs being seen as corrupt because > > they have a flag that isn't defined set, etc. > > > > Hence I'm not sure that this classification is correct. > > Gosh, I'm sure there was a reason we did this, but what ever it was > goes all the way back in the first re-appearance of the set back in > 2018 and I just cant remember the discussion at the time. It may have > just been done to get mkfs working and we just never got to reviewing > it. > > Should we drop it and just use XFS_SB_VERSION2_PARENTBIT? No, it needs to be a v5 feature bit - create a v5 parent pointer filesystem, create some files on it, and then go an mount it on a kernel that doesn't have PP support. If you can see the parent pointer attributes from userspace as "user.<binary garbage>" attributes, then we need to use an INCOMPAT feature bit rather than a RO_COMPAT bit. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
