Re: [RFC DELUGE v10r1d2] xfs: Parent Pointers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2023-03-17 at 16:45 -0700, Darrick J. Wong wrote:
> 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.

Here is a resync, some of them still needed hand porting, but it looks
like it sync'd up a lot of white space so let me know if this clears up
things for you
https://github.com/allisonhenderson/xfsprogs/tree/xfsprogs_new_pptrs_v10r1

Allison

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





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux