Preventing ext3 fsck at boot?

[Mike Kearey]

Sandor W. Sklar wrote:
> I've got a number of large EXT3 filesystems (2-8 TB each), presented via
> dual-path Fibre HBAs via SAN switches from several Nexsan SATAbeast
> arrays, to a number of systems running RHEL4.
> 


Now, you're just showing off :) Imagine 2 -8TB's 20 years ago:


http://sd4.sd-lj.si/diggit/20yago.jpg 1GB 20 years ago compared to a
flash available now.


> The question of whether EXT3 is the right filesystem to be using for
> this is probably best saved for another email (but I'd love to hear
> about better options; I'm relatively new to Linux, compared to AIX and
> Solaris.)
> 

ext3 is best used on a RHEL4 system because it's what we develop, test
and support. That is a very important consideration. Note that this does
not mean it's the best one on a technical and theoretical or performance
standpoint.


> My main problem is that when we reboot these servers for scheduled
> maintenance (or for any reason), odds are pretty good that I'm going to
> get the (dreaded) ...
> 
>     /dev/nsvg/lvol0 has gone 182 days without being checked, check forced.
> 
> ... message, and then my downtime is extended by 2-3 hours while the
> system does its fsck (and usually finds o problems.)
> 
> So, my questions are:
> 
> - The man page for tune2fs says that this can be disabled with the "-c"
> option, but recommends strongly against it.  Is it really such a bad
> thing to disable, if I'm using EXT3 (with the journaling that makes it
> "3" instead of "2")?  I've used JFS/JFS2 for years on AIX, and UFS
> journaling on Solaris, and neither seems to want to force an fsck just
> because some arbitrary time period has past since it last checked.
> 

ext2 is Linux extended filesystem 2. ext3 is Linux extended filesystem 3

The major difference between the two is the journal capability in ext3.
ext3 filesystem can be mounted as ext2 BTW, backwards compatibility is good.


> 
> - If the consensus is that it would be ok to disable these checks, what
> is the proper syntax?  I tried:
> 
>     # tune2fs -c0  /dev/mapper/nsvg-lvol0
>     tune2fs 1.35 (28-Feb-2004)
>     Setting maximal mount count to -1
> 
> ... but that didn't work.  Looking for some practical advice and
> recommendations, here, please!

We have the kbase article  http://kbase.redhat.com/faq/FAQ_80_5779.shtm
It says that the filesystem needs to be unmount, but I am not completely
sure that is required.

Anyway, verify it is set :

# dumpe2fs /dev/mapper/myvg-rootvol  |grep Max
dumpe2fs 1.39 (29-May-2006)
Maximum mount count:      -1


That should be enough. I believe RHEL5 comes delivered with Maximum
mount count set this way for the root filesystem.

In my opinion when you have more 800GB for a filesystem you are well and
truly at a point where an fsck is a waste of time compared to a clean
mkfs and restore from backup. So take the dire warnings from the tune2fs
manual as something that was valid and relevent 5 years ago or more and
not quite applicable to your situation :)



Cheers
Michael