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 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
