As a system administrator, you will be called to manage the filesystems of the servers. Tuning a filesystem is a task that you’re likely to perform every once in a while when making major changes to an installation. The common tasks are checking a filesystem for errors.
Some bugs, power failures, and mechanical problems can all cause severe data loss or the data structures on a filesystem to become corrupted. That is why Linux includes tools such as fsck for verifying a filesystem’s integrity and correcting any problems that may occur.
In this tutorial, we will learn more about the fsck command, when and how to use it properly.
What you need to know
Linux runs fsck automatically at startup on partitions that are marked for this in
/etc/fstab which is the file containing information about the filesystems which are permanently mounted on the system. The normal behavior is to perform just a quick cursory examination of a partition if it’s been unmounted cleanly. Despite this operation, the Linux boot process isn’t delayed because of a filesystem check unless the system wasn’t shut down properly. If a filesystem is marked unclean for some reason, that means a lengthy check of the filesystem is probably required.
It is rare to have a mounted filesystem with corruption. When a filesystem is properly unmounted anything cached in memory is flushed to disk and fsck doesn’t need to check anything. If the computer was shutdown abruptly, it’s possible that some of this cache is lost and what is on disk may be missing something. It is the job of fsck to fix any damage caused by this missing data.
1) When to use the fsck command
Journaling filesystems do away with full filesystem checks at system startup even if the system wasn’t shut down correctly. Nonetheless, these filesystems still require check programs to correct problems introduced by undetected write failures, bugs, hardware problems, and the like.
If you encounter odd behavior with a journaling filesystem, you might consider unmounting the concerned filesystem and performing a filesystem check on it by using the
fsck command. If the boot process fails because of a filesystem error, you can run the recovery mode to perform the operation to do.
2) How to use the fsck command
The fsck command offers many parameters that can be used for a specific case depending on your situation or the result that you need. So we will try to list the most useful options that you can need more often:
-y: automatically assumes yes to all questions
-A: causes fsck to check all of the filesystems present in
-C: displays a text-mode progress indicator of the check process
-V: it produces a verbose output of the check process
-N: it displays what the fsck command would normally do without doing anything
-p: attempt to fix errors automatically
-M: tells fsck command to don't check the mounted filesystems
-f: performs a full filesystem check even if a filesystem is marked clean
-t: specify the type of filesystem to check
-c: check for bad blocks and add them to bad block table of the filesystem
-b: uses alternative superblock
3) Repair the filesystems
When errors are detected on the filesystems, most of the time the
fsck command needs your authorization in order to perform any modification on the filesystem. So it will ask you questions every time it will find an error and will try to modify it. Which means that you will have to validate by clicking on 'y' every time. It can be tiring so you can use the
-y option to help you
First, unmount the partition
# umount /dev/sdb
Now check your filesystem
# fsck -y /dev/sdb
4) Force the check of a filesystem
Normally after installing your Linux system, all the partitions (filesystems) are placed the
/etc/fstab file to be mounted automatically at the system startup. When there are no errors, the filesystem is marked clean but you can force the check on a clean filesystem with the
# fsck -f /dev/sdb1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb1: 11/1310720 files (0.0% non-contiguous), 126322/5242624 blocks
5) Check for bad sectors on the filesystem
When a section on a disk can not be read from or written to anymore, it means that there are bad blocks which can affect your disk drive and maybe lead to hardware failure in the future. You can use the
-c option to check for the bad blocks on the filesystem
as the result
sudo fsck -fc /dev/sdb1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Checking for bad blocks (read-only test): done /dev/sdb1: Updating bad block inode. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 11/1310720 files (0.0% non-contiguous), 126322/5242624 blocks
6) Fix bad block on the filesystem
If you find any bad sector on your filesystem, you can try to fix it by using the
-b to indicate a new superblock to use
but first, you should list the superblock of the disk to know which one you can use
# dumpe2fs /dev/sdb1 | grep superblock dumpe2fs 1.44.1 (24-Mar-2018) Primary superblock at 0, Group descriptors at 1-3 Backup superblock at 32768, Group descriptors at 32769-32771 Backup superblock at 98304, Group descriptors at 98305-98307 Backup superblock at 163840, Group descriptors at 163841-163843 Backup superblock at 229376, Group descriptors at 229377-229379 Backup superblock at 294912, Group descriptors at 294913-294915 Backup superblock at 819200, Group descriptors at 819201-819203 Backup superblock at 884736, Group descriptors at 884737-884739 Backup superblock at 1605632, Group descriptors at 1605633-1605635 Backup superblock at 2654208, Group descriptors at 2654209-2654211 Backup superblock at 4096000, Group descriptors at 4096001-4096003
Now you can try to use an alternate superblock of the list for reparation
# fsck -b 32768 /dev/sdb1 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) /dev/sdb1 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(32768--33795) +(98304--99331) +(163840--164867) +(229376--230403) +(294912--295939) +(819200--820227) +(884736--885763) +(1605632--1606659) +(2654208--2655235) +(4096000--4097027) Fix<y>?
As you can see you can have a lot of question about the fixing process, so you can choose to add the
-y option when you will start the command but it will continue without asking you for a confirmation
The fsck command is run at boot time when filesystems are mounted from entries in the /etc/fstab file. it can force a check if the filesystem has gone longer than a certain amount of time without checks or if it has been mounted more than a certain number of times since the last check. Therefore, you’ll occasionally see automatic filesystem checks of filesystems, even if the system was shut down correctly. The fsck program skips any that have a 0 (zero) in the sixth column, any entries in that have a 1 in the sixth field are checked first, followed by entries that have a 2 in the sixth field.