Ext3 users - Oct 2005 - EXT3 journalling issue

Hello,

I have 2 boxes with 1.5TB storage with ext3 fs, and the kernel is 2.6.11.8. 
I'm using E2fsprogs 1.37 for FS creation. And, Filesystem revision #:    1 
(dynamic)

There are 2 scenarios:
1. All SATA drives, RAID5
2. All PATA drives, RAID5 and wrapped in log volumes.

I'm having lots of issues with fsck. I did search, but somehow not getting 
the right information.

needs_recovery gets set on the file system, but FS state is clean. Can I 
safely ignore this? After the default number of mounts, it gets into auto 
fsck, and it takes hours to finish it. Isn't it supposed to do it quickly? 
Can I safely set the max mount count to zero? I appreciate if anyone tells 
me more on this. I'm very new to sys admin.

Thanks..

_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

On Oct 19, 2005  13:57 -0700, sr ns wrote:
> needs_recovery gets set on the file system, but FS state is clean. Can I 
> safely ignore this?
When ext3 filesystems are mounted, needs_recovery is set until they are
unmounted.  If e2fsck is run, or the filesystem is mounted then the journal
is replayed and this flag is cleared.  This prevents the need for a full
e2fsck run.
> After the default number of mounts, it gets into auto 
> fsck, and it takes hours to finish it. Isn't it supposed to do it
quickly?
The needs_recovery + journal makes recovery after crash go quickly.  Running
a full e2fsck does not go any faster with e2fsck for ext3 filesystems, but
in most cases you don't need to run a full e2fsck, and this DOES go faster.
> Can I safely set the max mount count to zero?
Mostly, yes.  There are other forms of corruption like disk, cable, memory,
software that can cause errors in a filesystem.  Doing periodic checks
can detect these things.  Setting max mount count to zero means you skip
those checks until 6 months pass (which is max mount interval, and can
also be tuned).  Some people disable these checks because of the long e2fsck
time can lenghten downtimes.  In that case, you should instead schedule
some time when system is down to run e2fsck for a few hours.  If you are
using LVM/DM you can also make a snapshot and run e2fsck -fn on it to see
there are no problems, and then use tune2fs to update the "last
checked"
time/count.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.