diff options
Diffstat (limited to 'doc/developer-guide/datastructure-inode.md')
-rw-r--r-- | doc/developer-guide/datastructure-inode.md | 61 |
1 files changed, 28 insertions, 33 deletions
diff --git a/doc/developer-guide/datastructure-inode.md b/doc/developer-guide/datastructure-inode.md index a340ab9ca8e..45d7a941e5f 100644 --- a/doc/developer-guide/datastructure-inode.md +++ b/doc/developer-guide/datastructure-inode.md @@ -1,6 +1,6 @@ -#Inode and dentry management in GlusterFS: +# Inode and dentry management in GlusterFS: -##Background +## Background Filesystems internally refer to files and directories via inodes. Inodes are unique identifiers of the entities stored in a filesystem. Whenever an application has to operate on a file/directory (read/modify), the filesystem @@ -41,11 +41,10 @@ struct _inode_table { }; ``` -#Life-cycle +# Life-cycle ``` - inode_table_new (size_t lru_limit, xlator_t *xl) - +``` This is a function which allocates a new inode table. Usually the top xlators in the graph such as protocol/server (for bricks), fuse and nfs (for fuse and nfs mounts) and libgfapi do inode managements. Hence they are the ones which will @@ -59,11 +58,8 @@ new inode table. Thus an allocated inode table is destroyed only when the filesystem daemon is killed or unmounted. -``` - -#what it contains. -``` +# what it contains. Inode table in glusterfs mainly contains a hash table for maintaining inodes. In general a file/directory is considered to be existing if there is a corresponding inode present in the inode table. If a inode for a file/directory @@ -76,21 +72,21 @@ size of the hash table (as of now it is hard coded to 14057. The hash value of a inode is calculated using its gfid). Apart from the hash table, inode table also maintains 3 important list of inodes -1) Active list: +1. Active list: Active list contains all the active inodes (i.e inodes which are currently part of some fop). -2) Lru list: +2. Lru list: Least recently used inodes list. A limit can be set for the size of the lru list. For bricks it is 16384 and for clients it is infinity. -3) Purge list: +3. Purge list: List of all the inodes which have to be purged (i.e inodes which have to be deleted from the inode table due to unlink/rmdir/forget). And at last it also contains the mem-pool for allocating inodes, dentries so that frequent malloc/calloc and free of the data structures can be avoided. -``` -#Data structure (inode) + +# Data structure (inode) ``` struct _inode { inode_table_t *table; /* the table this inode belongs to */ @@ -108,7 +104,7 @@ struct _inode { struct _inode_ctx *_ctx; /* place holder for keeping the information about the inode by different xlators */ }; - +``` As said above, inodes are internal way of identifying the files/directories. A inode uniquely represents a file/directory. A new inode is created whenever a create/mkdir/symlink/mknod operations are performed. Apart from that a new inode @@ -128,9 +124,9 @@ inodes are those inodes whose refcount is greater than zero. Whenever some operation comes on a file/directory, and the resolver tries to find the inode for it, it increments the refcount of the inode before returning the inode. The refcount of an inode can be incremented by calling the below function - +``` inode_ref (inode_t *inode) - +``` Any xlator which wants to operate on a inode as part of some fop (or wants the inode in the callback), should hold a ref on the inode. Once the fop is completed before sending the reply of the fop to the above @@ -139,18 +135,18 @@ zero, it is removed from the active inodes list and put into LRU list maintained by the inode table. Thus in short if some fop is happening on a file/directory, the corresponding inode will be in the active list or it will be in the LRU list. -``` -#Life Cycle + +# Life Cycle A new inode is created whenever a new file/directory/symlink is created OR a successful lookup of an existing entry is done. The xlators which does inode management (as of now protocol/server, fuse, nfs, gfapi) will perform inode_link operation upon successful lookup or successful creation of a new entry. - +``` inode_link (inode_t *inode, inode_t *parent, const char *name, struct iatt *buf); - +``` inode_link actually adds the inode to the inode table (to be precise it adds the inode to the hash table maintained by the inode table. The hash value is calculated based on the gfid). Copies the gfid to the inode (the gfid is @@ -160,7 +156,7 @@ A inode is removed from the inode table and eventually destroyed when unlink or rmdir operation is performed on a file/directory, or the the lru limit of the inode table has been exceeded. -#Data structure (dentry) +# Data structure (dentry) ``` struct _dentry { @@ -170,22 +166,22 @@ struct _dentry { char *name; /* name of the directory entry */ inode_t *parent; /* directory of the entry */ }; - +``` A dentry is the presence of an entry for a file/directory within its parent directory. A dentry usually points to the inode to which it belongs to. In glusterfs a dentry contains the following fields. -1) a hook using which it can add itself to the list of +1. a hook using which it can add itself to the list of the dentries maintained by the inode to which it points to. -2) A hash table pointer. -3) Pointer to the inode to which it belongs to. -4) Name of the dentry -5) Pointer to the inode of the parent directory in which the dentry is present +2. A hash table pointer. +3. Pointer to the inode to which it belongs to. +4. Name of the dentry +5. Pointer to the inode of the parent directory in which the dentry is present A new dentry is created when a new file/directory/symlink is created or a hard link to an existing file is created. - +``` __dentry_create (inode_t *inode, inode_t *parent, const char *name); - +``` A dentry holds a refcount on the parent directory so that the parent inode is never removed from the active inode's list and put to the lru list (If the lru limit of the lru list is exceeded, there is @@ -212,15 +208,14 @@ deleted due to file removal or lru limit being exceeded the inode is retired purge list maintained by the inode table), the nlookup count is set to 0 via inode_forget api. The inode table, then prunes all the inodes from the purge list by destroying the inode contexts maintained by each xlator. - +``` unlinking of the dentry is done via inode_unlink; void inode_unlink (inode_t *inode, inode_t *parent, const char *name); - +``` If the inode has multiple hard links, then the unlink operation performed by the application results just in the removal of the dentry with the name provided by the application. For the inode to be removed, all the dentries of the inode should be unlinked. -``` |