If you're just wanting to do something like the netapp .snapshot (where it's in every directory), I'd be curious if the CIFS shadow copy support might already have done a lot of the heavy lifting for this. That might be a good place to look
On Mon, May 3, 2010 at 7:25 PM, Peter Jeremy <peter.jer...@alcatel-lucent.com> wrote: > On 2010-Apr-30 21:56:46 +0800, Edward Ned Harvey <solar...@nedharvey.com> > wrote: >>How many bytes long is an inode number? I couldn't find that easily by >>googling, so for the moment, I'll guess it's a fixed size, and I'll guess >>64bits (8 bytes). > > Based on a rummage in some header files, it looks like it's 8 bytes. > >>How many bytes is that? Would it be exceptionally difficult to extend >>and/or make variable? > > Extending inodes increases the amount of metadata associated with a > file, which increases overheads for small files. It looks like a ZFS > inode is currently 264 bytes, but is always stored with a dnode and > currently has some free space. ZFS code assumes that the physical > dnode (dnode+znode+some free space) is a fixed size and making it > variable is likely to be quite difficult. > >>One important consideration in that hypothetical scenario would be >>fragmentation. If every inode were fragmented in two, that would be a real >>drag for performance. Perhaps every inode could be extended (for example) >>32 bytes to accommodate a list of up to 4 parent inodes, but whenever the >>number of parents exceeds 4, the inode itself gets fragmented to store a >>variable list of parents. > > ACLs already do something like this. And having parent information > stored away from the rest of the inode would not impact the normal > inode access time since the parent information is not normally needed. > > On 2010-Apr-30 23:08:58 +0800, Edward Ned Harvey <solar...@nedharvey.com> > wrote: >>Therefore, it should be very easy to implement proof of concept, by writing >>a setuid root C program, similar to "sudo" which could then become root, >>identify the absolute path of a directory by its inode number, and then >>print that absolute path, only if the real UID has permission to "ls" that >>path. > > It doesn't need to be setuid. Check out > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/pwd.c > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/pwd.c > (The latter is somewhat more readable) > >>While not trivial, it's certainly possible to extend inodes of files, to >>include parent pointers. > > This is a far more significant change and the utility is not clear. > >>Also not trivial, it's certainly possible to make all this information >>available under proposed directories, ".zfs/inodes" or something similar. > > HP Tru64 already does something like this. > > -- > Peter Jeremy > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
