On Tue, Jan 30, 2018 at 08:56:07PM -0700, Allison Henderson 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. The online fs check use case is that we iterate every inode in the filesystem from start to finish via file handles, and if we find some damage it would be much more helpful to be able to report the file path to userspace (e.g. "/foo/bar/file is corrupt" vs. "inode 325325 is corrupt"). A second use is for xfs_repair and/or online fs repair -- instead of dumping files orphaned by a destroyed directory in lost+found, we have the possibility of rebuilding that directory by scanning all the inodes to see which ones have parent pointers to the broken directory and then rebuilding it from there. Easy enough to do in xfs_repair, but will be significantly more challenging to do it in the kernel <cough>. The third use I can think of relates to past years' discussion of head de-pop and pmem badblocks -- given a range of defective storage, we can cross reference that with the reverse mapping to figure out which (inode, offset) are affected, and try to use parent pointers to turn the inode numbers into file paths. We can also figure out if metadata is affected and start a rebuild operation (though obviously if the rmap data is affected then we're toast). > 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 Not sure it'll help for fs shrink, but clearly the exportfs part of the discussion has taken off. :) > 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. I posted a userspace ioctl interface strawman here, implementing use case #1 from above: https://marc.info/?l=linux-xfs&m=151270557232472&w=2 Basic parent pointer iteration and path construction are provided in userspace, bolted atop the in-kernel parent pointer iterator that behaves similarly to the existing xfs file-handle attribute iterator. --D > > Thank you! > > Allison Henderson
