A file system is a mechanism used by the operating system to store data. The nature of a file system determines how files are named, stored, and retrieved for use in an operating system. Every operating system uses a file system to organize files. All file systems maintain one or more internal data structures. These internal data structures are known as metadata. The main function of metadata is to organize data in a way that it is readily accessible to users.
Common Features of a File System
The features of a file system are discussed in the following sections.
Data Storage
The most basic feature of a file system is data storage. However, every file system has its own way of storing data. For example, the file system used by Windows operating system stores data as characters whereas a UNIX/Linux file system stores data in blocks.
File Operations
Apart from storing data, the file system also allows users to read and write data on files.
File-naming Conventions
Each file system has certain file-naming conventions that need to be followed. File-naming conventions define the number of characters allowed in a file name and the characters that cannot be used in a file name.
File Ownership
Any user can create a file on a Linux system, and the user who creates a file is considered its owner. The owner of a file can set access permissions for that file.
File Attributes
Each file created on a file system possesses certain attributes. These attributes define what actions can be performed on the file. The attributes of a file are read, write, and execute. In Linux, these attributes are denoted by the letters r, w, and x respectively. When you list the contents of a directory using the ls command with the –l option, the attributes of the files in the directory are displayed. Consider the following example:
 |
-rw-r--r-- 2 root root 15 May 2 17:04 aaa
-rw-r--r-- 1 root root 17 May 2 17:04 bbb
-rw-r--r-- 1 root root 12 May 2 17:04 ccc
-rw-r--r-- 2 root root 15 May 2 17:04 hard
drwxr-xr-x 2 root root 4096 May 4 16:44 mydir
|
In Listing 1-1-1, the first column displays the attributes of a file.
Table 1-1-1 specifies the actions that are defined by a particular attribute.
| Attribute | Explanation |
|---|---|
| r | Specifies that the contents of the file can only be read. |
| w | Specifies that the contents of the file can be modified. |
| x | Specifies that the file can be executed. However, this attribute is useful for executable files only. |
| d | Specifies that the listed item is a directory. |
Open table as spreadsheetFile Permissions
File permissions determine the attributes of a file for different users. Only the owner of a file has the right to alter the permissions of a file. The only exception to this rule is the root user who has the right to alter the permissions of any file in the file system. File permissions can be set by the owner of the file to grant or deny access to a particular file. While setting permissions, the owner can add or remove an attribute of a file.
Linux File Systems
Linux supports a variety of file systems. The default file system used by the Red Hat Linux operating system is ext2. However, if you are using version 7.2 of Red Hat Linux, you have an option of installing the operating system on an ext3 file system. A file named filesystems located in the /proc directory contains a list of supported file systems. The contents of the filesystems file are displayed in Listing 1-1-2:
|
[root@localhost dummy]# cat /proc/filesystems
nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext2
iso9660
nodev devpts
ext3
nodev usbdevfs
nodev autofs
nodev binfmt_misc
vfat
|
Inode
Every file located in a Linux file system is represented by an inode. An inode is a data structure that is responsible for storing file-related information. A file on a Linux file system can be identified using the inode number. However, a file system has a predefined set of inode numbers. This indicates that only fixed number of files can be created. On Linux, you can view the inode numbers assigned to files by using the ls –i command. Here’s an example:
[root@localhost dummy]# ls -i
453267 aaa 453269 bbb 453272 ccc
In the preceding example, the numbers 453267, 453269, and 453272 are the inode numbers assigned to the files aaa, bbb, and ccc, respectively. An inode typically consists of the following information about the file:
-
User ownership
-
Group ownership
-
Access mode (read, write, and execute permissions)
-
File type
-
Timestamp
-
File size
-
Pointers to data blocks
In Linux, practically everything can be called a file. Even directories and devices are called files. In addition to pointing to files, an inode can also point to links. Links play a major role in Linux. You can create links in Linux by using the ln command. You can also have several file names associated with a single inode. The inode also contains a link count. When a file is created for the first time, this link count is 1. This count gets incremented by 1 when a link to the file is created. Similarly, when a link from the file is deleted, the kernel decrements the link count by 1, but does not remove the file itself, until the link count becomes zero.
Links are used to point to an existing file. Links are of two types, hard links and symbolic links (also known as soft links).
Hard Links
You create a hard link for a file by using the ln command. Hard links can only be used within a single file system. When you create a hard link, for a file specifying another file name, another instance of the existing file is created. As a result, any changes made to the new file also apply to the original file. For example, you create a hard link named hard for a file named aaa. All changes made to the new file named hard will also apply to the file aaa. Consider the following example:
[root@localhost dummy]# ln aaa hard
The preceding command creates a hard link to the file aaa. An important thing to remember is that hard, in the above example, is a link and not a new file. When you create a hard link, a new file is not created. The value "hard" is just the name assigned to the link. The name "hard" actually points to the file aaa because it shares the same inode number. The inode number for the file aaa is as follows:
[root@localhost dummy]# ls -i
453267 aaa 453269 bbb 453272 ccc 453267 hard
The output of the ls –i command suggests that the file hard is actually the file aaa. Both these files share the same inode number, indicating that they share the same location on the hard disk.
Symbolic Links
Symbolic links can also be created using the ln command. However, you need to use the –s option along with it. Consider the following example where a symbolic link named soft is created for the file named bbb.
[root@localhost dummy]# ln -s bbb soft
Symbolic links are depicted using ->. Consider the following output of the ls –li command.
[root@localhost dummy]# ls –li
|
total 20
453267 -rw-r--r-- 3 root root 15 May 2 17:04 aaa
453269 -rw-r--r-- 1 root root 17 May 2 17:04 bbb
453272 -rw-r--r-- 1 root root 12 May 2 17:04 ccc
453267 -rw-r--r-- 3 root root 15 May 2 17:04 hard
453265 lrwxrwxrwx 1 root root 3 May 2 17:59 soft ->bbb
|
In Listing 1-1-3, notice that:
-
The symbolic link is depicted using -> characters.
-
The character l, which appears before the permissions, suggests that the listed file is a symbolic link.
The inode number that represents bbb is different from the inode number that represents the file soft. This means that when you create a soft link, a new file is created. This file contains information about the inode number of the original file. Therefore, when you try opening the file soft, the file named bbb is opened.
-
The user, group, and others have read, write, and execute permissions on the link.
There are a few advantages of using symbolic links over hard links. They are as follows:
-
Symbolic links can be created across file systems.
-
Symbolic links can point to any type of file.
-
Symbolic links occupy less disk space than hard links.
Working of a Linux File System
You will now learn how a Linux file system operates. When a file is created, the data blocks allocated to a file are stored in its inode. The following list explains what happens when a user requests an I/O operation on the file:
-
The current offset is converted to a block number. This is done by the kernel code.
-
Next, the kernel uses this block number as an index in the block addresses table.
-
Then, the kernel reads or writes the physical block.
-
Later, when a process uses a pathname, the kernel code searches in the directories until it finds the corresponding inode number.
-
Finally, after converting the name to an inode number, the same inode number is used to cater to subsequent requests that demand performing specific tasks on the file.
During a pathname to inode conversion in case of symbolic links, the kernel replaces the name of the link with its contents, which is the name of the target file. Next, the kernel restarts the pathname interpretation.
Using File Systems in Linux
The concept of file systems in Linux is very different from that in Windows. In Linux, you need to mount a file system before using it. For example, you can access the files on your CD-ROM only after it is mounted. Mounting allows flexibility, so that the files on a file system could be read-only or could be prevented from being executed for greater security.
Server Load
Keeping file systems unmounted when not in use helps save server time and resources. When there are fewer mounted file systems, the load on the server is minimal. In Linux, you need to mount a file system before using it. For example, you cannot access the files on your CD-ROM unless the CD-ROM is mounted. The concept of mounting can be quite flexible, allowing files on that file system to be mounted for read-only use, or prevent files on that file system from being executed, leading to enhanced security.
Security
When you do not need a file system, you can simply unmount it. This is particularly useful from the security point of view. An unmounted file system is inaccessible and, therefore, less vulnerable to security threats.
Mounting and Unmounting a File System
Mounting and unmounting file systems in Linux is a simple task. But before discussing how file systems in Linux are mounted, it is important to examine a file named fstab.
The /etc/fstab File
The fstab file resides in the /etc directory. This file contains descriptive information about various file systems. The system administrator of the Linux system should take special care in maintaining this file. This file is read every time a system is started. Each file system entry in this file is specified in a separate line. The order of entries in this file is important because whenever you run file system-specific commands to mount, unmount, or check the file system, the entries in this file are sequentially read by the operating system. This file contains the following information:
-
The file systems that can be mounted on your system
-
The location where the file system will be mounted
-
The user who can mount the file system
-
The permissions with which the file system will be mounted
Consider the contents of a sample /etc/fstab file that is displayed in Listing 1-1-4:
|
[root@localhost dummy]# cat /etc/fstab
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/hda2 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
|
The contents of the /etc/fstab file can be divided into six fields. The fields are as follows:
-
fs_spec: This field describes the file system to be mounted. The file system can be a block special device or a remote file system.
-
fs_file: This field specifies the mount point. The mount point is the directory on which the file system can be mounted.
-
fs_vfstype: This field is used to specify the type of file system to be mounted.
-
fs_mntops: This field is used to specify the mount options that must be used to mount the particular file system.
-
fs_freq: This field is used to specify whether the specified file system should be backed up. The value 1 signifies that the file system can be backed up when the dump backup utility is used. The value 0 signifies that the particular file system will not be backed up when the dump utility is used.
-
fs_passno: This field is used to specify which file systems must be checked first when the system is restarted. Every time the system is booted, the file systems on the Linux system are checked for integrity. This field can be used to set the priority using which the file systems must be checked at the time of restarting the computer. The root file system should always have the option "1" set. This indicates that the root file system must be checked for integrity on a priority basis. Other file systems of the Linux system should have an fs_passno value of 2 to indicate that they should be checked only after the root file system is checked.
The mount and umount Commands
You can mount and unmount file systems from the console by issuing commands. To mount a file system, you can use the mount command. The syntax for the mount command is:
#mount –t type device directory
In the preceding syntax:
-
–t is used to indicate that the type of file system that will be mounted will be specified.
-
type signifies the type of the file system that will be mounted.
-
device is the name of the device that will be mounted.
-
directory is the name of the directory on which the file system will be mounted.
Although it is advisable to follow the preceding syntax, it is possible to mount a file system simply by specifying the mount point. For example, to mount a CD-ROM drive, you can specify the following command:
#mount /mnt/cdrom
Just as the mount command is used to mount a file system, the umount command is used to unmount a file system. When you use the umount command, the specified file system is detached from the file hierarchy. The syntax for the umount command is as follows:
# umount –t type device directory
In the preceding syntax:
-
–t is used to indicate that the file system type will be mentioned.
-
type specifies the type of file system that will be unmounted.
-
device specifies the name of the device that will be unmounted.
-
directory specifies the directory from which the file system will be unmounted.
Although you can use the options specified in the preceding syntax while unmounting a file system, a file system can also be unmounted simply by specifying the mount point. For example, to unmount a CD-ROM, you can specify the following command:
#umount /mnt/cdrom
Introducing VFS
There are a number of file systems that are supported by the Linux kernel. As a result, the Linux kernel employs a mechanism that helps it treat all the supported file systems indiscriminately at an upper level. This mechanism is called the virtual file system (VFS). The interface of each lower-level file system that you wish to use should confirm to the VFS.
VFS is an indirection layer that manages system calls. It calls the necessary functions in the physical file system code to perform the necessary I/O operations.
The virtual file system, which is also known as the virtual file system switch, performs the following main functions:
-
Helps several file systems coexist on a Linux system
-
Keeps a check on the available file systems on the Linux system
-
Matches the devices with the appropriate file systems
-
Performs generic processing for operations involving files
The VFS layer functions with the following objects and their corresponding operations:
-
File system: Is responsible for storing information pertaining to an open file and a process. This object exists only when a file interacts with a process.
-
Superblock: Is responsible for storing information pertinent to a file system that is mounted.
-
Inode: Is responsible for storing meta information pertaining to a single file.
-
Dentry: Is responsible for linking a directory entry with the corresponding file.
The VFS Design
VFS uses a table, which is defined when the kernel is configured. This table helps track supported file systems and contains the following information:
-
A description of all file system types that are supported by Linux
-
The type of the file system
-
A pointer to a function, which is called when the file system is mounted
The VFS Descriptors
To understand the working of VFS, it is important to understand the relevance of descriptors that are used by VFS.
Mounted File System Descriptors
A mounted file system descriptor contains useful information that is relevant to file systems. The information stored in the mounted file system descriptor is as follows:
-
Generic information that is shared by all file system types
-
Pointers to functions
-
Information privately maintained by the file system code
There are two other types of descriptors that are used by VFS. They are:
-
Open file descriptors
-
Inode descriptors
Inode Descriptors
The inode descriptor contains function pointers. These pointers call functions, which are used to perform specific actions on any file.
The structure used by VFS for inode operations contains several function pointers. Table 1-1-2 lists some of the commonly implemented function pointers and their purpose.
| Function Pointer | Purpose |
|---|---|
| Link | Creates a hard link |
| Unlink | Deletes a link |
| Symlink | Creates a symbolic link |
| Mkdir | Creates directory |
| Rmdir | Removes a directory |
| Mknod | Creates a block file or a character special file |
| Readlink | Reads and prints the contents of a symbolic link |
| Truncate | Truncates a file |
Open File Descriptors
Similar to inode descriptors, the open file descriptor also contains pointers to functions. However, these pointers can call functions that can be used to perform specific actions on open files.
The Working of the VFS
When a file system is mounted, the mount function is called. In addition to reading the superblock from the disk and initializing internal variables, the mount function also returns a mounted file system descriptor to the VFS. After the file system is mounted, the mounted file system descriptor is used by VFS functions. VFS functions use the file system descriptor to access physical file system routines.
Maintaining Consistency in File Systems
A file system contains information in a structured format. This structured information is updated from time to time when the file system performs read and write operations on it. However, there is a potential risk involved. Say, for example, a write operation is being performed on the metadata present in the file system when an unexpected power failure occurs. In this situation, there is possibility of a system crash. As a result, certain inconsistencies can crop up in the metadata. There are two solutions to this problem that can help maintain data integrity. You will now learn about each of these solutions in detail. Later, you will compare the solutions by performing a one-on-one analysis to decide which solution is better. To maintain file system integrity, you can either use the fsck command or the journaling file system.
Using the fsck Command
While shutting down, Linux transfers all cached data to the hard disk. This ensures that the file system is unmounted. As a result, the file system is ready for use when the system is started again. However, there might be situations where the Linux system is not shut down properly. The reasons could be power failure or system lock up.
In such situations, the file systems are not cleanly unmounted, and as a result, the integrity of files might be affected. In this situation, Linux invokes the fsck utility when the operating system is restarted, which checks for file system integrity.
The fsck utility thoroughly scans metadata structures and repairs them if it encounters any errors. However, fsck prompts you before making any correction. The file system becomes ready for use after fsck performs the test successfully. All file systems that are specified in the /etc/fstab file are checked to verify that the metadata structures are still usable.
You can invoke fsck from the console by using the fsck command to check file system integrity at any time - not just when the file system is not cleanly unmounted. The syntax for the fsck command is as follows:
#fsck [options] [filesystem]
When you use the fsck command, an exit code is returned. This code is a summation of the conditions specified in Table 1-1-3.
| Code | Result |
|---|---|
| 0 | Indicates that fsck did not encounter any error while performing file system check |
| 1 | Indicates that file system errors were encountered but were corrected |
| 2 | Indicates that the system should be restarted |
| 4 | Indicates that fsck encountered file system errors but left them uncorrected |
| 8 | Indicates that an operational error was detected |
| 16 | Indicates that there was an error in the usage of or the syntax of the command |
| 128 | Indicates that a shared library error was detected |
Table 1-1-4 explains the important options that can be used with the fsck command.
| Option | Explanation |
|---|---|
| -r | Used to specify that fsck should prompt before making any repairs to the file system |
| -s | Used for the serial mode |
| -t | Used to indicate that the file system type will be specified immediately after the option |
| -A | Used to check all the file systems present in the /etc/fstab file |
| -V | Used for the verbose mode |
Using Journaling File Systems
Journaling file systems are fault-resilient systems that are primarily used for high-availability servers. Journaling file systems ensure data integrity, and they store the changes to metadata in a serial log. At the time of system failure, the entire journaling file system ensures that the system is restored. The mechanism that a journaling file system follows to restore the system is called journaling or logging. When logging is used, a space on the system is allocated solely for this purpose. Whenever you attempt to write something to the disk, the file system first writes the data onto the metadata of the log. At the time of a system crash, system recovery code analyzes the metadata log. Then, to recover or clean up the inconsistent files, it replays only the log files.
| Note | Journaling file systems have existed since mid-1980s. The most popularly used journaling file systems that are used today are ReiserFS, XFS, JFS and ext3. |
The fsck Utility and Journaling File Systems: A Comparison
Although, the fsck utility is also used to check and rectify file system errors, there are certain drawbacks of using fsck. The drawbacks are:
-
The fsck utility takes a considerable amount of time to verify large file systems. Carrying out a thorough consistency check on the entire metadata of a file system is rather time-consuming. The bigger the file system, the longer the scan takes.
-
The Linux system remains offline while the fsck is checking the file system. This adversely effects the system uptime, which is critical if the server is being used for Web hosting.
-
The entire file system is checked for errors by the fsck utility although only specific areas of the file system might have been affected.
There are certain advantages of journaling file systems as compared to the fsck utility. They are:
-
A journaling file system maintains a log that describes the recent modifications made to metadata. Which means that, the file system checks only the modified files present in the journal. This saves considerable time because it helps perform system checks faster.
-
The procedure for checking the file system is faster, which means that the server uptime is not adversely affected.
-
Only a limited part of the file system is checked for errors in case of the journaling file system, because only the journal or the log file is examined before it is replayed to rectify the potential errors in the file system.
-
The journal helps in bringing the file system back to a consistent state in a considerably short time. In addition, the journaling process does not take a long time on large file systems. With the help of journaling, hundreds of gigabytes of file system metadata can be quickly brought to a consistent state.
-
The logs maintained by the journaling file system contain adequate information, which helps replay the log record and carry out the operation.
-
Data integrity is ensured in a journaling file system. This is because updates to metadata are written to a serial log on the disk prior to updating the original disk blocks.
-
If there is any system failure, the entire journaling file system ensures that the consistency of the file system is restored.
This approach does not need a full scan of the file system. As a result, the file system check on large file systems is completed quickly. For a file system that contains multiple-gigabytes of data, it involves only a few seconds.
Common File Systems Supported by Linux
Unlike Windows, Linux supports a wide range of file systems. The most commonly used file systems are ext2, ext3, XFS, and ReiserFS, ISO 9660 (the file system used by the CD-ROM). One of the key strengths of Linux is its ability to recognize a wide range of file systems. Linux can also be installed on a FAT file system, although that is not the preferred choice.
Ext2fs
The Second Extended Filesystem or ext2fs is one of the most commonly used file systems in Linux. Before the release of Red Hat Linux 7.2, ext2fs was used, by default, by Red Hat Linux for installation. The features of ext2fs can be summarized as are explained in this section.
Robust Design
Ext2fs is a robust file system that provides standard Unix file features. The robust design minimizes the risk of data loss.
Support for Standard UNIX File Types
All standard UNIX file types are supported by ext2fs. The standard UNIX file types supported by ext2fs include regular files and directories. In addition to this, device special files and symbolic links are also supported.
Provision for Handling File Systems Created on Big Partitions
Ext2fs has the ability to handle large partition sizes. In other words, when you are using ext2fs, you need not create multiple partitions because ext2fs works well with the disks that have a large storage capacity.
Support for Long File Names
Another important feature of ext2fs is that it supports long file names. The maximum number of characters that can be used for a file name is 255. However, there are certain file-naming conventions that apply. In addition to using long file names, you can also use variable length directory entries in ext2fs. The variable length of directory listings allows file names to be flexible.
Blocks Reserved for Administrators
A helpful feature of ext2fs is its use of reserved blocks. By default, five percent of the blocks are reserved for the root user. This means that only the root user can use this pre-allocated space.
Support for File Attributes
Ext2fs also supports file attributes. By specifying file attributes, users can modify the kernel behavior while using a set of files. Attributes can be set for either a file or a directory.
When you set certain attributes for a directory, all new files created in the directory inherit those attributes. Attributes can be set using the chattr command.
Provision for Synchronous Updates
Ext2fs supports synchronous updates. The mount command can be used with the sync option to achieve this.
Synchronous updates can be used in ext2fs. The mount option, sync, forces synchronous I/O for the file system. This helps ensure metadata consistency. However, because using synchronous updates can result in poor performance, this feature is not widely used.
Ability to Provision for Selecting the Logical Block Size to be Used
Using ext2fs, the administrator has the choice of specifying the logical block size when creating the file system. The size of a single block can be 1024, 2048, or 4096 bytes. Big block sizes can increase the speed of I/O operations.
Support for Fast Symbolic Links
Ext2fs supports a feature called fast symbolic links. A symbolic link that does not use any data block on the file system is called a fast symbolic link. When you use symbolic links, the target name is stored in the inode instead of the data block. This helps save considerable amount of disk space.
In addition to saving disk space, fast symbolic links also considerably improve the speed of link operations. In other words, the data block is not read while accessing such a link. You can specify a maximum of 60 characters for the target name in a fast link.
Forced File System Checks
Forced file system checks imply that a file system is checked automatically at regular intervals, regardless of whether or not the file system is working properly. Ext2fs forces file system checks in two ways.
The superblock consists of a mount counter, which is incremented by 1 each time the file system is mounted. When the counter reaches the specified maximum value, the file system checker automatically performs a file system check.
Other details, such as the last check time and the maximum check interval, are also maintained in the superblock. These fields help the administrator facilitate regular checks.
File System-related Utilities
Ext2fs provides several tools that help create, fine-tune, and maintain your ext2 file system. The tools available in ext2fs file system are explained in this section.
The mke2fs Utility
The mke2fs utility is used to create a second extended file system in Linux. It is created on a device, which can be a floppy or a disk partition. This utility initializes a partition so that it can accommodate an empty ext2 file system. The syntax for the mke2fs utility is as follows:
mke2fs [options] device [blocks]
There are several options that can be used with the mke2fs utility. Table 1-1-5 refers to a few of the important options.
| Options | Explanation |
|---|---|
| -b | Used to specify the block size in bytes. |
| -c | Used to specify that the specified device should be scanned before executing the command. |
| -f | Used to specify the size of the fragments in bytes. |
| -I | Used to specify that an inode should be created for each byte per inode of space. By default, 4096 bytes are assigned for each inode. You can change the number of bytes assigned per inode. However, you must ensure that the number of bytes per inode is either 1024 or greater. |
| -l | Used to specify the name of the file that must be checked for a list of bad blocks. |
| -m | Used to specify the percentage of blocks that are reserved for the super user. |
| -v | Used to invoke the verbose mode. |
The tune2fs Utility
Administrators use this utility to adjust tunable file system parameters on second extended file systems in Linux. This utility can be used to alter the following:
-
The error behavior displayed by the file system
-
The maximal mount count that should be maintained for the file system
-
The maximal check interval after which a file system check should be started
-
The number of logical blocks exclusively reserved for the super user or the root user
When you use this utility, you must ensure that the file system is ummounted. If your file system is mounted, you will not be able to use this command.
The syntax for using the tune2fs command is as follows:
#tune2fs [options] device
Table 1-1-6 shows the options that can be used with the tune2fs command.
| Options | Explanation |
|---|---|
| -c | Specifies the number of mount counts after which the file system check must be performed. |
| -e | Specifies the behavior of the kernel when errors are encountered. |
| -g | Specifies that a particular group will use reserved blocks. The group ID or the group name can be specified with this option. |
| -l | Displays the contents of the superblock. |
| -m | Specifies the percentage of blocks that will be reserved only for privileged users. |
| -r | Specifies the number of blocks that will be reserved for use by privileged users. |
| -u | Specifies a user ID or a user name that will use reserved blocks. |
The e2fsck Utility
This is a very useful utility that is used to check the integrity of an ext2 file system. The e2fsck utility repairs file system inconsistencies that might occur due to an improper shut down of a system. The syntax for the e2fsck utility is as follows:
#e2fsck [options] device
Table 1-1-7 displays the most common options that are used with the e2fsck utility.
| Options | Explanation |
|---|---|
| -b | Specifies a new superblock instead of using the default superblock. |
| -d | Checks the file system in the debugging mode. |
| -f | Checks a file system forcefully. |
| -l | Specifies a file name that will be checked for a list of bad blocks in addition to checking other blocks. |
| -n | Specifies that no changes should be made to the file system. |
| -p | Repairs bad blocks without prompting for a confirmation. |
| -t | Displays timing statistics. |
| -v | Specifies the verbose mode. |
| -L | Specify the file that should be checked for bad blocks. |
Ext3fs
Ext3fs is an improvised version of ext2fs, which was designed by Dr. Stephen Tweedie. Although ext3fs is based on the ext2fs, it is a journaling file system. There are several useful features that make ext3fs a secure and efficient file system. You will read about the salient features of the ext3 file system in this section.
Linux Distribution Support
Several Linux distributions, such as Mandrake Linux 8.2, Red Hat Linux 7.2, and Suse Linux 7.3, have provided ext3 support in their kernel. To be precise, the ext3 file system has been merged into kernel builds since version 2.4.16.
Compatibility with ext2fs
The on-disk formats of ext2 and ext3 are identical. This is because ext3 is based on ext2 source code. This compatibility enables an ext3 file system to make use of all of the existing applications that have already been developed to work with the ext2 file system. The extent of compatibility can be best explained by the fact that a cleanly unmounted ext3 file system can be remounted as an ext2 file system.
Upgrading
The ext2 file system can be upgraded to ext3 file system with ease. While upgrading, you need not back up all the data, reformat the file system, or restore the data. This is because ext3 uses the same metadata that ext2 uses.
In order to successfully upgrade an ext2 file system to an ext3 file system, you need to perform the following steps:
-
Upgrade a few key system utilities.
-
Install kernel 2.4.
-
Use the tune2fs command.
For example, to convert an existing ext2 file system on /dev/hdb1 to ext3, you can give the following command:
#tune2fs -j /dev/hdb1
Security
Compared to ext2, ext3 is a more secure file system. It ensures the integrity of data that is written to the hard disk.
A Journaling File System
The most significant feature of an ext3 file system is probably that it is a journaling file system. A journaling file system has several advantages over normal file systems. The features of an ext3 file system, which is a journaling file system are listed below:
-
The ext3 journaling file system support comes in two parts, the kernel and tools.
-
The ext3 file system is backward compatible with the ext2 file system. In addition to this, it also inherits the beneficial features of the ext2 file system, such as the metadata format. For example, ext3 users can access the well-tested and mature e2fsck tool.
-
The journaling code of ext3 file systems uses a special application programming interface (API) that helps you implement a journal on block devices. This API is called the Journaling Block Device layer or JBD.
-
Ext3 implements journaling by connecting to the JBD API. For instance, the ext3 file system code informs the JBD of the modifications it will perform. In addition, it requests permission from the JBD before performing any type of modification on the data. This helps the JBD manage the journal for the ext3 file system driver.
-
The journal for ext3 is stored in a file called .journal, which is stored in the root of the file system. This is how ext3 is able to add the required journal to the file system, which can be done without actually requiring incompatible extensions to the ext2 metadata. This way the ext3 file system ensures backward compatibility with the ext2 file system.
eXtended File System
Silicon Graphics developed the eXtended File System (XFS) in 1990. The XFS file system came into existence mainly because the Extent File System (EFS) file system that the employees at Silicon Graphics were using was unsuitable for performing certain tasks. To counter this problem, SGI designed a file system known as the XFS file system. The following are the features of the XFS file system:
-
XFS is a high-performance, 64-bit file system. In 1994, it was made available to the whole world with the release of IRIX 5.3.
-
From simple workstations to complex supercomputers, XFS is used as an underlying file system for all IRIX-based products of SGI.
-
A version of XFS file system is available for Linux as well. It provides the Linux operating system with a refined and robust file system that can fulfill all kinds of storage problems. Some distributions, like Mandrake 8.2, provide Linux kernels with XFS support.
-
For large disk operations, XFS provides data access efficiency by maintaining journaling logs in the form of well-defined tables. These tables contain information about the location of data blocks and the link between two blocks.
-
In addition, XFS is a highly scalable file system. It manages large data files quickly and, therefore, enables faster access to data.
-
XFS also has the ability to manage user rights and permissions on various files and directories stored on the disk.
-
XFS uses advanced journaling technology, which involves using 64-bit addressing. In addition, scalable structures and algorithms are also used with XFS.
-
An important feature of XFS is its ability to allow the system to restart quickly after an unexpected interruption. This benefit is also derived from the journaling technology used by XFS. XFS manages a fast reboot, regardless of the number of files being used at the time of the unexpected interruption. In contrast to traditional file systems, the XFS journaling avoids lengthy file system checks.
-
The journaling structures and algorithms used by XFS are tuned in a manner that helps rapid transaction logging.
-
XFS efficiently handles activities such as space allocation and searches. This behavior results from the efficient table structures used by XFS.
-
The fact that XFS is a 64-bit file system allows it to handle large-sized files with ease.
-
The address space must be effectively large, and the structures and algorithms must scale in accordance with the disk size. XFS provides the technologies needed for this scalability.
-
An efficient space manager manages the procedure of disk space allocation in XFS. The main function of the space manager in addition to allocating disk space is controlling inodes. Similarly, the namespace manager ensures the efficient allocation of directory files.
-
Inodes created efficiently by XFS are not bound to a particular area on the disk. Instead, they are placed close to the files or directories that they point to. As a result, data can be accessed faster.
-
Files such as symbolic links that occupy less space on the disk are stored as part of the inode. This helps increase performance and save space on the disk.
ReiserFS
ReiserFS is one of the earliest file systems used with Linux. Hans Reiser and his team at Namesys developed this file system. They wanted to design and develop a file system that could create a single shared environment or namespace in which applications could interact in a powerful, direct, and efficient manner. As a result, ReiserFS was created. The following are the salient features of this file system:
-
It makes use of an efficient and optimized binary tree that helps arrange and organize file system data systematically. In a binary tree, each file is represented as an object in the file system hierarchy. These objects store information about files and file links and enable faster data access. This enhances performance and eases restrictions on file system layouts. With ReiserFS, it is possible to have a directory that consists of 100,000 other directories.
-
ReiserFS dynamically allocates inodes when required. This indicates that a fixed set of inodes is not created when the file system is created. This makes the file system flexible enough to accommodate a wide range of storage requirements. In addition, it makes efficient use of space.
-
Instead of allocating storage space in fixed 1K or 4K blocks, ReiserFS allocates the exact amount of space it requires. In addition, ReiserFS stores files inside the binary tree leaf node instead of storing the data somewhere else on the disk and pointing to it. This provides two benefits. The first benefit is that small file performance is enhanced considerably. This is because file data and inode information are stored next to each other and can be accessed with a single I/O operation. If expressed in numeric figures, the performance of ReiserFS can increase ten to fifteen times when compared to ext2 or ext3 file systems. Second, ReiserFS can pack tails together. Tails are files with a size that is smaller than the logical block size or are leftover portions of files not accommodated in a block.
-
Tail packing helps ReiserFS to hold approximately 6 percent more data than an ext2 file system. This file system manages disk space in an efficient manner by putting as many as 100 byte files into one block. Unlike ReiserFS, other file systems put each file in its own block.
Tmpfs
Tmpfs is also known as the virtual memory (VM) file system. Tmpfs is a file system that uses random access memory (RAM) and swap devices for storage purposes. The virtual memory resources used by the Linux kernel are derived from RAM and SWAP devices. A mechanism known as the VM subsystem that resides in the kernel is responsible for allocating these resources to other parts of the system. The VM subsystem receives requests for pages from the tmpfs file system before files can be stored.
Tmpfs remains unaware about the location of the pages. Therefore, it cannot determine whether these pages are on swap devices or in RAM. All it knows is that it is using some kind of virtual memory to store files.
Tmpfs file system can be created using a simple mount command:
# mount tmpfs /mnt/tmpfs –t tmpfs
After this command is executed, a new, ready-for-use tmpfs file system is mounted at /mnt/tmpfs. Soon after the mount command is executed, the file system, of the type tmpfs, is mounted.
Tmpfs has the following advantages:
-
It has a dynamic file system size. The tmpfs file system driver allocates more virtual memory while files are copied or created. This helps increase the file system capacity dynamically.
-
When you remove files from /mnt/tmpfs, the tmpfs file system driver frees virtual memory resources by reducing the file system size. As a result, virtual memory is made available to other parts of the system.
-
Speed is another great advantage of tmpfs. The tmpfs file system resides completely in RAM. As a result, read and write operations are performed faster. If swap devices are used, high performance is retained and parts of the tmpfs file system are moved to RAM because more free VM resources are available.
-
Virtual memory is unstable in nature. As a result, tmpfs data is not preserved between startups. This feature makes tmpfs the ideal file system for storing and managing critical data.
