Re: [LSF/MM TOPIC][LSF/MM ATTEND] Parent pointer future use cases

[Allison Henderson <allison.henderson@oracle.com>]

On 01/31/2018 11:46 AM, Darrick J. Wong wrote:
> 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

Yes, I think I have an earlier version of that patch in my tree already, 
so I'll make sure those work.  :-)

Thank you everyone for all your feedback, this gives me some more ideas 
of use cases I can run it through as it comes up.  Hoping to have 
another set of it out soon for people to look through.  Thanks all!

Allison

> 
>>
>> Thank you!
>>
>> Allison Henderson