> From: Jonathan Adams [mailto:jonathan.ad...@oracle.com] > > Understood; though you can always "check" (i.e. > stat(".zfs/path/object") and > see if the inode # matches). In most cases, the file will probably not > have > moved. I agree that searching the whole space is hard.
Understood. Most of the time, you'll be correct if you assume the path name of an object hasn't changed in between snapshots. You can verify the correctness of this guess by checking the inode number. But if the guess happens to be wrong, there's no reliable way (right now) to perform a reverse lookup, and *locate* the former name/location of that inode, if it existed at all. > > zhist would automate the process: Lookup inode number of an object > in the > > present filesystem, locate the .zfs directory for this filesystem, > find all > > the snapshots of this object in previous snapshots, check the mtime > of each > > one, and only print out unique results which are accessible by the > current > > user. All of which is to be completed ... very quickly. > > Ah; have you looked at > http://arc.opensolaris.org/caselog/PSARC/2010/105/, > the ZFS diff ARC case? It wouldn't work over CIFS or NFS, but would > give > you the correct name. Ahhh. I knew somebody was working on zfs diff, but that was all I knew. Thanks for the link. I may wish to ask them some questions. More likely, I'll just admit I'm getting nowhere right now, and fallback to just assuming the path name hasn't changed, and try to get more attention once something is actually *working.* > That's not (quite) true; ZFS does keep track of parents, and since you > are > presumably starting from a path, you can certainly get a path->inode > mapping. Ummm... Are you sure? Maybe that was just phrased wrong? Given that you know the name of some object in the present filesystem, and you want to locate the snapshots of that object in a previous snapshot of the filesystem, but you can't assume it remained in the unchanged absolute path name... Yes, you can lookup its inode number. ls -di foo Theoretically, if given proper permissions and some function to call, you could open that inode number in a former snapshot without knowing its absolute path name, and if it's a directory, you could recursively follow '..' to identify its complete path. But so far I've had the assumption (numerously supported) that file inodes don't currently have any reference to their parent(s). In fact, one person on zfs-discuss (Peter Jeremy) said a file could be linked to 32767 times, but usually it'll be a small number ... single digits ... and an inode number is 8 bytes long. Which means you'd need flexible storage size, in every inode, typically less than 80 bytes, but possibly up to 256kbytes storage per file inode, to be able to reference all of its parents. > > * There is a potential security risk, so even the reverse directory > lookup > > by inode, can only be done by root. > > What I don't understand is what you think an in-kernel solution can do > which is better than a find(1) invocation. The kernel doesn't need to know the path name to an object; as long as the kernel knows the device and inode number of an object, it can open that object. If the object contains a reference to its parent inode (directories do) then the kernel can very quickly recursively open all those parents, and identify the absolute path name of the object. In near-zero time. Find, unfortunately, must recursively walk *down* the tree, inspecting every inode in the whole filesystem. This could be an extremely long time. _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
