Re: scrub: Tree block spanning stripes, ignored

[Ivan P <chrnosphered@gmail.com>]

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?

Regards,
Ivan

On Mon, Mar 28, 2016 at 3:10 AM, Qu Wenruo <quwenruo.btrfs@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.btrfs@gmx.com
>> <mailto:quwenruo.btrfs@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 <chrnosphered@gmail.com
>>         <mailto:chrnosphered@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 majordomo@vger.kernel.org
>>         <mailto:majordomo@vger.kernel.org>
>>         More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>