On Fri, 2008-03-07 at 21:24 +0100, Miklos Szeredi wrote: > > This isn't hiding information from the lower layers. The only use of the > > dentry is much higher up in the call chain. If you take a look at > > sys_chmod (another inode attr modifying call) the dentry is really only > > used in > > > > sys_chmod->chown_common->notify_change->fsnotify_change > > And i_op->setattr(). Which is in the same boat as setxattr since most filesystems just grab the inode from the dentry that is passed in (although I didn't look as extensively as I did with setxattr). This is another example of needlessly passing a dentry where an inode is sufficient and correct. So once again the only real purpose for the dentry to be there is fsnotify_change. I also don't see a reason for getattr to take a vfsmount and a dentry. Even fuse_getattr does nothing with the vfsmount and only pulls the inode from the dentry to pass into fuse_do_getattr(which takes an inode). The libfs code for simple_getattr does nothing with them as well. Can anyone cite a real use for all of this? It seems that the pervasiveness of dentries in all the file system code isn't justified. Note I haven't looked through every file system (yet) but from what I've seen there are no real users of these dentries except for CIFS. > > > > > The operations that actually change the inode metadata on disk do not > > touch the dentry at all except to get the inode(rightly so since it is > > an INODE operation). > > "Disk" and "inode" are concepts specific to a certain class of > filesystems, but make no sense for a different set. What makes sense > for all filesystems is the hierarchy of path components, which is what > dentries represent. Would you care to elaborate? Perhaps an example in tree (or out). Path names are nothing but a user friendly way of telling the file system which inode you want. I've even had someone ask me once if they could just open a file by inode. > > Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
