File system checking on ext3 after a system crash

Theodore Tso tytso at
Sat Apr 7 11:44:04 UTC 2007

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

More information about the Ext3-users mailing list