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 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
