Skip to content

xfs: parent pointers

Darrick J. Wong linux-xfs 1 version In review

Get series with b4
b4 am 20171208035457.GD19219@magnolia

Versions newest first

  1. v1 Latest2 patches 1 replyIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2xfs: sketchy implementation of parent pointersfs/xfs/Makefile fs/xfs/libxfs/xfs_fs.h fs/xfs/xfs_ioctl.c +2 more+350 -01 reply
2/2xfsprogs: implement the upper half of parent pointersfsr/Makefile include/handle.h include/parent.h +10 more+708 -3570 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFCRAP DONOTMERGE PATCH 0/2] xfs: parent pointers

Hi all,

So I've been working in my spare time (ha ha) to build a prototype parent pointer ioctl backend so that I can play around with the userspace side of things -- namely (cough) having xfs_scrub be able to resolve an (ino, gen) tuple back to a user-friendly file path.

The first ugly patch attacks the dentry cache to use d_parent to provide one of the parents of some file. Obviously, this is totally deficient as we can only report one parent and the file has to have been opened via path at some previous point in time, and I bet the locking is totally wrong. It's too ugly to live but it /does/ function as a stub.

The second patch implements two iterators atop the parent pointer ioctl we've been tossing around on the mailing list -- one to return parents of an open file/file handle, and a second one to return all the paths of an open file/file handle, and plunges it into (part of) xfs_scrub and the xfs_io parent command. Note that I'm expecting xfs_scrub/xfs_repair to take over parent pointer checking and fixing, so I removed the checker function from xfs_io.

This is _not_ a substitute for Allison's parent pointer patches, as they provide the meat of the real feature... but seeing how much bikeshedding ioctls invite, we might as well start the reconciliation process now.

--D