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/