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 >
