Ivan P wrote on 2016/03/27 16:31 +0200:
Thanks for the reply,
the raid1 array was created from scratch, so not converted from ext*.
I used btrfs-progs version 4.2.3 on kernel 4.2.5 to create the array, btw.
I don't remember any strange behavior after 4.0, so no clue here.
Go to the subvolume 5 (the top-level subvolume), find inode 71723 and
try to remove it.
Then, use 'btrfs filesystem sync <mount point>' to sync the inode removal.
Finally use latest btrfs-progs to check if the problem disappears.
This problem seems to be quite strange, so I can't locate the root
cause, but try to remove the file and hopes kernel can handle it.
Thanks,
Qu
Is there a way to fix the current situation without taking the whole
data off the disk?
I'm not familiar with file systems terms, so what exactly could I have
lost, if anything?
Regards,
Ivan
On Sun, Mar 27, 2016 at 4:23 PM, Qu Wenruo <quwenruo.bt...@gmx.com
<mailto:quwenruo.bt...@gmx.com>> wrote:
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 <chrnosphe...@gmail.com
<mailto:chrnosphe...@gmail.com>> 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 majord...@vger.kernel.org
<mailto:majord...@vger.kernel.org>
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
