On Jan 30, 2018, at 8:56 PM, Allison Henderson <allison.henderson@xxxxxxxxxx> wrote:
>
> Hi everyone!
>
> Recently I have been working towards adding a new parent pointer patch set to xfs. Briefly summarized, goal of the feature is to enable an application to quickly derive an inodes path from the mount point by storing information about the inodes parent(s) in an extended attribute. Currently, I am aware of the intent to use the feature as part of an online scrub and repair feature. Looking forward however, I would like to know about any other future coding intents that might make use of this feature. For example, optimizing file system shrink or exportfs operations? Are there certain interfaces or test cases that would be helpful to have? I know the patch set has had a complicated history, so ideally being aware of how folks may go about using it may help to construct test cases to route out flaws sooner rather than later.
We have reverse inode->parent pointers in Lustre already, with a list of
{parent,name} tuples stored in a "link" xattr. There is a userspace command
"lfs fid2path /mountpoint [FID]" that spits out a list of pathnames for a
filename relative to /mountpoint when the FID (inode number) is given.
Parent directory links are useful in several areas:
- better reporting in error messages (filename instead of inode number)
- generate pathnames for a hard-linked file for regular users, or tools like
migration/rsync/tar so that they don't need to reverse engineer hard links
by scanning the whole filesystem looking for matching inode numbers
- directory reconstruction in fsck, since each inode can use the xattr data
re-attach itself to the namespace, including the directories themselves
which contain a "link" xattr with their own name in the ".." directory
- being able to generate open file listings on the server from a list of
FIDs (this is probably not useful for local filesystems)
Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
