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@xxxxxxxxxxx.
corrupt dinode 6242615, (btree extents). This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxx.
corrupt dinode 6242615, (btree extents). This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxx.
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
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
