fsck paranoid?

Some random hints :

  1. 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.
  2. 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.



  1. 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)

  2. 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.

Leave a comment

Your email address will not be published.