Edward Ned Harvey wrote: >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Chris Hoogendyk >> >> Of course, zfs is most likely Solaris 10, and GNU locate is most likely >> Linux. Locate isn't on Solaris by default. However, sunfreeware added a >> findutils package not too long ago that includes locate. Locate has >> advantages and disadvantages. It runs a cron in the middle of the night >> to populate a database with filenames and locations. It is thus faster >> than find, but limited to finding the location of files based on their >> names (as they were yesterday). >> > > The Linux utility wouldn't be the main problem in the "locate" scenario. I > considered just running a cron job to generate a txt file in the form: > inodenum filename > Generate an index file for the whole filesystem. I guessed that would take > ... I don't know ... an hour. > > But the granularity of snapshots is every 15 minutes. So if anything is > going to perform an exhaustive index periodic operation and be useful ... > it's got to be *really* fast. I don't think it's a viable option. > There is no 'reverse lookup' mechanism for inodes. If the file is open, lsof can find it, but even that is an expensive operation.
The inodes, by their nature, are not meant to be used this way. The inodes do not contain references back to their file name(s) (remember, this is how links are done - multiple directory entries point at the same inode, and the file is not considered truly deleted until the link count in the inode is zero). They are the low-level items that are pointed at, they weren't built to be used the other way around. Almost anything that you are going to do with inodes in this way is going to be expensive. - Richard _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
