Messages in this thread |  | | | From | dony <> | | Subject | Re: structure dentry help... | | Date | Tue, 2 Nov 1999 00:02:37 +0800 |
| |
On Mon, 01 Nov 1999, Alexander Viro wrote: > On Mon, 1 Nov 1999, hechengdong wrote: > > > Hi, > > > > Now I am learning linux kernel sources. Can anyone point out to me > > the detailed information about _DENTRY_ structure? I can not guess > > what's the actual meaning of its member, such as d_parent,d_mounts, > > d_covers etc. > > It's slightly messy, but the current layout looks so: > d_parent: points to the parent node in the tree.
Does d_parent mean that it points to this dentry's parent node? I am really confused.
> d_subdirs: anchor of the cyclic list that goes through all > children
"all children " means whose children? this dentry's childrenor this dentry's parent's children? In the Dcache.h, "d_subdirs" is explained as "our children". I am very much confused.
> d_children: that's where the aforementioned list sits (i.e we > have parent's d_subdirs <-> 1st child's d_children <-> 2nd child's > d_children <-> ... <-> parent's d_subdirs).
In Dcache.h, "d_children" is explained as "child of parent list". that is to say, it points to this dentry's parent's children , instead of pointing to this dentry's own children? right? If so, why can d_subdirs and d_child make up of a cyclic list? What's the difference or relationship between them?
> d_mounts: who overlaps it (root of the tree mounted atop of our > dentry) _or_ dentry itself if it's not a mountpoint; in other words it's a > step upwards. > d_covers: opposite.
Sorry, I still cannot distinguish between d_mounts and d_covers. Say a example, if /dev/cdrom is mounted under /mnt , then what does d_mounts and d_covers mean respectively? What's the difference or relationship between them?
> d_inode: inode corresponding to dentry. May be NULL (for negative > dentries). > d_alias: cyclic list of dentries that have the same d_inode. It's > anchored in the d_inode->i_dentry. This looks like d_parent/d_children/d_subdirs > structure. Warning: it's badly abused in several filesystems and it is > going to change. d_inode will stay as it is, but you will be safer if > you'll stay out of the d_alias (and i_dentry in struct inode). > > d_hash: hash chains. Anchored in hash table. > > d_count: reference counter. Number of pointers to dentry. Pointers > from cyclic lists do not count. > > d_name: name of dentry. > > d_op: methods. > > The rest: bloody mess. > > Notice that: > a) we can't handle more than one dentry for a directory. VFS does > not allow that, partially due to the d_alias abuse in NFS and friends. > b) _all_ work with dcache still requires big lock. Again, fixing > that will require cleanup of d_alias/i_dentry mess. > c) we have only two states for dentry - hashed and unhashed. > Life would be much easier if we had finer separation (e.g. special case > for dentry in process of lookup()). To be changed. > d) all locking is done on inode level. It makes race prevention > much harder. > e) cached_lookup() acts funny if we find a directory dentry _and_ > attempt to revalidate it gives negative. Compare with the case of > non-directory. Handling of invalidation is tied with the d_alias/i_dentry > problem - same offenders hold the thing. It will take a large and nasty > rewrite. -- #################################### Linux is more powerful than windows dony.he@huawei.com.cn #################################### - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |