• Verify the integrity of filesystems
• Monitor free space and inodes
• Repair simple filesystem problems

This article covers standard and journaling (also called journaling) filesystems with an emphasis is on ext2 (standard filesystem) and ext3 (journaling filesystem), but tools for other filesystems are mentioned too. Most of this material applies to both 2.4 and 2.6 kernels. Most examples in this article use Fedora 12, with a 2.6.32 kernel. Your consequences on other systems may differ.
This article helps you prepare for Objective 104.2 in Topic 104 of the Linux Professional Institute Certification level 1 (LPIC-1) exams. The objective has a weight of 2.
Prerequisites
To get the most from the articles in this series, you should have a basic knowledge of Linux and a working Linux system on which you can practice the orders covered in this article. Sometimes different versions of a program will format productivity differently, so your consequences may not always look exactly like the listings and figures shown here.
You should also be traditional with the material in our article “Learn Linux 101: Make partitions and filesystems.”
Checking filesystems
In cases when your system crashes or loses power, Linux may not be able to cleanly unmount your filesystems. Thus, your filesystems may be left in an variable state, with some changes completed and some not. Operating with a hurt filesystem is not a excellent thought as you are likely to further compound any existing errors.
The main tool for checking filesystems is fsck, which, like mkfs, is really a front end to filesystem-checking routines for the various filesystem types. Some of the underlying check routines are shown in Listing 1.

Listing 1. Some of the fsck programs

You may be surprised to learn that several of these files are hard links to just one file as shown in Listing 2. Remember that these programs may be used so early in the boot process that the filesystem may not be mounted and symbolic link support may not yet be available. See our article Learn Linux, 101: Make and exchange hard and symbolic links for more information about hard and symbolic links.

Listing 2. One fsck program with many faces

The system boot process use fsck with the -A option to check the root filesystem and any other filesystems that are specified for checking in the /etc/fstab control file. If the filesystem was not cleanly unmounted, a uniformity check is performed and repairs are made, if they can be done safely. This is controlled by the pass (or passno) field (the sixth field) of the /etc/fstab entry. Filesystems with pass set to zero are not check at boot time. The root filesystem has a pass value of 1 and is check first. Other filesystems will usually have a pass value of 2 (or higher), indicating the order in which they should be check.
Multiple fsck operations can run in parallel if the system determines it is advantageous, so different filesystems are allowed to have the same pass value, as is the case for the /grubfile and //mnt/ext3test filesystems shown in Listing 3. Note that fsck will avoid running multiple filesystem checks on the same physical disk. To learn more about the layout of /etc/fstab, check the man pages for fstab.

Listing 3. Boot checking of filesystems with /etc/fstab entries

filesystem                           mount top  type   options    dump pass
UUID=a18492c0-7ee2-4339-9010-3a15ec0079bb /              ext3    defaults        1   1
UUID=488edd62-6614-4127-812d-cbf58eca85e9 /grubfile      ext3    defaults        1   2
UUID=2d4f10a6-be57-4e1d-92ef-424355bd4b39 swap           swap    defaults        0   0
UUID=ba38c08d-a9e7-46b2-8890-0acda004c510 swap           swap    defaults        0   0
LABEL=EXT3TEST                            /mnt/ext3test  ext3    defaults        0   2
/dev/sda8                                 /mnt/xfstest   xfs     defaults        0   0
LABEL=DOS                                 /dos           vfat    defaults        0   0
tmpfs                   /dev/shm                         tmpfs   defaults        0   0
devpts                  /dev/pts                         devpts  gid=5,mode=620  0   0
sysfs                   /sys                             sysfs   defaults        0   0
proc                    /proc                            proc    defaults        0   0

Some journaling filesystems, such as ReiserFS and XFS, force have a pass value of 0 because the journaling code, rather than fsck, does the filesystem uniformity check and repair. On the other hand, some filesystems, such as /proc, are built at initialization time and therefore do need to be check.
You can check filesystems after the system is booted. You will need root power, and the filesystem you want to check should be unmounted first. Listing 4 shows how to check two of our filesystems, by the device name, categorize, or UUID. You can use the blkid command to find the device given a categorize or UUID, and the categorize and UUID, given the device.

Listing 4. By fsck to check filesystems

If you attempt to check a mounted filesystem, you will usually see a warning similar to the one in Listing 5 where we try to check our root filesystem. Heed the warning and do not do it!

Listing 5. Do not attempt to check a mounted filesystem

It is also a excellent thought to let fsck map out which check to run on a filesystem; running the incorrect check can corrupt the filesystem. If you want to see what fsck would do for a given filesystem or set of filesystems, use the -N option as shown in Listing 6.

Listing 6. Result what fsck would do to check /dev/sda7, /dev/sda8, and /dev/sda9

So far, we have check ext and vfat filesystems. Let’s now check the XFS filesystem on /dev/sda8. As you can see in Listing 7, the fsck command austerely tells us that we should use the xfs_check command. If there are no errors, then xfs_check does not show any productivity. There is a -v option for verbose productivity, but it is much too verbose for a simple check.

Listing 7. By fsck with XFS

Monitoring free space
On a storage space device, a file or directory is contained in a collection of blocks. Information about a file is contained in an inode, which minutes information such who the owner is, when the file was last accessed, how large it is, whether it is a directory, and who can read from or write to it. The inode number is also known as the file serial number and is unique within a particular filesystem. See our article Learn Linux, 101: File and directory management for more information on files and directories.
Data blocks and inodes each take space on a filesystem, so you need to monitor the space treatment to ensure that your filesystems have space for growth.
The df command
The df command displays information about mounted filesystems. If you add the -T option, the filesystem type is built-in in the show; otherwise, it is not. The productivity from df for the Fedora 12 system that we used above is shown in Listing 8.

Listing 8. Showing filesystem treatment

Notice that the productivity includes the whole number of blocks as well as the number used and free. Also notice the filesystem, such as /dev/sbd9, and its mount top: / /dev/sdb9. The tmpfs entry is for a virtual reminiscence filesystem. These exist only in RAM or swap space and are made when mounted without need for a mkfs command. You can read more about tmpfs in “Common threads: Advanced filesystem implementor’s guide, Part 3“.
For point information on inode treatment, use the -i option on the df command. You can exclude certain filesystem types by the -x option, or restrict information to just certain filesystem types by the -t option. Use these multiple times if necessary. See the examples in Listing 9.

Listing 9. Showing inode treatment

[ian@echidna ~]$ df -i -x tmpfs
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb9            2883584  308920 2574664   11% /
/dev/sda2              48768      41   48727    1% /grubfile
/dev/sda8            20976832       3 20976829    1% /mnt/xfstest
/dev/sda7            7159808      11 7159797    1% /mnt/ext3test
/dev/sda9                  0       0       0    -  /dos
[ian@echidna ~]$ df -iT -t vfat -t ext3
Filesystem    Type    Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb9     ext3   2883584  308920 2574664   11% /
/dev/sda2     ext3     48768      41   48727    1% /grubfile
/dev/sda7     ext3   7159808      11 7159797    1% /mnt/ext3test
/dev/sda9     vfat         0       0       0    -  /dos

You may not be surprised to see that the FAT32 filesystem does not have inodes. If you had a ReiserFS filesystem, its information would also show no inodes. ReiserFS keeps metadata for files and directories in stat items. And since ReiserFS uses a balanced tree structure, there is no predetermined number of inodes as there are, for example, in ext2, ext3, or xfs filesystems.
There are several other options you may use with df to limit the show to local filesystems or control the format of productivity. For example, use the -H option to show human readable sizes, such as 1K for 1024, or use the -h (or --si) option to get sizes in powers of 10 (1K=1000).
If you aren’t sure which filesystem a particular part of your directory tree lives on, you can give the df command a parameter of a directory name or even a filename as shown in Listing 10.

Listing 10. Human readable productivity for df

The tune2fs command
The ext family of filesystems also has a utility called tune2fs, which can be used to inspect information about the block count as well as information about whether the filesystem is journaled (ext3 or ext4) or not (ext2). The command can also be used to set many parameters or exchange an ext2 filesystem to ext3 by adding a journal. Listing 11 shows the productivity for a near-empty ext3 filesystem by the -l option to austerely show the existing information.

Listing 11. By tune2fs to show ext4 filesystem information

[root@echidna ~]# tune2fs -l /dev/sda7
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   EXT3TEST
Last mounted on:          
Filesystem UUID:          7803f979-ffde-4e7f-891c-b633eff981f0
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype
 needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Defaulting mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              7159808
Block count:              28637862
Reserved block count:     1431893
Free blocks:              28140444
Free inodes:              7159797
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1017
Blocks per assemble:         32768
Fragments per assemble:      32768
Inodes per assemble:         8192
Inode blocks per assemble:   512
Filesystem made:       Mon Aug  2 15:23:34 2010
Last mount time:          Tue Aug 10 14:17:53 2010
Last write time:          Tue Aug 10 14:17:53 2010
Mount count:              3
Most mount count:      30
Last check:             Mon Aug  2 15:23:34 2010
Check interval:           15552000 (6 months)
Next check after:         Sat Jan 29 14:23:34 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (assemble root)
First inode:              11
Inode size:           256
Required superfluous isize:     28
Desired superfluous isize:      28
Journal inode:            8
Defaulting directory hash:   half_md4
Directory Hash Seed:      2438df0d-fa91-4a3a-ba88-c07b2012f86a
Journal backup:           inode blocks

xfs_info
For XFS filesystems you can show the same information that mkfs.xfs showed when the filesystem was made by the xfs_info as shown in Listing 12. You need to use xfs_info on a mounted filesystem.

Listing 12. By xfs_info to show XFS filesystem information

The du command
The df command gives information about a whole filesystem. Sometimes you force want to know how much space is used by your home directory, or how huge a partition to use if you wanted to go /usr to its own filesystem. To answer this kind of question, use the du command.
The du command displays information about the filename (or filenames) given as parameters. If a directory name is given, then du recurses and calculates sizes for every file and subdirectory of the given directory. The result can be a lot of productivity. Fortunately, you can use the -s option to request just a summary for a directory. If you use du to get information for multiple directories, then add the -c option to get a grand whole. You can also control productivity format with the same set of size options (-h, -H, --si, and so on) that are used for df. Listing 13 shows two views of the home directory of a newly made user who has logged in once and made an index.html file.

Listing 13. By du

The reason for the difference between the 48K whole from du -c * and the 1.1M summary from du -s is that the latter includes the entries starting with a dot, such as .bashrc, while the former does not.
One other thing to note about du is that you must be able to read the directories that you are running it against.
So now, let’s use du to show the whole space used by the /usr tree and each of its first-level subdirectories. The result is shown in Listing 14. Use root power to make sure you have appropriate access permissions.

Listing 14. By du on /usr

Repairing filesystems
Occasionally, very occasionally we hope, the worst will happen and you will need to repair a filesystem because of a crash or other failure to unmount cleanly. The fsck command that you saw above can repair filesystems as well as check them. Usually the automatic boot-time check will fix the problems and you can proceed.
If the automatic boot-time check of filesystems is unable to restore uniformity, you are usually dumped into a single user shell with some instructions to run fsck manually. For an ext2 filesystem, which is not journaled, you may be presented with a series of requests asking you to confirm proposed actions to fix particular blocks on the filesystem. You should generally allow fsck to attempt to fix problems, by responding y (for yes). When the system reboots, check for any missing data or files.
If you suspect corruption, or want to run a check manually, most of the checking programs require the filesystem to be unmounted, or at least mounted read-only. Because you can’t unmount the root filesystem on a running system, the best you can do is drop to single user mode (by telinit 1) and then remount the root filesystem read-only, at which time you should be able to perform a uniformity check. A better way to check a filesystem is to boot a recovery system, such as a live CD or a USB reminiscence key, and perform the check of your unmounted filesystems from that.
If fsck cannot fix the problem, you do have some other tools available, although you will generally need advanced knowledge of the filesystem layout to successfully fix it.
Why journal?
An fsck scan of an ext2 disk can take reasonably a while to complete, because the internal data structure (or metadata) of the filesystem must be scanned completely. As filesystems get better and better, this takes longer and longer, even even if disks also keep getting quicker, so a full check may take one or more hours.
This problem was the impetus for journaled, or journaling, filesystems. Journaled filesystems keep a log of recent changes to the filesystem metadata. After a crash, the filesystem driver inspects the log in order to determine which recently changed parts of the filesystem may possibly have errors. With this design exchange, checking a journaled filesystem for uniformity typically takes just a matter of seconds, regardless of filesystem size. Furthermore, the filesystem driver will usually check the filesystem on mounting, so an external fsck check is generally not required. In fact, for the xfs filesystem, fsck does nothing!
If you do run a manual check of a filesystem, check the man pages for the appropriate fsck command (fsck.ext3, e2fsck , reiserfsck, and so on) to determine the appropriate parameters. The -p option, when used with ext2, ext3, or ext4 filesystems will cause fsck to involuntarily fix all problems that can be safely fixed. This is, in fact, what happens at boot time.
We’ll illustrate the use of e2fsck and xfs_check by first running e2fsck on an empty XFS filesystem and then by xfs_check to fix it. Remember we suggested that you use the fsck front end to be sure you are by the right checker, and we warned you that failure to do so may result in filesystem corruption.
In Listing 15, we start running e2fsck against /dev/sda8, which contains an XFS filesystem. After a few interactions we use ctrl-Break to break out, but it is too late. Warning: Do NOT do this unless you are willing to end your filesystem.

Listing 15. Deliberately running e2fsck manually on an XFS filesystem

Even if you broke out at the first prompt, your XFS filesystem would still have been corrupted. Repeat after me. Do NOT do this unless you are willing to end your filesystem.
Now let’s use xfs_check to repair the XFS filesystem. The xfs_check command is reasonably verbose, but it has a -s option which reports only serious errors. The productivity is shown in Listing 16.

Listing 16. Repairing the XFS filesystem by xfs_check

You can also use xfs_repair to repair an XFS filesystem. Like xfs_check, it is reasonably verbose, and it does not have an -s option. If you’d like just to see what needs repair without really repairing it, use xfs_repair -n.
Superblocks
You may be wondering how all these checking and repairing tools know where to start. Linux and UNIX filesystems usually have a superblock, which describes the filesystem metadata, or data describing the filesystem itself. This is usually stored at a known location, frequently at or near the commencement of the filesystem, and replicated at other well-known locations. You can use the -n option of mke2fs to show the superblock locations for an existing filesystem. If you specified parameters such as the bytes per inode ratio, you should invoke mke2fs with the same parameters when you use the -n option. Listing 17 shows the location of the superblocks on /dev/sda7.

Listing 17. Result superblock locations

Advanced tools
There are several more advanced tools that you can use to examine or repair a filesystem. Check the man pages for the right treatment and the Linux Documentation Machinate (see Resources) for how-to information. Nearly all of these orders require a filesystem to be unmounted, although some functions can be used on filesystems that are mounted read-only. A few of the orders are described not more than.
You should always back up your filesystem before attempting any repairs.
Tools for ext2 and ext3 filesystems

tune2fs

Adjusts parameters on ext2 and ext3 filesystems. Use this to add a journal to an ext2 system, making it an ext3 system, as well as show or set the most number of mounts before a check is forced. You can also assign a categorize and set or disable various discretionary features.

dumpe2fs

Prints the super block and block assemble descriptor information for an ext2 or ext3 filesystem.

debugfs

Is an interactive file system debugger. Use it to examine or exchange the state of an ext2 or ext3file system.

Tools for Reiserfs filesystems

reiserfstune

Displays and adjusts parameters on ReiserFS filesystems.

debugreiserfs

Performs similar functions to dumpe2fs and debugfs for ReiserFS filesystems.

Tools for XFS filesystems

xfs_info

Displays XFS filesystem information.

xfs_growfs

Expands an XFS filesystem (high and mighty another partition is available).

xfs_admin

Changes the parameters of an XFS filesystem.

xfs_repair

Repairs an XFS filesystem when the mount checks are not sufficient to repair the system.

xfs_db

Examines or debugs an XFS filesystem.

We will wrap up our tools review with an illustration of the debugfs command, which allows you to explore the inner workings of an ext family filesystem. By defaulting, it opens the filesystem in read-only mode. It does have many orders that allow you to attempt undeletion of files or directories, as well as other operations that require write access, so you will specifically have to enable write access with the -w option. Use it with extreme care. Listing 18 shows how to open the root filesystem on my system; navigate to my home directory; show information, including the inode number, about a file called index.html; and finally, map that inode number back to the pathname of the file.

Listing 18. By debugfs

Conclusion
We’ve covered many tools you can use for checking, modifying, and repairing your filesystems. Remember to always use extreme care when by the tools discussed in this article or any other tools. Data loss may be only a keystroke away.

Resources
Learn

• Use the developerWorks roadmap for LPIC-1 to find the developerWorks articles to help you study for LPIC-1 certification based on the April 2009 objectives.
• At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the Linux Professional Institute’s Linux system administration certification. In particular, see their April 2009 objectives for LPI exam 101 and LPI exam 102. Always refer to the LPIC Program site for the latest objectives.
• Review the entire LPI exam prep series on developerWorks to learn Linux nitty-gritty and prepare for system administrator certification based on earlier LPI exam objectives prior to April 2009.
• Learn more about tmpfs in “Common threads: Advanced filesystem implementor’s guide, Part 3” (developerWorks, September 2001).
• The Linux Documentation Machinate has a variety of useful ID, especially its HOWTOs.
• In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM harvest and IT industry topics.
• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM harvest and tools, as well as IT industry trends.
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
• Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.

Get harvest and technologies

• Evaluate IBM harvest in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

• Participate in the discussion forum.
• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis. 
• http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-104-2/index.html