xfs
[Top] [All Lists]

Re: Problem repairing filesystem

To: XFS mailing list <linux-xfs@xxxxxxxxxxx>
Subject: Re: Problem repairing filesystem
From: Paul Schutte <paul@xxxxxxxx>
Date: Fri, 16 Aug 2002 10:28:30 +0200
References: <3D5A3174.1A91A496@up.ac.za>
Sender: owner-linux-xfs@xxxxxxxxxxx
I am sorry to interrupt the discussion on software raid,
but I think that it would be possible to save my 320Gb data partition.

xfs_repair return the following error:

fatal error -- can't read block 0 for directory inode 2097749

If I connect with xfs_db:

xfs_db -r /dev/sda3
xfs_db: inode 2097749
xfs_db: print
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.atime.sec = Thu Aug  8 00:09:45 2002
core.atime.nsec = 870865000
core.mtime.sec = Wed Aug  7 02:06:59 2002
core.mtime.nsec = 862258000
core.ctime.sec = Wed Aug  7 02:06:59 2002
core.ctime.nsec = 862258000
core.size = 8192
core.nblocks = 2
core.extsize = 0
core.nextents = 2
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 3
next_unlinked = null
u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[1,131077,1,0]
1:[8388608,131078,1,0]

xfs_db: fsb 131077
xfs_db: type dir2
xfs_db: print

--snip--
du[93].inumber = 2232717
du[93].namelen = 14
du[93].name = "94_numaq-tsc-4"
du[93].tag = 0xca8
du[94].inumber = 2232718
du[94].namelen = 25
du[94].name = "95_fsync-corruption-fix-2"
du[94].tag = 0xcc8
du[95].inumber = 2232719
du[95].namelen = 28
du[95].name = "96_inode_read_write-atomic-3"
du[95].tag = 0xcf0
du[96].inumber = 2232720
du[96].namelen = 28
du[96].name = "97_i_size-corruption-fixes-1"
du[96].tag = 0xd18
du[97].inumber = 2232721
du[97].namelen = 13
du[97].name = "9900_aio-2.gz"
du[97].tag = 0xd40
du[98].inumber = 2232722
du[98].namelen = 18
du[98].name = "9900_aio-API-x86-2"
du[98].tag = 0xd58
du[99].inumber = 2232723
du[99].namelen = 24
du[99].name = "9910_shm-largepage-2.bz2"
du[99].tag = 0xd78
du[100].inumber = 2232724
du[100].namelen = 29
du[100].name = "9910_shm-largepage-2.bz2.sign"
du[100].tag = 0xda0
du[101].inumber = 2232725
du[101].namelen = 23
du[101].name = "9910_shm-largepage-2.gz"
du[101].tag = 0xdc8
du[102].inumber = 2232726
du[102].namelen = 28
du[102].name = "9910_shm-largepage-2.gz.sign"
du[102].tag = 0xdf0
du[103].inumber = 2097749
du[103].namelen = 1
du[103].name = "."
du[103].tag = 0xe18
du[104].freetag = 0xffff
du[104].length = 0x1d8
du[104].tag = 0xe28

This suggests to me that the data is still there.
If only we could get xfs_repair to finnish it's job and not exit with this
error.

We tried 3 versions of xfs_repair(1.2.0, 2.0.3, 2.2.1), but they all exit
with the same error.


Paul


Paul Schutte wrote:

> Background:
> ----------------
>
> I ran a ftp server on a pentium II 333Mhz with 256M RAM, using the
> 2.4.9-31-xfs kernel.
> Used 4 x 120 Gb IDE drives in a RAID 5 array on an Adaptec 2400 hardware
> raid controller.
> There is a 4Gb root partition and a +/- 320Gb data partition.
>
> One of the drives failed and the machine crashed.
> We replaced the drive and rebuild the array.
>
> I booted up with a CD that I created a while a go with
> 2.4.19-pre9-20020604 and mounted a
> nfs root partition with all the xfs tools on it.
> We ran xfs_repair (version 2.2.1) on the root partition of the raid
> array.
> A lot of the files have the dreaded zero problem, but apart from that it
> is mountable and usable.
>
> The problem:
> ------------------
>
> We ran xfs_repair on the 320Gb partition.
>
> After about 15min xfs_repair died with 'Terminated' being print on the
> console.
>
> dmesg reveals:
> Out of Memory: Killed process 269 (xfs_repair).
>
> I recreated the swap partition and activated it.
>
> Ran xfs_repair again.
>
> <xfs_repair>
> --snip--
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - ensuring existence of lost+found directory
>         - traversing filesystem starting at / ...
>         - traversal finished ...
>         - traversing all unattached subtrees ...
>
> fatal error -- can't read block 0 for directory inode 2097749
> </xfs_repair>
>
> When you mount the filesystem, it is empty (except for lost+found which
> is also empty)
>
> The output of xfs_repair is large about 300k bzip2'ed. It would be best
> if interested parties download it.
>
> http://www2.up.ac.za/paul/xfs_repair.out.bz2
>
> http://www2.up.ac.za/paul/dmesg.out.bz2
>
> Questions:
> --------------
> Have I lost the 320G partition or does someone still have a trick up
> their sleeve ?
>
> Would it be possible to make xfs_repair use a lot less memory ?
> My guess is that the filesystem got it's final blow by xfs_repair
> exiting prematurely.
>
> Any suggestions are welcome.
>
> Paul Schutte


<Prev in Thread] Current Thread [Next in Thread>