Re: [RFC DELUGE v10r1d2] xfs: Parent Pointers

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Mar 17, 2023 at 07:06:07PM +0000, Allison Henderson wrote:
> On Thu, 2023-03-16 at 11:54 -0700, Darrick J. Wong wrote:
> > Hi everyone,
> > 
> > This deluge contains all of the additions to the parent pointers
> > patchset that I've been working since last month's deluge.  The
> > kernel
> > and xfsprogs patchsets are based on Allison's v10 tag from last week;
> > the fstests patches are merely a part of my development tree.  To
> > recap
> > Allison's cover letter:
> > 
> > "The goal of this patch set is to add a parent pointer attribute to
> > each
> > inode.  The attribute name containing the parent inode, generation,
> > and
> > directory offset, while the  attribute value contains the file name.
> > This feature will enable future optimizations for online scrub,
> > shrink,
> > nfs handles, verity, or any other feature that could make use of
> > quickly
> > deriving an inodes path from the mount point."
> > 
> > v10r1d2 rebases everything against 6.3-rc2.  I still want to remove
> > the
> > diroffset from the ondisk parent pointer, but for v10 I've replaced
> > the
> > sha512 hashing code with modifications to the xattr code to support
> > lookups based on name *and* value.  With that working, we can encode
> > parent pointers like this:
> > 
> >         (parent_ino, parent_gen, name[])
> > 
> > xattr lookups still work correctly, and repair doesn't have to deal
> > with
> > keeping the diroffsets in sync if the directory gets rebuilt.  With
> > this
> > change applied, I'm ready to weave my new changes into Allison's v10
> > and
> > call parent pointers done. :)
> > 
> > The online directory and parent pointer code are exactly the same as
> > the
> > v9r2d1 release, so I'm eliding that and everything that was in
> > Allison's
> > recent v10 patchset.  IOWs, this deluge includes only the bug fixes
> > I've
> > made to parent pointers, the updates I've made to the ondisk format,
> > and
> > the necessary changes to fstests to get everything to pass.
> > 
> > If you want to pull the whole thing, use these links:
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=pptrs-drop-unnecessary__;!!ACWV5N9M2RV99hQ!MnkBbyDKEdgQiXLfmXZ87uT_j_TAtQHHA1UraPf01op6wNpRZkk2tg5CXru4eL6-pzJyUl-uJAZlSrGWwDFp$
> >  
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=pptrs-drop-unnecessary__;!!ACWV5N9M2RV99hQ!MnkBbyDKEdgQiXLfmXZ87uT_j_TAtQHHA1UraPf01op6wNpRZkk2tg5CXru4eL6-pzJyUl-uJAZlSmjOh6X7$
> >  
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=pptrs-name-in-attr-key__;!!ACWV5N9M2RV99hQ!MnkBbyDKEdgQiXLfmXZ87uT_j_TAtQHHA1UraPf01op6wNpRZkk2tg5CXru4eL6-pzJyUl-uJAZlSlulOhuJ$
> >  
> > 
> > Allison: Could you please resync libxfs in the following patches
> > under
> > https://urldefense.com/v3/__https://github.com/allisonhenderson/xfsprogs/commits/xfsprogs_new_pptrs_v10__;!!ACWV5N9M2RV99hQ!MnkBbyDKEdgQiXLfmXZ87uT_j_TAtQHHA1UraPf01op6wNpRZkk2tg5CXru4eL6-pzJyUl-uJAZlSqiXa3xN$
> >  
> > please?
> > 
> > xfsprogs: add parent pointer support to attribute code
> > xfsprogs: extend transaction reservations for parent attributes
> > xfsprogs: parent pointer attribute creation
> > xfsprogs: remove parent pointers in unlink
> > xfsprogs: Add parent pointers to rename
> > xfsprogs: move/add parent pointer validators to xfs_parent
> > 
> > There are discrepancies between the two, which makes ./tools/libxfs-
> > diff
> > unhappy.  Or, if you want me to merge my ondisk format changes into
> > my
> > branches, I'll put out v11 with everything taken care of.
> Sure, will resync, as I recall some of them had to deviate a little bit
> because the corresponding code appears in different places, or needed
> special handling.

Ok, thank you.  It's easier to develop xfsprogs code when libxfs can be
kept in sync easily.

> Originally my intent was just to get the kernel side of things settled
> and landed first, and then grind through the other spaces since user
> space is mostly a port.  I was trying to avoid sending out giant
> deluges since people seemed to get hung up enough in just kernel space
> reviews.

Yeah, 'tis true that sending xfsprogs libxfs patches prematurely is just
noise on the list. :/

That said, the closer a patchset gets to final review, the tidier the
xfsprogs part ought to be.  I've added support in repair and the
debugger, which means this is /very/ close to its final review.

--D

> Thanks for all the help tho.
> 
> Allison
> 
> > 
> > --D
>