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
pgp2nCFDIdxia.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
