Thanks!
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
BLOCKS:
(0-11):1633-1644, (IND):1645, (12-1035):1646-2669, (DIND):2670, (IND):2671,
(1036-2059):2
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,
(6156-7179):7797
-8820, (IND):8821, (7180-8192):8822-9834
TOTAL: 8202
==================
==================
#date
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@xxxxxxxxxxxxx>
To: sr ns <sr_linux@xxxxxxxxxxx>
CC: ext3-users@xxxxxxxxxx
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
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.
_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
