> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> Each inode contain a link count. It seems trivially
> simple to me, that along with the link count in each inode, the
> filesystem could also store a list of which inodes link to it.
Others may have better ideas for implementation. But at least for a
starting point, here's how I imagine this:
The goal is to be always able to instantly locate all the previous snapshot
versions of any file or directory, regardless of whether or not that
filename, directory name, or any path leading up to that file or directory
may have ever changed. An additional goal is to obey security. Dont give
the user any information that they couldn't have found by other (slower)
means. In this described scenario, these goals has been achieved.
Currently, there's a .zfs directory, which is not a "real" directory. By
default, it's hidden until you explicitly try to access it by name.
Inside the .zfs directory, there's presently a "snapshot" directory, and
nothing else. Let's suppose my system has several snapshots. "snap1",
"snap2", "snap3", ... Then these appear as
/tank/.zfs/snapshot/{snap1,snap2,snap3,...} And inside there, are all the
subdirectories which lead to all the files.
Let there be also, an "inodes" directory next to the snapshot directory.
/tank/.zfs/snapshot
/tank/.zfs/inodes
Whenever a snap is created, let it be listed under both "snapshot" and
"inodes"
/tank/.zfs/snapshot/{snap1,snap2,snap3,...}
/tank/.zfs/inodes/{snap1,snap2,snap3,...}
If you simply "ls /tank/.zfs/inodes/snap1" then you see nothing. The system
will not generate a list of every single inode in the whole filesystem; that
would be crazy.
But, just as the ".zfs" directory was hidden and appears upon attempted
access, let there be text files, whose names are inode numbers, and these
text files only appear upon attempted access.
ls /tank/.zfs/inodes/snap1
(no result)
cat /tank/.zfs/inodes/snap1/12345
(gives the following results)
/tank/.zfs/snapshot/snap1/foo/bar/baz (which is the abs path to the
file having inode 12345)
And so, a mechanism has been created, so a user can do this:
ls -i /tank/exports/home/jbond/somefile.txt
12345
cat /tank/.zfs/inodes/snap1/12345
(result is: exports/home/jbond/Some-File.TXT)
Thus, we have identified the former name of somefile.txt and ...
cat /tank/.zfs/snapshot/snap1/exports/home/jbond/Some-File.TXT
Note: the above "ls -i ; cat" process is slightly tedious.
I don't expect many users to do this directly.
But I would happily automate and simplify this process
By coding zhist to utilize this technique automatically.
User could:
zhist ls somefile.txt
Result would be:
/tank/.zfs/snapshot/snap1/exports/home/jbond/Some-File.TXT
And of course, once the command-line verson of zhist
Can do that, there's no obstacle preventing the GUI frontend.
One important note:
Since you're doing a reverse mapping, from inode number to path name, it's
important to obey filesystem security. Fortunately, the process of
generating absolute path names from an inode number is handled by kernel,
and only after the complete absolute pathname has been generated, is
anything returned to the user. Which means the kernel has the opportunity
to test whether or not the user would have access to "ls" the specified
inode by pathname, before returning that pathname to the user. In other
words, if the user couldn't get that pathname via "find
/tank/.zfs/snapshot/snap1 -inum 12345" then the user could not get that
pathname via .zfs/inodes either.
The only difference is that the "find" command could run for a very long
time, yet the ".zfs/inodes" directory returns that same result nearly
instantly.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
