At 10/31/2016 02:34 AM, Marc MERLIN wrote:
I have a filesystem on top of md raid5 that got a few problems due to the
underlying block layer (bad data cable).
The filesystem mounts fine, but had a few issues
Scrub runs (I didn't let it finish, it takes a _long_ time)
But check --repair won't even run at all:
myth:~# btrfs --version
btrfs-progs v4.7.3
myth:~# uname -r
4.8.5-ia32-20161028
myth:~# btrfs check -p --repair /dev/mapper/crypt_bcache0 2>&1 | tee
/var/spool/repair
bytenr mismatch, want=13835462344704, have=0
ERROR: cannot read chunk root
Your chunk root is corrupted, and since chunk tree provides the
underlying disk layout, even for single device, so if we failed to read
it, then it will never be able to be mounted.
You could try to use backup chunk root.
"btrfs inspect-internal dump-super -f" to find the backup chunk root,
and use "btrfs check --chunk-root <backup chunk root bytenr>" to have
another try.
Thanks,
Qu
Couldn't open file system
enabling repair mode
myth:~#
myth:~# btrfs rescue super-recover -v /dev//mapper/crypt_bcache0
All Devices:
Device: id = 1, name = /dev//mapper/crypt_bcache0
Before Recovering:
[All good supers]:
device name = /dev//mapper/crypt_bcache0
superblock bytenr = 65536
device name = /dev//mapper/crypt_bcache0
superblock bytenr = 67108864
device name = /dev//mapper/crypt_bcache0
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
I don't care about the data, it's a backup array, but I'd still like to know
if I can recover from this state and do a repair to see how much data got
damaged
Thanks,
Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
