fsck on shutdown instead of startup

Usually, fsck is executed automatically at startup after every 30th reboot or so. Sometimes, it can be really slow, and can delay bootup by more than half an hour.

Is there any way to run fsck at shutdown instead? (I don't mind if shutdown is delayed. Bootup time is more important.)

I would like this for the Debian or Scientific Linux distros.

Solution 1:

While you can check some things during shutdown, you cannot effectively run fsck on your root filesystem. You see, fsck requires that the filesystem is not mounted before it can attempt repair. This is only possible during boot, while still running from initramfs.

Solution 2:

For Debian you can use AutoFsck but the package is no longer supported (last update 2010). So keep that in mind.

The other way would be to put a FSCK/bash script in your shutdown script. For SE linux/centos etc I would use chkconfig level 0 (halt) and 6(reboot). chkconfig --levels 0 rc.local-shutdown on Put the script in /etc/rc.d/init.d/. (level 6 for reboot)

For Debian I would put the create the scripts in /etc/rc6.K00scriptname and /etc/rc0.d/K00scriptname,

As for the script, you can use something like this:

#!/bin/bash
NETFS="nonfs,nosmbfs,nocifs,nocodafs,noncpfs,nosysfs,nousbfs,noshfs,nofuse,nofuseblk"

if (( `tune2fs -l /dev/sda2 | awk '/Mount count/{print $3}'` > `tune2fs -l /dev/sda2 | awk '/Maximum mount count/{print $4-1}' ))
then /sbin/fsck -A -T -C -a -t $NETFS 2>/dev/null
fi

This code was not written by me, but by someone on archlinux forums. I have not tried the code. So keep that in mind too.

Or you can just do something simple like /sbin/fsck -A -T -C -a -- -f inside the script.

Solution 3:

The problem with fsck on shutdown is that, you see when you are shutting down, you are unmounting the filesystem. Even if the fs is dirty, unmounting a fs doesn't force it to check it's integrity. While, you are mounting it, you are performing a fsck to check whether the metadata for the data is correct and whether fs has proper information for the fs as it reports it has. This can take place while the fs is going to be mounted. Because the code to check the fs integrity comes to play when the fs is going to be mounted.

This is I would guess the reason that we can do a lazy umount even if the fs is dirty but there is no lazy or forced umount when the fs is dirty ;)

Usually journalling fs shouldn't take long time to come up unless it is heavily screwed. xfs_repair is pretty slick and can be done online while btrfs is well, another story.