Some random hints :
- Ensure the final field / column in /etc/fstab is non-zero for other filesystems you have mounted; if it’s 0 then fsck will never run on them.
- fsck -Cccy /dev/blah1 does a read-write (non-destructive test). Works well on SSDs
Example from /etc/fstab:
/dev/md0 /mount/point ext3 defaults 0 2
When looking at the various boxes we have in our office, I found one server had the following (run dumpe2fs /dev/whatever1):
- Mount count: 62
- Maximum mount count: 39
- Last checked: Wed Jul 9 16:09:17 2008
- Next check after: Mon Jan 5 15:09:17 2009
Today is 8th June 2012. Ooops.
Interestingly when I did run fsck on it, there were no errors. Is perhaps the default ext3 setting of checking every 20-30 mounts too paranoid? It’s certainly very painful running fsck on large ‘rotating’ volumes – waiting over an hour for a server to come up is not fun.
openSUSE has disabled the automatic fsck for ext3/4 (“0″ in /etc/fstab) since some releases, and I’m not aware of any broken filesystems.
In other words: why run fsck if you have a journal?
(yes, I know that fsck != journal, but with the journal the risk of breaking the filesystem seems to be very low)
Oh, that’s interesting to know. I wonder when/if the other distros will follow suit… I have a few public facing servers where fsck is taking /hours/ to run on (~1Tb plus volumes), and it’s a real pain.