On 03/27/2016 05:54 PM, Ivan P wrote:
Read the info on the wiki, here's the rest of the requested information:
# uname -r
4.4.5-1-ARCH
# btrfs fi show
Label: 'ArchVault' uuid: cd8a92b6-c5b5-4b19-b5e6-a839828d12d8
Total devices 1 FS bytes used 2.10GiB
devid 1 size 14.92GiB used 4.02GiB path /dev/sdc1
Label: 'Vault' uuid: 013cda95-8aab-4cb2-acdd-2f0f78036e02
Total devices 2 FS bytes used 800.72GiB
devid 1 size 931.51GiB used 808.01GiB path /dev/sda
devid 2 size 931.51GiB used 808.01GiB path /dev/sdb
# btrfs fi df /mnt/vault/
Data, RAID1: total=806.00GiB, used=799.81GiB
System, RAID1: total=8.00MiB, used=128.00KiB
Metadata, RAID1: total=2.00GiB, used=936.20MiB
GlobalReserve, single: total=320.00MiB, used=0.00B
On Fri, Mar 25, 2016 at 3:16 PM, Ivan P <chrnosphered@xxxxxxxxx> wrote:
Hello,
using kernel 4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on my
2x1Tb btrfs raid1 array and it finished with 36 unrecoverable errors
[1], all blaming the treeblock 741942071296. Running "btrfs check
--readonly" on one of the devices lists that extent as corrupted [2].
How can I recover, how much did I really lose, and how can I prevent
it from happening again?
If you need me to provide more info, do tell.
[1] http://cwillu.com:8080/188.110.141.36/1
This message itself is normal, it just means a tree block is crossing
64K stripe boundary.
And due to scrub limit, it can check if it's good or bad.
But....
[2] http://pastebin.com/xA5zezqw
This one is much more meaningful, showing several strange bugs.
1. corrupt extent record: key 741942071296 168 1114112
This means, this is a EXTENT_ITEM(168), and according to the offset, it
means the length of the extent is, 1088K, definitely not a valid tree
block size.
But according to [1], kernel think it's a tree block, which is quite
strange.
Normally, such mismatch only happens in fs converted from ext*.
2. Backref 741942071296 root 5 owner 71723 offset 2589392896 num_refs 0
not found in extent tree
num_refs 0, this is also strange, normal backref won't have a zero
refrence number.
3. bad metadata [741942071296, 741943185408) crossing stripe boundary
It could be a false warning fixed in latest btrfsck.
But you're using 4.4.1, so I think that's the problem.
4. bad extent [741942071296, 741943185408), type mismatch with chunk
This seems to explain the problem, a data extent appears in a metadata
chunk.
It seems that you're really using converted btrfs.
If so, just roll it back to ext*. Current btrfs-convert has known bug
but fix is still under review.
If want to use btrfs, use a newly created one instead of btrfs-convert.
Thanks,
Qu
Regards,
Soukyuu
P.S.: please add me to CC when replying as I did not subscribe to the
mailing list. Majordomo won't let me use my hotmail address and I
don't want that much traffic on this address.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
