Preventing ext3 fsck at boot?

[Sandor W. Sklar]

On Sep 28, 2007, at 10:34 PM, Mike Kearey wrote:

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

Oh, I wish I was just showing off!  I never thought I'd miss the days  
where all of my storage was presented in 4 GB luns from a "top-of-the- 
line" Symmetrix, connected with lots of really long SCSI cables under  
the floor.  :-)     Our last purchase of Nexsan SATAbeasts included  
drives that were 1 TB in size; I shudder to think of the rebuild time  
when one drive in the RAID set fails.

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

That is an interesting point, and one that I didn't consider.  All of  
our RHEL systems are built from a local Satellite Server, but we have  
bought a few "retail" licenses, for the purposes of support.  So, can  
I take it that you're stating that if we were to have a problem with  
an XFS, or Reiser filesystem, and opened a support case with it, we  
might experience some issues?  That is an important point, so  
thanks ... that does help inform our decision.

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

Sure, its good for many people in many cases; irrelevant for us,  
though.  I need, in order of importance, (a) reliability, (b)  
performance, and (c) ease of administrative tasks.

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

Ah, thanks for that URL.  The man page wasn't clear on whether or not  
the filesystem needed to be unmounted (at least, to my bleary eyes,  
it wasn't.)
>
> 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 :)

Thanks very much for your help.  Generally, I agree with your opinion  
(but I'd prefer to never have to either fsck or restore filesystems  
this big!)

	-s-

--
Sandor W. Sklar
Unix Systems Administrator
Stanford University Libraries & Academic Information Resources (SULAIR)
Digital Libraries Systems & Services (DLSS)