>>>>> "David" == David N Blank-Edelman <[email protected]> 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 _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
