this is what a filesystem check on boot looks like…

MY RECOMMENDATION: WHO CARES IF THE NAS IS DOING A AUTOMATIC REBOOT AT SUNDAY 3 o’CLOCK IN THE MORNING AND CHECKING 2-3TB OF EXT3 FILESYSTEM? NO ONE!

RELIABILITY SHOULD BE THE TOP1 PRIORITY OF ANY FILESYSTEM.

MAYBE SPEED CAN BE SECOND, UNLESS YOU DO NOT CARE ABOUT DATA-LOSS. (temporary storage… but believe me… even a temporary storage contains important files that users feel very angry about if lost)

I believe regular automatic filesystem checks (also of the root filesystem) are a pretty good idea.

So what you SHOULD do is:

1. use ext3 until 2020 than use ext4 or btrfs or whatever has proofen to be reliable on the market for 10 years. (see article „the perfect filesystem“)

2. have backups that report via mail if the backup worked or not.

3. let your filesystem be checked if people don’t need it – sunday night – once a month.

so the idea is: set partition to be checked – and cron a reboot when there is probably no usage of your server or service.

works with ext3 and ext4 but not with XFS filesystem

tune2fs allows the system administrator to adjust various tunable filesystem parameters on Linux ext2, ext3, or ext4 filesystems.

You should strongly consider the consequences of disabling mount-count-dependent checking entirely.

Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked.

A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. (straight from: tune2fs.man.txt)

It is strongly recommended that either -c (mount-count-dependent) or -i (time-dependent) checking be enabled to force periodic full e2fsck(8) checking of the filesystem.

Failure to do so may lead to filesystem corruption (due to bad disks, cables, memory, or kernel bugs) going unnoticed, ultimately resulting in data loss or corruption.

if you use something else than ext3/ext4 you can try the

touch /forcefsck

approach.

tune2fs -C 2 -c 1 /dev/sda1; # check filesystem on every boot
tune2fs -c 10 -i 30 /dev/sda1; # check sda1 every 10 mounts or after 30 days

you can check that a filesystem check was performed with:

tune2fs -l /dev/sda1 | egrep -i "mount count|Check interval|Last|Next"

Last mounted on: /
Last mount time: Tue Jul 4 10:27:35 2017
Last write time: Tue Jul 4 10:06:15 2017
Mount count: 19
Maximum mount count: 10
Last checked: Tue Jun 27 11:05:21 2017
Check interval: 2592000 (1 month)
Next check after: Thu Jul 27 11:05:21 2017

manpage:

tune2fs.man.txt

touch /forcefsck

does not seem to relibly force a filesystem check….

force filesystem check

this can only be done on unmounted partitions.

so you would have to boot from a separate partition – in order to unmount (umount) the / root-partition.

this is not possible in init 1 runlevel 1 – maintenance mode.


fsck -y -v -f /dev/sda1

e2fsck 1.43.4 (31-Jan-2017)
/dev/sda1 is mounted.
e2fsck: Cannot continue, aborting.

Links:

https://www.thomas-krenn.com/de/wiki/FSCK_Best_Practices

admin