I saw the following comment atop the iput
function:
/**
* iput - put an inode
* @inode: inode to put
*
* Puts an inode, dropping its usage count. If the inode use count hits
* zero, the inode is then freed and may also be destroyed.
*
* Consequently, iput() can sleep.
*/
To me that sounds like it's not "putting" anything, but "dropping" it. I'm aware of the drop_inode
function, which gets called from iput
in some cases, so the usage of the term "put" is even more confusing here.
The inode object represents all the information needed by the kernel to manipulate a file or directory. For Unix-style filesystems, this information is simply read from the on-disk inode. If a filesystem does not have inodes, however, the filesystem must obtain the information from wherever it is stored on the disk.
To look up an inode requires that the VFS calls the lookup() method of the parent directory inode. This method is installed by the specific filesystem implementation that the inode lives in.
A "dentry" in the Linux kernel is the in-memory representation of a directory entry; it is a way of remembering the resolution of a given file or directory name without having to search through the filesystem to find it.
put
is common terminology in kernel code for decrementing an object's reference count. It's the complement of get
, which increases the reference count. You can find it lots of places, not just with inodes.
Reference counts are used to keep shared objects from being destroyed as long as they're in use. Code using an object get
s the object, uses it, then put
s it to release it.
iput
is the opposite of iget
which searches for an inode,
allocates memory for it if necessary and returns a reference to the inode to the
caller.
iput
takes this inode "back", i.e. frees the memory if needed.
There is a reference counter system, such that one inode can be used
in parallel by more than one caller and can therefore
be only dropped (i.e. removed from memory) if there is no user of it
anymore (every user has called iput
).
/**
* iget_locked - obtain an inode from a mounted file system
* @sb: super block of file system
* @ino: inode number to get
*
* Search for the inode specified by @ino in the inode cache and if present
* return it with an increased reference count. This is for file systems
* where the inode number is sufficient for unique identification of an inode.
*
* If the inode is not in cache, allocate a new inode and return it locked,
* hashed, and with the I_NEW flag set. The file system gets to fill it in
* before unlocking it via unlock_new_inode().
*/
struct inode *iget_locked(struct super_block *sb, unsigned long ino)
Basically a process has a File Descriptor Table, which includes an file pointer point to the files the process open, the file pointer is actually a pointer point to an item of the Open File Table(which is maintained by kernel). And the Open File Table will have an inode pointer point to the item in I-node Table(also maintained by kernel). The I-node table contains all the information of file(file info and pointer to blocks store file data)
When you open a file, an inode item is added to the I-node table. In order to achieve and free inode faster, the system will maintain an inode cache. When the I-node Table needs a new item, it will use iget() to get an inode from the cache, and when a file is closed, it will return the related inode to the cache using iput().
So the iput() means PUT the inode to the inode cache, and DROPPING means reduce the reference of an inode in the I-node Table. Refer to this page to get more details.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With