> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey

Thanks to Victor, here is at least proof of concept that yes, it is possible
to reverse resolve, inode number --> pathname, and yes, it is almost
infinitely faster than doing something like "find":

Root can reverse lookup names of inodes with this command:
        zdb -dddd <dataset_name> <object_number>

(on a tangent)
Surprisingly, it is not limited to just looking up directories.  It finds
files too (sort of).  Apparently a file inode does contain *one* reference
to its latest parent.  But if you hardlink more than once, you'll only find
the latest parent, and if you rm the latest hardlink, then it'll still find
only the latest parent, which has been unlinked, and therefore not valid.

But it works perfectly for directories.
(back from tangent)

Regardless of how big the filesystem is, regardless of cache warmness,
regardless of how many inodes you want to reverse-lookup, this zdb command
takes between 1 and 2 seconds per filesystem, fixed.  In other words, the
operation of performing reverse-lookup per inode is essentially zero time,
but there is some kind of "startup" overhead. 

In theory at least, the reverse lookup could be equally as fast as a regular
forward lookup, such as "ls" or "stat".  But my measurements also show that
a forward lookup incurs some form of "startup" overhead.  A forward lookup
on an already mounted filesystem should require a few ms.  But in my example
below, it takes several hundred ms per snapshot, which means there's a
"warmup" period for some reason, to open up each snapshot.

Find, of course, scales linearly with the total number of directories/files
in the filesystem.  On my company filer, I got these results:

Just do a forward lookup
        time ls -d /tank/somefilesystem/.zfs/snapshot/*/some_object
        took 24 sec, on my 53 snapshots 
        (that's 0.45sec per snapshot)
Using a for loop and zdb to reverse lookup those things
        took 1m 3sec, on my 53 snapshots
        (that's 1.19 sec per snapshot)
Using "find -inum" to locate all those things ...
        I only let it complete 4 snapshots.  
        Took 33 mins per snapshot

So that's a marvelous proof of concept.  Yes, reverse lookup is possible,
and it's essentially infinitely faster than "find -inum" can be.  I have a
feeling a reverse-lookup application could be even faster, if it were an
application designed specifically for this purpose.  

Zdb is not a suitable long term solution for this purpose.  Zdb is only
sufficient here, as a proof of concept.  

Here's the problem with zdb:
man zdb
DESCRIPTION
     The zdb command is used by  support  engineers  to  diagnose
     failures and gather statistics. Since the ZFS file system is
     always consistent on disk and is self-repairing, zdb  should
     only be run under the direction by a support engineer.

     If no arguments are  specified,  zdb,  performs  basic  con-
     sistency  checks  on  the  pool and associated datasets, and
     report any problems detected.

     Any options supported by this command are  internal  to  Sun
     and subject to change at any time.

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to