[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Preventing ext3 fsck at boot?




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)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]