Demystifying Linux 101: File System
“Everything is a file”
This is one of the key concepts that drove the Unix operating system to the success. A file provides a common abstraction to the wide range of I/O resources such as documents, directories, hard-drives, CD-Roms, modems, keyboards, printers, monitors, terminals and even some inter-process and network communications.
•Your computer memory is a file object located in /dev/mem.
•Your first hard disk is a file object located in /dev/sda.
(Note that Linux kernel is responsible for exposing those information to use as a file.)
Inode
The inode (index node) is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. Each inode stores the attributes and disk block locations of the object’s data. An inode contains a File Controle Block (FCB) which has the details about permissions, owner, group, size, access/modify times, etc related to the content stored inside the inode. Inode content is stored in the disk blocks and the inode has pointers that refer to this disk blocks.
FCB contains the following information.
- File type: a regular file or a directory
- Permissions to that file: read, write, execute
- Link count: The number of hard links relative to an inode
- User ID: the owner of the file
- Group ID: group owner
- Size of file: or major/minor number in case of some special files
- Timestamp: access time, modification time and (inode) change time
- Attributes: immutable’ for example
- Access control list: permissions for special users/groups
- Link to the location of the file stored in a disk block
- Other metadata about the file
As you have noticed in the above FCB does not contain a name attribute. So that we can have multiple names for a single inode and that leads to the concept called hard-link which will discuss later.
You may have noticed that there is a property called “File type” in the FCB. This is to denote whether the inode is a file or a directory object.
If we consider tree structure of the Linux file system, we can denote it as the above diagram. Where root itself is an inode directory that stores the all other file and directory information. “file1” is a file inode located in the /home/user/ directory path. When a file1 is created, it is assigned both name and an inode number which is unique to the file system. Both name and the inode number is stored inside the directory (user inode). A directory inode holds only the names of the files that appear to the user and their inode numbers, the file inode(file1) contains all the other information describing a file. And the name that references an inode is called hard-link. So the main thing here need to be clarified is that a file’s name belongs to the directory inode and the file content is stored in a separate file inode.
If you want to find out attribute information of a file, that information is stored in the inode of the object (file inode), not in the directory inode. You must first use the inode number associated with the file object to find the file attributes.
“ls” or “ls -i” command only need to read the names and inode numbers from the directory — no additional inode access is needed because no other attributes are being queried. Reading the one directory inode is sufficient.
“ls -l” command has to display attribute information for every object named in the directory, so it has to do a separate inode lookup to find out the inode attribute information for every inode in the directory. A directory with 1000 names in it requires 1000 separate inode lookups to fetch the attributes!
(This is why ls or ls -i are much faster than ls -l on a large directory)
We can use the “stat” command to retrieve the inode information of a file as shown below.
File permission conflicts associated with this behavior.
In this example, I have created a directory “dir1” which has the read and execute permission for the current user. (d r-x rwx r-x denotes that its a directory, the user has r-x permission, the user group has rwx permission and others have r-x permission.) And a text file “file1.txt” which has read-write permission to the current user “kasun” inside the “dir1”.
But when I try to delete the “file1.txt” inside “dir1” directory, permission was denied even though the “file1.txt” has the write permission to delete.
The reason for this behavior is that the “dir1” directory inode which stores the file name does not have the write permission to delete the file name.
Let's add write permission to the directory and remove all the permission in the file for the current user.
Then try to delete the “file1.txt”.
Here we were able to delete the “file1.txt” from the “dir1” directory by giving write permission to the directory which holds the file even though the user has no permission to the file.
The link between the file name and the inode is called a hard-link. Since file name and the inode are separate entities, one inode can have multiple names. The number of links that an inode has denotes by the link-count in FCB. The ln command can create a new name (a new hard link) in a directory for an existing file inode, increasing the file’s inode link count. The rm command removes a name (a hard link) from a directory, decreasing the file’s inode link count.
When the link count for an inode goes to zero, the inode has no names and the inode is freed and recycled and all the storage and data used by the item are released.
The rm command does not remove files; it removes names for files. When all the names for a file inode are removed, the system removes the inode itself and releases all the disk space.
As long as an inode has at least one name in some directory (a non-zero link count), it cannot be freed up and released.
References;
