Red Hat Bugzilla – Bug 47525
rc.sysinit fsck's ext3 / filesystems
Last modified: 2014-03-16 22:21:36 EDT
rc.sysinit nullifies the advantage of journalling in ext3 root partitions,
as it runs an fsck against root. Not the end of the world, but if the "/"
partition is big, it takes a while, and users feel that they're not getting
their moneys worth from ext3. Is their some ext3 detection that can be
done so as to tell the fsck portion of rc.sysinit to to a test check that
*doesn't* fix everything (so that the journal can)?
AFAIK, e2fsck does the right thing (skips fsck on ext3 unless it's needed.)
What e2fsprogs do you have installed?
The current behaviour is correct. The initscripts _must_ call fsck for ext3
filesystems. If the filesystem has an error on it, or if it has exceeded its
maximum time between fscks (which you can set via tune2fs), e2fsck will do a
full run on the filesystem. But if not, fsck will just recover the journal and
will not do a full check, so you get the right behaviour.
If you are getting a full fsck on your root filesystem every time, then there's
something else wrong --- probably it is only being mounted as ext2. Try a
to verify what the kernel thinks the root filesystem is. If you change the root
filesystem type to ext3 in /etc/fstab, you still need to rerun mkinitrd to cause
it to be remounted as ext3 on the next boot, otherwise you'll still be mounting
root as ext2 and you'll get the fsck-on-reboot that you described.