linux - Is it safe to disable fsck on boot?

07
2014-07

IMB

Occasionally fsck would run on it's own when I reboot my server, but most of the time it doesn't. But when it does run, it takes too long to finish. Is it safe to disable this permanently?

Answers

rob

If this is a production server, it's not a good idea to disable fsck's automatically scheduled checks on boot.

fsck automatically runs on boot after M mounts or N days, whichever comes first. You can tune this schedule using tune2fs.

I would suggest leaving the automatic check enabled, but using tune2fs to adjust the check schedule if appropriate, and forcing fsck to run when it is more convenient.

When fsck runs, it will reset the Mount count to 0 and update the Last checked field, effectively rescheduling the next automatic check.

If you don't want to run fsck manually but you know it will be convenient on the next scheduled reboot, you can force fsck on the next boot:

You can make your system run fsck by creating an empty 'forcefsck' file in the root of your root filesystem. i.e.: touch /forcefsck Filesystems that have 0 or nothing specified in the sixth column of your /etc/fstab, will not be checked

Find out if fsck will run on the next boot:

With ext2, ext3 and ext4 you can use

dumpe2fs -h /dev/diskname

Frank Thomas

I wouldn't. You can disable it if you have a policy for manually running fsck periodically, and use a fully journaling file system, but otherwise it is important for long term file system health. With boot checking disabled, you will only have fsck run automatically if your journal is marked as dirty, but it will not do things like bad sector checks, or manually look for file system issues that have not already been recorded.

Peter Horvath

I am glad to complement the "no-no-no" answers with some new ideas.

It depends on the importance of the server.

If it is extreme important (for example, your job depends on it): what you want to fix, is not your problem. Your problem is not the slow fsck, but the frequent rebooting. This is what you should fix.

If it is not so important: go ahead! If your reboots are clean (there is always clean shutdown), the only way for a filesystem error to happen, is a serious kernel or hardware bug. But they have mostly alternative symptoms too (see dmesg).

Related Answers

Kristian

First off, you're right about running fsck on the partition - fsck only works on filesystems, not entire disks. You can get a list of all partitions on the disk with fdisk -l /dev/sdd.

You're filesystem type is probably ext3 (the default in most Linux distros), which means it will usually pass an fsck as long its journal is clean. fsck -f will, as mentioned above, force a full check.

However, if you have read errors on the disk, no amount of fsck will help dd - since dd really doesn't care about the content of the disk.

To get dd to read the disk and continue on read errors, use dd conv=noerror,sync, which will continue on read errors and append null bytes to any block when there is a read error.

After you have finished the backup, you should run fsck -f on the clone to get it up and running again.

Another tip: If you backup the partition to a file, you can loopback mount it with mount -o loop filename.ext3 /mountpoint. Also, say you are cloning a 200G partition to a 500G drive, you can then run resize2fs /dev/sdx1 (where sdx is your new drive, partitioned with a single 500G partition), and the filesystem will be resized to 500G.

Lastly, if the disk is in such a shape that it's giving you read errors, I would advise you to avoid turning the disk off and on until you're finished recovering data. In some failure modes, the disk will at some point simply no longer spin up or fail to be recognized by the OS, and at that point getting data out of the drive becomes quite expensive.

Jonik

This may not be relevant in your case, but thought I'd mention it anyway:

For a lower-level disk check, you could use the badblocks utility. It goes through a device and reports any bad blocks (it cannot repair anything, of course). It's useful, at least, for verifying whether a disk is physically damaged.

Also, e2fsck can use badblocks to avoid bad blocks being used by a filesystem. From e2fsck manual:

  -c     This option causes e2fsck to use badblocks(8) program to do a  read-
         only scan of the device in order to find any bad blocks.  If any bad
         blocks are found, they are added to the bad block inode  to  prevent
         them from being allocated to a file or directory.  If this option is
         specified twice, then the bad block scan will be done using  a  non-
         destructive read-write test.

Richard Hoskins

You want the -f option to fsck (Force checking even if the file system seems clean.)

You should run fsck in single user mode. One easy way to do this without a live cdrom boot is to reboot with the -F option.

shutdown -rF now

Home

linux - Is it safe to disable fsck on boot?