In: Categories » Computers and technology » Linux Commands » The fsck tool short for File System ChecK
The fsck tool, short for File System ChecK, is used to diagnose and repair file systems that may have become damaged in the course of daily operations. Such repairs are usually necessary after a system crash in which the system did not get a chance to fully flush all of its internal buffers to disk. (Although this tool’s name bears a striking resemblance to one of the expressions often uttered after a system crash, that this tool is part of the recovery process is strictly coincidence.) Usually, the system runs the fsck tool automatically during the boot process (much in the same way Windows runs Scandisk) if it detects a partition that was not cleanly unmounted. Linux makes an impressive effort to automatically repair any problems it runs across and in most instances does take care of itself. The robust nature of the ext3 file system helps in such situations. Nevertheless, it may happen that you get this message: Your system appears to have shut down uncleanly Press Y within 5 seconds to force file system integrity check If you press Y, you’ll see messages appear on the screen telling you how the check is proceeding. The system will tell you what file system is being checked and how far the check has progressed. You may see messages such as these:
recovering journal
clearing orphaned inode
These messages are normal; fsck is just doing its thing. If you find that a file system is not behaving as it should (log messages are excellent hints to this situation), you may want to run fsck yourself on a running system. The only downside is that the file system in question must be unmounted in order for this to work. If you choose to take this path, be sure to remount the file system when you are done.
NOTE
The name fsck isn’t the proper title for the ext2/ext3 repair tool; it’s actually just a wrapper. The fsck wrapper tries to determine what kind of file system needs to be repaired and then runs the appropriate repair tool, passing any parameters that were passed to fsck. In ext2 and ext3, the real tool is called e2fsck. When a system crash occurs, you may need to call e2fsck directly rather than relying on other applications to call it for you automatically.
Parameters Available for e2fsck
The parameters available for e2fsck are shown in Image 7-4. For example, to run e2fsck on the /dev/hda3 file system, you would run:
[root@tedford /root]# e2fsck /dev/hda3
To force a check and automatically answer Yes to any prompts that come up, you would enter this command:
[root@tedford]# e2fsck -f -y /dev/hda3
TIP
You won’t find an “e3fsck” command. The ext2 and ext3 file systems are so similar that the e2fsck command works on both of them.
What If I Get Errors?
First, relax. The fsck check rarely finds problems that it cannot correct by itself. When it does ask for human intervention, telling fsck to execute its default suggestion is often enough. Very rarely does a single pass of e2fsck not clear up all problems. On the rare occasions when a second run is needed, it should not turn up any more errors. If it does, you are most likely facing a hardware failure. Remember to start with the obvious: Check for reliable power and well-connected cables. Anyone running SCSI systems should verify that they’re using the correct type of terminator, that cables aren’t too long, that SCSI IDs aren’t conflicting, and that cable quality is adequate. (SCSI is especially fussy about the quality of the cables.)
The lost+found Directory
Another rare situation is when e2fsck finds segments of files that it cannot rejoin with the original file. In those cases, it will place the fragment in the partition’s lost+found directory. This directory is located where the partition is mounted, so if /dev/hda3 is mounted on /usr, then /usr/lost+found correlates to /dev/hda3. Anything can go into a lost+found directory—file fragments, directories, and even special files. When normal files wind up there, a file owner should be attached, and you can contact the owner and see if they need the data (typically, they won’t). If you encounter a directory in lost+found, you’ll most likely want to try to restore it from the most recent backups rather than trying to reconstruct it from lost+found. At the very least, lost+found tells you if anything became dislocated. Again, such errors are extraordinarily rare.
legal notice
Our website is not responsible for the information contained by this article. Web-articles is a free articles resource.
Suggestion: If you need fresh, daily updated content for your website, feel free to use our service. Click here for more information.
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above.
related articles
Editing Text Files Editors are by the far the bulkiest of common tools, but they are also the most useful. Without them, making any kind of change to a text file would be a tremendous undertaking. Regardless of your Linux distribution, you will have gotten a few editors. You should take a few moments to get comfortable with them before you’re busy fighting another problem. NOTE Although all of the editors listed here come with Red Hat 8, not all of them are installed by default. ...
2. Reviewing Linux File System Standards
Reviewing Linux File System Standards One argument you hear regularly against Linux is that there are too many different distributions, and that multiple distributions lead to fragmentation. This fragmentation will eventuate in different, incompatible Linux versions. This is, without a doubt, complete nonsense that plays on “FUD” (Fear, Uncertainty, and Doubt). These types of arguments usually stem from a misunderstanding of the kernel and distributions. However, the Linux community has realized that it h...
3. Linux is built upon the foundation of file systems
File Systems Linux is built upon the foundation of file systems. They are the mechanisms by which the disk gets organized, providing all of the abstraction layers above sectors and cylinders. In this module, you’ll learn about the composition and management of these abstraction layers supported by the default Linux file system, ext2, and its more robust counterpart, ext3. This module covers the many aspects of managing disks. This includes creating partitions, establishing file systems, automating the process ...
4. Mounting and Unmounting Local Disks
Linux’s strong points include its flexibility and the way it lends itself to seamless management of file locations. Partitions are mounted so that they appear as just another subdirectory. Even a substantial number of file systems look, to the user, like one large directory tree. This characteristic is especially helpful to the administrator, who can relocate partitions to various servers but can have the partitions still mounted to the same location in the directory tree; users of the file system need not know abou...
Adding and Partitioning a Disk The process of adding a disk under Linux on the Intel (x86) platform is relatively easy. Assuming you are adding a disk that is of similar type to your existing disks (e.g., adding an IDE disk to a system that already has IDE drives or adding a SCSI disk to a system that already has SCSI drives), the system should automatically detect the new disk at boot time, and all that is left is partitioning it and creating a file system on it. If you are adding a new type of disk (...
6. With the partitions created you need to put file systems on them
Syncing disks. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. [root@tedford /root]# If you needed to write an /etc/fstab file yourself for this configuration, it would look something like this: /dev/hdb1 / ext3 defaults 1 1 /dev/hdb2 swap swap defaults 0 0 /dev/hdb3 /usr ext3 defaults 1 2 /dev/hdb5 /home ext3 defaults 1 2 /dev/hdb6 /var ext3 defaults 1 2 /dev/hdb...
7. Mounting NFS partitions works much the same way as mounting local partitions
Mounting NFS Partitions Mounting NFS partitions works much the same way as mounting local partitions. The only difference is in how the partition is addressed. On local disks, partitions are addressed by their device name, such as /dev/hda1. In NFS mounts, partitions are referenced by their hostnames and export directories. Thus, if the server named ungerer is allowing your host to mount the directory /export/SL1200/MK2 and you want to mount this to /projects/topsecret1, you would use this command:...
8. Using autofs to mount partitions across the network
Starting the autofs Service Because the way you’re using autofs to mount partitions across the network relies on NFS, before using it you’ll need to be sure you can do normal NFS mounts. Once you have this working, just make a simple change to your startup scripts to deploy the autofs service. The easiest way to do this is to run the redhat-config-services utility to enable the daemon. Simply start the configuration tool and mark the autofs check box as shown. If you need to start autofs by hand...
9. Configuring Individual Partitions on Linux machines
Managing Quotas In any multiuser environment, you’re bound to run across users who—either refusing to play fair or because they’re oblivious to common courtesy—practice the fine art of disk hogging, taking up more than a reasonable amount of disk space. This problem can be managed in several ways. The first and most obvious solution is to beg and plead. This rarely works. The second approach is peer pressure: You regularly and publicly post the amounts of disk space being hogged by these users. If peop...