lkml.org 
[lkml]   [1999]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: structure dentry help...
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans