Ivan P wrote on 2016/03/28 23:21 +0200:
Well, the file in this inode is fine, I was able to copy it off the
disk. However, rm-ing the file causes a segmentation fault. Shortly
after that, I get a kernel oops. Same thing happens if I attempt to
re-run scrub.
How can I delete that inode? Could deleting it destroy the filesystem
beyond repair?
The kernel oops should protect you from completely destroying the fs.
However it seems that the problem is beyond kernel's handle (kernel oops).
So no safe recovery method now.
From now on, any repair advice from me *MAY* *destroy* your fs.
So please do backup when you still can.
The best possible try would be "btrfsck --init-extent-tree --repair".
If it works, then mount it and run "btrfs balance start <mnt>".
Lastly, umount and use btrfsck to re-check if it fixes the problem.
Thanks,
Qu
Regards,
Ivan
On Mon, Mar 28, 2016 at 3:10 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
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
--
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
