[BBLISA] Mapping inode numbers to file names

[John Stoffel]

>>>>> "David" == David N Blank-Edelman <dnb at ccs.neu.edu> writes:

David> On Apr 28, 2010, at 8:32 AM, Dean Anderson wrote:

>> I can't think of any alternative to recursively decending the file space
>> looking for the inode. Find might not be the fastest program, though.

David> Ok, now you've peaked my interest. Two questions:

David> 1) Are there any other cool filestystem-walking tools out
David> there? I'm willing to believe someone has done a faster version
David> of find that I just haven't heard of. I know about stuff like
David> ack, but is there an ffind in existence?

It depends on the hardware the filesystem is on, and the load it can
handle.  For a single disk... you'll just thrash it to death with
mutiple finds.  I wouldn't expect them to finish faster at all, and
probably slower.

Now with a big Netapp with NFS, then I'd run parallel finds.  I found
something like 3x speedup with upto 4 threads.  More than that and I
waws impacting user experience. 

David> 2) Could one do anything smart when looking for the inode based
David> on its number and how inode numbers are allocated? I don't know
David> how random the allocation is and whether numeric proximity
David> relates at all to hierarchical proximity.

I think it depends on the filesystem.  And of course a network
filesystem probably doesn't have Inodes in the sense your asking for.

One trick is to read each directory in readdir order, which is linear
(for ext2/3 at least), instead of in alphabetical order.  

My personal feeling is that you should just move up a few levels and
search down from there, and not spend time searching all over the
filesystem for something, since I would assume (and we all know what
that really means!) that most moves are generally quite local, unless
they've moved someplace completely else, like another network
filesystem.

John