On Thu, Aug 28, 2014 at 04:14:25PM -0700, Chris Holcombe wrote: > My apologies if this has already been asked. I feel that I've done a > sufficient amount of Google search homework. I'm working with Gluster > (http://www.gluster.org/) and they have a directory called xattrop > where they store links to files that need to be healed. When I stat > the file I can see that there's 2 or 3 hard links to the file. I > can't seem to find a way in code or with an xfs_* utility to find the > path of those hard links. Does anyone know how to do this or if it's > even possible? From looking through the XFS documentation I don't > really see a way to do it without a find /mount_point -num <number> > brute force method. btrfs has a utility called: > > btrfs inspect-internal inode-resolve [-v] <inode> <path> > Resolves an <inode> in subvolume <path> to all filesystem > paths. > > I'd like to build an equivalent tool in C for XFS if it's possible. You need help from the filesystem, both in terms of the on-disk format and the kernel code needed to push that information back out to userspace. Indeed, this is the functionality we need for reverse inode->path lookups: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/27772 (parent pointers, for those that don't want to follow the link) Right now it's state is in limbo. We have a more recent design, but since SGI has dropped off the edge of the world, nobody is working on it. It's on my radar along with reverse mapping btrees for filesystem block to inode lookups so that we can do all of this sort of stuff easily without needing to walk the entire filesystem to find the forward pointers to objects.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
