ext3 crash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
:

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/





[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux