On 2010-Apr-30 10:24:14 +0800, Edward Ned Harvey <solar...@nedharvey.com> wrote: >Each inode contain a link count. In most cases, each inode has a >link count of 1, but of course that can't be assumed. 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. >If link count is 2, then there's a list of 2 inodes, which are the >"parents" of this inode.
I'm not sure exactly what you are trying to say here but it don't think it will work. In a Unix FS (UFS or ZFS), a directory entry contains a filename and a pointer to an inode. The inode itself contains a count of the number of directory entries that point to it and pointers to the actual data. There is currently no provision for a reverse link back to the directory. I gather you are suggesting that the inode be extended to contain a list of the inode numbers of all directories that contain a filename referring to that inode. Whilst I agree that this would simplify inode to filename mapping and provide an alternate mechanism for checking file permissions, I think you are glossing over the issue of how/where to store these links. Whilst files can have a link count of 1 (I'm not sure if this is true in "most" cases), they can have up to 32767 links. Where is this list of (up to) 32767 "parent" inodes going to be stored? >In which case, it would be trivially easy to walk back up the whole >tree, almost instantly identifying every combination of paths that >could possibly lead to this inode, while simultaneously correctly >handling security concerns about bypassing security of parent >directories and everything. Whilst it's trivially easy to get from the file to the list of directories containing that file, actually getting from one directory to its parent is less so: A directory containing N sub-directories has N+2 links. Whilst the '.' link is easy to identify (it points to its own inode), distinguishing between the name of this directory in its parent and the '..' entries in its subdirectories is rather messy (requiring directory scans) unless you mandate that the reference to the parent directory is in a fixed location (ie 1st or 2nd entry in the parent inode list). >It seems too perfect and too simple. Instead of a one-directional >directed graph, simply make a bidirectional. There's no significant >additional overhead as far as I can tell. It seems like it would >even be easy. Well, you need to find somewhere to store up to 32K inode numbers, whilst having minimal space overhead for small numbers of links. Then you will need to patch the vnode operations underlying creat(), link(), unlink(), rename(), mkdir() and rmdir() to manage the backlinks (taking into account transactional consistency). -- Peter Jeremy
pgpLmGCkPtpSv.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
