>From: Andreas Dilger <adilger@clusterfs.com>
>To: Andy Paul <aaspaul@hotmail.com>
>CC: ext3-users@redhat.com
>Subject: Re: ext3 crash
>Date: Mon, 8 Apr 2002 02:23:17 -0600
>
>On Apr 08, 2002 15:08 +0900, Andy Paul wrote:
> > - I suppose I can survive without it. Would have used RAID, had I needed
>an
> > insurance policy. I am more concerned about not finding the cause and
> > having the same experience repeated next time.
>
>Well, RAID is not a form of backup, especially in a case like this. It
>only protects you from disk failures, not software screw-ups.
>
> > - The error sequence started when a user tried to access some data using
> > samba. Noticing some strange delay, he cancelled the request, however
>samba
> > (?) seemed to have entered some retry loop, trying to access various
> > inodes/blocks for about 1 hour, and filling the log with errors.
>
>Sounds like a software problem to me.
>
> > #od -Ax -tx4 /dev/hda9
> > 000200 9a038c08 9476785f 49bf458f c00096e3
> > : : : : :
> > 0003f0 d9995854 d6aaaddf 04b01455 41407ffe
>
>This chunk is repeated every few sectors on your disk. This is why I
>think it looks like a software problem.
>
> > 000400 00664000 00cc7892 000a393a 00267129
> > 000410 00662dfc 00000000 00000002 00000002
> > 000420 00008000 00008000 00004000 3ca7c82d
> > 000430 3cb11525 00250019 0003ef53 00000001
> > 000440 3c05b658 00ed4e00 00000000 00000001
> > 000450 00000000 0000000b 00000080 00000004
> > 000460 00000002 00000001 a73c96f6 d34646c9
> > 000470 8258dcb3 d03f0f27 6168732f 00366572
>
>This seems like a normal superblock (probably written out later over the
>rest of the junk on the disk).
>
> > 000800 9a038c08 9476785f 49bf458f c00096e3
> > : : : : :
> > 0009f0 d9995854 d6aaaddf 04b01455 41407ffe
> > 000a00 9a038c08 9476785f 49bf458f c00096e3
> > : : : : :
> > 000bf0 d9995854 d6aaaddf 04b01455 41407ffe
> > 000c00 9a038c08 9476785f 49bf458f c00096e3
> > : : : : :
> > 000e00 9a038c08 9476785f 49bf458f c00096e3
> > : : : : :
> > 000ff0 d9995854 d6aaaddf 04b01455 41407ffe
>
> > #./findsuper /dev/hda9 512 0
> > starting at 0, with 512 byte increments
> > thisoff block fs_blk_sz blksz grp last_mount
> > 1024 1 13400210 4096 0 Mon Apr 1 11:38:37 2002
>
>Normal superblock...
>
> > 8053760 7865 13400210 4096 0 Mon Apr 1 11:38:37 2002
> > : : : : : : : : : : :
> > 8082432 7893 13400210 4096 0 Mon Apr 1 11:38:37 2002
>
>Superblocks in the journal...
>
> > 134217728 131072 13400210 4096 1 Mon Apr 1 11:38:37 2002
> > 402653184 393216 13400210 4096 3 Mon Apr 1 11:38:37 2002
> > 671088640 655360 13400210 4096 5 Mon Apr 1 11:38:37 2002
> > 939524096 917504 13400210 4096 7 Mon Apr 1 11:38:37 2002
> > 1207959552 1179648 13400210 4096 9 Mon Apr 1 11:38:37 2002
> > 3355443200 3276800 13400210 4096 25 Mon Apr 1 11:38:37 2002
> > 3623878656 3538944 13400210 4096 27 Mon Apr 1 11:38:37 2002
> > 6576668672 6422528 13400210 4096 49 Mon Apr 1 11:38:37 2002
> > 10871635968 10616832 13400210 4096 81 Mon Apr 1 11:38:37 2002
>
>Backup superblocks. ^^^^ Try using some of these numbers for e2fsck,
>
>e2fsck -b 131072 /dev/hda9
>e2fsck -b 393216 /dev/hda9
>e2fsck -b 917504 /dev/hda9
>:
>
e2fsck produced the following output :
---------
# e2fsck -b 131072 /dev/hda9
e2fsck 1.26 (3-Feb-2002)
e2fsck: Bad magic number in super-block while trying to open /dev/hda9
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# e2fsck -b 393216 /dev/hda9
e2fsck 1.26 (3-Feb-2002)
e2fsck: Bad magic number in super-block while trying to open /dev/hda9
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
# e2fsck -b 10616832 /dev/hda9
e2fsck 1.26 (3-Feb-2002)
e2fsck: Attempt to read block from filesystem resulted in short read while
trying to open /dev/hda9
Could this be a zero-length partition?
# e2fsck -b 6422528 /dev/hda9
e2fsck 1.26 (3-Feb-2002)
e2fsck: Bad magic number in super-block while trying to open /dev/hda9
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
-----------
I think I would like to stop at this point, due to lack of time ( and
patience). I will reformat the partition tomorrow.
Andreas, thank you for your time.
Adrian
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
