Hello,
I looked through the archives a bit and could not find anything relevant,
if you know otherwise please point me in the right direction.
I have a ~3T ext3 filesystem on linux software raid that had been behaving
corectly for sometime. Not to long ago it gave the following error after
trying to mount it:
mount: wrong fs type, bad option, bad superblock on /dev/md0,
or too many mounted file systems
after a long fsck which I had to do manually I noticed the following in
/var/log/messages after trying to mount again:
Jan 19 09:13:11 terrorbytes kernel: EXT3-fs error (device md0):
ext3_check_descriptors: Block bitmap for group 3584 not in group (block
0)!
Jan 19 09:13:11 terrorbytes kernel: EXT3-fs: group descriptors corrupted !
when trying to correct again with e2fsck I get this error:
e2fsck 1.34 (25-Jul-2003)
Group descriptors look bad... trying backup blocks...
e2fsck: Invalid argument while checking ext3 journal for /dev/md0
some more information on the system:
os flavor: Suse 9.1
kernel version: 2.6.5-7.202.7-default (various suse patches applied to
2.6.5 kernel)
I am not sure where to go from here, any help, experience, or references
to documentation that would help me better understand the problem would be
apreciated.
Sincerely,
Dennison Williams
"And for all the good or evil, creation or destruction
your living might have of accomplished, you might have
just never have lived at all"
-The Sleeping Beauty
On Jan 18, 2006 16:16 -0800, Dennis Williams wrote:> I looked through the archives a bit and could not find anything relevant, > if you know otherwise please point me in the right direction. > > I have a ~3T ext3 filesystem on linux software raid that had been behaving > corectly for sometime. Not to long ago it gave the following error after > trying to mount it: > > mount: wrong fs type, bad option, bad superblock on /dev/md0, > or too many mounted file systemsThis sounds like the superblock has been overwritten. There are occasional reports from > 2TB filesystem users of similar corruption. It isn't clear if the problem exists in ext3 or if it is in the block or SCSI layer.> some more information on the system: > os flavor: Suse 9.1 > kernel version: 2.6.5-7.202.7-default (various suse patches applied to > 2.6.5 kernel)RHEL4 (2.6.9) claims support for up to 8TB filesystems. I don't know what patches they made, if any, in order to have this working. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
This is a 64 bit system running a 64 bit kernel.
After reading through the manpage for e2fsck a bit I noticed that mke2fs
can be used to determine additional superblock backups with the -n flag.
Not knowing how the fs was created I assumed that the default blocksize
was used.
terrorbytes:~ # mke2fs -n /dev/md0
mke2fs 1.34 (25-Jul-2003)
warning: 160 blocks unused.
Filesystem labelOS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
403685856 inodes, 805797888 blocks
40289902 blocks (5.00%) reserved for the super user
First data block=0
24591 block groups
32768 blocks per group, 32768 fragments per group
16416 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616,
78675968,
102400000, 214990848, 512000000, 550731776, 644972544
terrorbytes:~ # e2fsck -yb 229376 /dev/md0
The system has now been corecting errors for the past 12 hours. I hope
when it finishes, it will mount without complaints.
Sincerely,
Dennis Williams
"And for all the good or evil, creation or destruction
your living might have of accomplished, you might have
just never have lived at all"
-From: The Sleeping Beauty
On Wed, 18 Jan 2006, Dennis Williams wrote:
> Hello,
> I looked through the archives a bit and could not find anything relevant,
> if you know otherwise please point me in the right direction.
>
> I have a ~3T ext3 filesystem on linux software raid that had been behaving
> corectly for sometime. Not to long ago it gave the following error after
> trying to mount it:
>
> mount: wrong fs type, bad option, bad superblock on /dev/md0,
> or too many mounted file systems
>
> after a long fsck which I had to do manually I noticed the following in
> /var/log/messages after trying to mount again:
>
> Jan 19 09:13:11 terrorbytes kernel: EXT3-fs error (device md0):
> ext3_check_descriptors: Block bitmap for group 3584 not in group (block
> 0)!
> Jan 19 09:13:11 terrorbytes kernel: EXT3-fs: group descriptors corrupted !
>
> when trying to correct again with e2fsck I get this error:
>
> e2fsck 1.34 (25-Jul-2003)
> Group descriptors look bad... trying backup blocks...
> e2fsck: Invalid argument while checking ext3 journal for /dev/md0
>
> some more information on the system:
> os flavor: Suse 9.1
> kernel version: 2.6.5-7.202.7-default (various suse patches applied to
> 2.6.5 kernel)
>
> I am not sure where to go from here, any help, experience, or references
> to documentation that would help me better understand the problem would be
> apreciated.
>
> Sincerely,
> Dennison Williams
>
> "And for all the good or evil, creation or destruction
> your living might have of accomplished, you might have
> just never have lived at all"
> -The Sleeping Beauty
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>
> > The system has now been corecting errors for the past 12 hours. I hope > > when it finishes, it will mount without complaints. > > Never belive fsck here. It may check heavy corrupted filesystems serval DAYS. > For me (corrupted 120 Gb ext3 partition) "fsck.ext3 -y" work 3 days before i > interrupt it. In manual mode, avoid 'duplicate inode clone' and answer yes to > 'delete file' - only 30 minutes. >Just out of morbid curiosity what does 'duplicate inode clone' mean? And how does the fs get in that state? The fsck finished this morning with the following final statements: /dev/md0: ***** FILE SYSTEM WAS MODIFIED ***** /dev/md0: ********** WARNING: Filesystem still has errors ********** /dev/md0: 1472505/403685856 files (10.3% non-contiguous), 673983041/805797888 blocks 1) Why would the fs still have errors? Is it correct to assume that running fsck again is the answer? (I hope so) 2) What does the last line of this message mean? I did notice that the fs mounted correctly after this with the following errors in /var/log/messages: Jan 21 02:09:48 terrorbytes kernel: kjournald starting. Commit interval 5 seconds Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning (device md0): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning (device md0): ext3_clear_journal_err: Marking fs in need of filesystem check. Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning: mounting unchecked fs, running e2fsck is recommended Jan 21 02:09:48 terrorbytes kernel: EXT3 FS on md0, internal journal Jan 21 02:09:48 terrorbytes kernel: EXT3-fs: mounted filesystem with ordered data mode. after unmounting the filesystem, I ran a standard fsck again: terrorbytes:~ # e2fsck /dev/md0 e2fsck 1.34 (25-Jul-2003) /dev/md0 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Thank you to everyone who has responded to my posts with thier suggestions. Sincerely, Dennison Williams