Everyone that uses a journaling capable filesystem knows in case of a system halt they will not endup with a corrupted filesystem. So, there are two situations when it might be necessary running fsck: a hardware problem ( disk controller, cables, memoryu, etc) or some sort of hardware bug ( basically some problem in the filesystem’s driver ).
The whole time a I am using ext3/ext4 fsck I never found anything wrong in any of my systems. Due that I changed from 27 to 99 the mount count of my filesystem prior to an error check, because this operation might take a long time to complete and, as I said before, that does not appears to be necessary.
It is important to point out that this command can be used only if you use ext2 ( not recommended but compatible), ext3 and ext4.
tune2fs /dev/sda1 -c 99 -i 0 tune2fs 1.41.12 (17-May-2010) Setting maximal mount count to 99 Setting interval between checks to 0 seconds
Said that: /dev/sda1 is the partition we would like to increase the check interval, in my case sda1. The parameter -c 99 instructs at every 99 filesystem mounts, to run a disk check. The parameter -i 0 instructs to ignore a verification based on time lapse ( oh yes, if by any reason you did not turn on your computer for X days, the next power on, a disk check will occur regardless the mount count ).
To force a disk check in the next boot ( regardless any configuration ):
shutdown -F now
This command turns off the computer, if you’d like a reboot, just append -r.