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

Re: File system checking on ext3 after a system crash

Ted -- Thanks for your response - It was indeed very helpful.
I realized a full fsck was enforced due to  the FS went unchecked for more than 180 days (default period when the FS was created with mke2fs -j <blockdevice>)  

So my question for you and folks in the group -- Can I safely disable this behavior   of  routine fsck  with tune2fs -i 0 <blockdevice) .(By doing this I am assuming that the e2fsck program does a log replay whenever there is a system crash - and a manual intervention is needed whenever this fails.)

Are there negative implications by doing the above.

Thanks for any suggestions/Advise.


On 4/7/07, Theodore Tso <tytso mit edu> wrote:
On Fri, Apr 06, 2007 at 12:35:53PM -0400, Balu manyam wrote:
> Hi folks --   My machine is a RHEL 3 with 2.4 kernel  installed - with some
> large ext3 filesystems on drives connected internally  ( >200G)
> Now, When this system crashed (for eg:- a CPU panic /hardware error )   -
> e2fsck on this filesystem seems to be taking a long time to return thereby
> adding to the overall downtime of this system.
> could there be any workarounds for my issue?
> say for example , to have it try to replay the journal and if it fails only
> then , configure  it do a full check ?

E2fsck normally only replays the journal (a relatively quick
operation).  It will only do a full check if the filesystem was marked
as having an error (which the kernel will do if it notices an
inconsistency), or if the filesystem fails some very obvious checks
before or after the journal is run.  (But in the latter case, it
usually means the filesystem is very badly damaged and e2fsck will not
attempt to fix it via an automatic preen pass, but will instead stop
and ask for human guidance.)

So did e2fsck actually print out any inconsistencies?  It normally
will print a message saying that the filesystem was marked as having
errors, etc.  And what do you mean by "a long time"?  It depends on
disk speed, of course, but I have a 95% utilized 700 gig filsystem
which takes 40 minutes to fsck.  This is usually relatively moderm
SATA drives in a RAID 5 configuraitons, however.

Finally, are you sure the filesystem is being mounted as ext3 while
the system is in normal operation?  What does "cat /proc/mounts" say?
It could be that for some reason you are only mounting the filesystem
using ext2 (maybe the journal wasn't created, or the ext3 module
wasn't loaded, etc.)

Hope this is helpful!

                                                - Ted

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