xfs
[Top] [All Lists]

"Corrupt dinode 6242615, (btree extents). This is a bug."

To: xfs@xxxxxxxxxxx
Subject: "Corrupt dinode 6242615, (btree extents). This is a bug."
From: Hanne Munkholm <hanne@xxxxxxxxxx>
Date: Mon, 8 Aug 2011 12:05:09 +0200 (CEST)
User-agent: Alpine 1.00 (OSX 882 2007-12-20)
Hi list.

I have an xfs file system which got damaged due to not being
properly unmounted before the iSCSI connection terminated (I
think. Corrupted it is).

I cannot mount it. mount: wrong fs type, bad option, bad superblock on /dev/sdd,
        missing codepage or helper program, or other error
        In some cases useful info is found in syslog - try
        dmesg | tail  or so

xfs_check suggests running xfs_repair -L. ERROR: The filesystem has valuable metadata changes in a log
which needs to be replayed.  Mount the filesystem to replay the log, and
unmount it before re-running xfs_check.  If you are unable to mount the
filesystem, then use the xfs_repair -L option to destroy the log and attempt a
repair.  Note that destroying the log may cause corruption -- please
attempt a mount of the filesystem before doing this.

I haven't done that yet.

Instead I ran
xfs_repair -n.
I got a lot of output that looks promising for a repair IMO, at
least it acknowleges an xfs system beoing there:

xfs_repair -n /dev/sdd
Phase 1 - find and verify superblock...
Phase 2 - using internal log
         - scan filesystem freespace and inode maps...
         - found root inode chunk
Phase 3 - for each AG...
         - scan (but don't clear) agi unlinked lists...
         - process known inodes and perform inode discovery...
         - agno = 0
bad nblocks 952 for inode 6242615, would reset to 972
bad nextents 182 for inode 6242615, would reset to 185
imap claims a free inode 13352640 is in use, would correct imap and clear inode
imap claims a free inode 13352641 is in use, would correct imap and clear inode
<snip>
        - agno = 1
         - agno = 2
         - agno = 3
         - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
         - setting up duplicate extent list...
         - check for inodes claiming duplicate blocks...
         - agno = 0
         - agno = 3
         - agno = 2
         - agno = 1
bad nblocks 952 for inode 6242615, would reset to 972
bad nextents 182 for inode 6242615, would reset to 185
entry "sample_000001299840_0_0.000000.pdb" at block 764 offset
2512 in directory inode 6242615 references free inode 13352640
        would clear inode number in entry at offset 2512...
entry "sample_000001299860_0_0.000000.pdb" at block 764 offset
2560 in directory inode 6242615 references free inode 13352641
<snip>
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
         - traversing filesystem ...
corrupt dinode 6242615, (btree extents).  This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxxx
corrupt dinode 6242615, (btree extents).  This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxxx
corrupt dinode 6242615, (btree extents).  This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxxx
Segmentation fault

But then it fails in phase 6, as shown above.

My questions are now:

a) Does it look like clearing the log with -L would be a good
idea? To me it looks like a lot of errors that are not log
errors is found?

b) What's with the segfault? What happens when the "real" repair
with no -n gets to the segfault? Is it dangerous to try it if it
segfaults somewhere halfway? (More dangerous than it would
normally be).

It is a 6TB file system and I am running a terribly old Xen
kernel: 2.6.26-2-xen-amd64 #1 SMP Mon Jun 13 18:44:16 UTC 2011
x86_64 GNU/Linux

I have placed a xfs_metadump here:
http://people.binf.ku.dk/hanne/tmp/metadata.gz

Thanks in advance for some help in interpreting what the xfs
tools are telling me.

PS We do have some backup so I am not interested in smug
comments about backup :) only in technical help in repairing
this file system or concluding that we cannot).


Med venlig hilsen / Best regards
--
Hanne Munkholm                      Email: hanne@xxxxxxxxxx
Systemadministrator                 Tlf: +45 35 32 13 49

Bioinformatik-centret
Københavns Biocenter, Biologisk Institut
Ole Maaløes Vej 5, 2200 København N

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