Dentry Objects

We mentioned in Section 12.1.1 that the VFS considers each directory a file that contains a list of files and other directories. We shall discuss in Chapter 17 how directories are implemented on a specific filesystem. Once a directory entry is read into memory, however, it is transformed by the VFS into a dentry object based on the dentry structure, whose fields are described in Table 12-5. The kernel creates a dentry object for every component of a pathname that a process looks up; the dentry object associates the component to its corresponding inode. For example, when looking up the /tmp/test pathname, the kernel creates a dentry object for the / root directory, a second dentry object for the tmp entry of the root directory, and a third dentry object for the test entry of the /tmp directory.

Notice that dentry objects have no corresponding image on disk, and hence no field is included in the dentry structure to specify that the object has been modified. Dentry objects are stored in a slab allocator cache called dentry_cache; dentry objects are thus created and destroyed by invoking kmem_cache_alloc( ) and kmem_cache_free( ) .

Table 12-5. The fields of the dentry object

Type

Field

Description

atomic t

d count

Dentry object usage counter

unsigned int

d flags

Dentry flags

struct inode *

d inode

Inode associated with filename

struct dentry *

d parent

Dentry object of parent directory

struct list head

d hash

Pointers for list in hash table entry

struct list head

d lru

Pointers for unused list

struct list head

d child

Pointers for the list of dentry objects included in parent directory

struct list head

d subdirs

For directories, list of dentry objects of subdirectories

struct list head

d alias

List of associated inodes (alias)

int

d mounted

Flag set to 1 if and only if the dentry is the mount point for a filesystem

struct qstr

d name

Filename

unsigned long

d time

Used by d revalidate method

struct dentry operations*

d op

Dentry methods

struct super block *

d sb

Superblock object of the file

unsigned long

d vfs flags

Dentry cache flags

void *

d fsdata

Filesystem-dependent data

unsigned char *

d iname

Space for short filename

Each dentry object may be in one of four states: Free

The dentry object contains no valid information and is not used by the VFS. The corresponding memory area is handled by the slab allocator.

Unused

The dentry object is not currently used by the kernel. The d_count usage counter of the object is 0, but the d_inode field still points to the associated inode. The dentry object contains valid information, but its contents may be discarded if necessary in order to reclaim memory.

In use

The dentry object is currently used by the kernel. The d_count usage counter is positive and the d_inode field points to the associated inode object. The dentry object contains valid information and cannot be discarded.

Negative

The inode associated with the dentry does not exist, either because the corresponding disk inode has been deleted or because the dentry object was created by resolving a pathname of a nonexisting file. The d_inode field of the dentry object is set to null, but the object still remains in the dentry cache so that further lookup operations to the same file pathname can be quickly resolved. The term "negative" is misleading since no negative value is involved.

+12 -3

Responses

  • alexandra
    How dentry object is used to resolve the pathname?
    2 years ago

Post a comment