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

RE: Preventing ext3 fsck at boot?



Check the man page of fstab.

The last field in every record indicates whether the file system is checked on reboot.

Cheers,
Mike.

 -----Original Message-----
From: 	redhat-list-bounces redhat com [mailto:redhat-list-bounces redhat com]  On Behalf Of Sandor W. Sklar
Sent:	Friday, September 28, 2007 2:42 PM
To:	General Red Hat Linux discussion list
Subject:	Preventing ext3 fsck at boot?

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.

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

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.


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

Thanks,
	-s-

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


-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request redhat com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list




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