> > > 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. About vfsmount, I have no idea. > 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). Fuse is a strange beast, it uses identifiers stored in the inode to communicate with userspace, but then converts them back to paths on the library interface (there's an alternative, much less popular API, where filesystems may use the IDs natively). LUFS was a project very similar to fuse, and it used paths on the kernel interface. The project died, but not because it was fundamentally flawed, but because fuse was more stable, and better in other respects. Both projects used the "path based API" concept, which distinguished them from eariler attempts at userspace filesystems, and which made both of them very popular. > 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. Right, and while CIFS is not the cleanest codebases in the kernel, to say the least, this particular usage of dentries is perfectly valid. > > > 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. FAT? AFAIK there isn't any inode, metadata is stored directly in the directory entry. I know, fat doesn't use dentries either, but that's beside the point. The struct inode is just a way to cache metadata (and whatever the filesystem wants), and dentries are a way to cache the names. Using the name is certainly a valid thing for a filesystem to do, so passing down the dentry is the right thing to do. > I've even had someone ask me once if they could just open a file by > inode. Yes, comes up once in a while, and it's a rather stupid idea. Userspace shouldn't know about inodes at all. But because of hard links it does need i_ino, which has been a constant source of headaches over the years. 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
