On Fri, Mar 07, 2008 at 10:46:40PM +0100, Miklos Szeredi wrote: > > > "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. A better example in terms of having more unix-like visible use would be hfsplus. It is even used as the native file system of a unix variant (apple's osx/darwin). For Linux, we synthetically create the whole dentry and inode separation. On disk, there is no logical separation. The primary key to find the metadata is parent directory id + filename, while the catalog id number (the equivalent of an inode number) is a secondary key with a separate index pointing to the real primary key. Structurally, this is all kept in a single catalog tree for the entire volume, and you build a key and do a search. If you look at the code for iget in hfsplus, you will find that it creates the secondary key of just the "inode" number and searches on that in the catalog. The result of that search is the thread record containing the real key consisting of the parent id and filename, which is then used to search for the actual data record. As a consequence of this structure, hard links are a horrible hack and are more like symlinks internally. Just to summarize, on hfsplus the information in the dentry is what we need to load the data for struct inode, while it takes extra work to find the data on disk if we don't have the information from the dentry. If you look at the code for hfsplus, it tries to act like it is a normal unix filesystem as much as possible but that does cause extra searches in the catalog. Brad Boyer flar@xxxxxxxxxxxxx -- 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
