EXT3 journalling issue

sr ns sr_linux at hotmail.com
Wed Oct 26 18:57:01 UTC 2005


But, I have got more issues. The fsck.ext3 takes a long time (> 90min), and 
sometimes it fails.

I ran the debugfs and checked the journal (inode 8):

#/sbin/debugfs /dev/sda2
debugfs 1.35 (28-Feb-2004)
debugfs:  stat <8>
Inode: 8   Type: regular    Mode:  0600   Flags: 0x0   Generation: 0
User:     0   Group:     0   Size: 33554432
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 65616
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x43041631 -- Thu Aug 18 05:01:37 2005
atime: 0x00000000 -- Thu Jan  1 00:00:00 1970
mtime: 0x43041631 -- Thu Aug 18 05:01:37 2005
(0-11):1633-1644, (IND):1645, (12-1035):1646-2669, (DIND):2670, (IND):2671, 
672-3695, (IND):3696, (2060-3083):3697-4720, (IND):4721, 
(3084-4107):4722-5745, (IND):574
6, (4108-5131):5747-6770, (IND):6771, (5132-6155):6772-7795, (IND):7796, 
-8820, (IND):8821, (7180-8192):8822-9834
TOTAL: 8202

Wed Oct 26 18:09:50 GMT 2005

#/sbin/dumpe2fs -h /dev/sda2
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          22bdad74-262f-491a-ba79-a543f1900e9c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index 
filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              183091200
Block count:              366171553
Reserved block count:     18308577
Free blocks:              64052904
Free inodes:              183032464
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Thu Aug 18 04:49:58 2005
Last mount time:          Wed Oct 26 14:17:10 2005
Last write time:          Wed Oct 26 14:17:10 2005
Mount count:              134
Maximum mount count:      -1
Last checked:             Thu Aug 18 04:49:58 2005
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      04ee4b29-93a7-4e6c-8d34-7eaa6234dd03
Journal backup:           inode blocks

The "mtime" (modified time?) is Aug 2005. Is there something wrong with 
this? Where exactly is the journal maintained? This is from a good box (with 
no fsck errors) - I don't have access to the affected box right now. But, 
it's similar to this in every way.

What's the significance of "max mount count=-1"?

I'm using the default rc.sysinit script of Fedora distro.

Can you point me to some good doc (working details) on ext3 and journalling? 
Reading the code would be my last option. Sorry, I don't mean to be 
rude/lazy here. This is not my domain, and I'm just trying to fix this.

Thanks for any advise.

>From: Andreas Dilger <adilger at clusterfs.com>
>To: sr ns <sr_linux at hotmail.com>
>CC: ext3-users at redhat.com
>Subject: Re: EXT3 journalling issue
>Date: Mon, 24 Oct 2005 13:20:40 -0600
>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 
>The needs_recovery + journal makes recovery after crash go quickly.  
>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 
>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"
>Cheers, Andreas
>Andreas Dilger
>Principal Software Engineer
>Cluster File Systems, Inc.

Don’t just search. Find. Check out the new MSN Search! 

More information about the Ext3-users mailing list