Re: btrfs check --init-csum-tree removes csums again

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: btrfs check --init-csum-tree removes csums again
From: Karl-Philipp Richter <richter@richtercloud.de>
To: Tim DeNike <tim@denike.us>, Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Date: 2015年02月17日 12:18
> Hi,
> Now I could rebuild the csum tree with `--repair --init-csum-tree` with
> 3.18.2 on Linux 3.19, see the attached output for the things which were
> fixed and probably caused the problem.
>
> Thanks for your suggestions!
>
> Best regards,
> Kalle
>
> Am 16.02.2015 um 12:19 schrieb Karl-Philipp Richter:
>> Hi,
>> I get the same output except some differences in address offsets:
>>
>>      $ sudo btrfs check --init-csum-tree /dev/disk/by-uuid/bd6298ea-
>> 0748-45fe-87c8-eace6793ca89
>>      Creating a new CRC tree
>>      Checking filesystem on
>> /dev/disk/by-uuid/bd6298ea-0748-45fe-87c8-eace6793ca89
>>      UUID: bd6298ea-0748-45fe-87c8-eace6793ca89
>>      Reinit crc root
>>      extent-tree.c:2657: btrfs_reserve_extent: Assertion `ret` failed.
>>      btrfs[0x43da2a]
>>      btrfs(btrfs_reserve_extent+0xb63)[0x44347a]
>>      btrfs(btrfs_alloc_free_block+0x5a)[0x4434f5]
>>      btrfs[0x4368db]
>>      btrfs(btrfs_search_slot+0x11d1)[0x438652]
>>      btrfs(btrfs_csum_file_block+0x3ce)[0x447b35]
>>      btrfs(cmd_check+0xf76)[0x426191]
>>      btrfs(main+0x15d)[0x40993d]
>>      /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fe6b0807ec5]
>>      btrfs[0x4094f9]
According to this, there is something wrong in extent tree, or the csum 
rebuild takes up the whole space left.

For the former case, it maybe fixed by --init-extent-tree option and 
then --init-csum-tree, if other trees are not
corrupted.
(run --init-extent-tree with --init-csum-tree has a bug which will only 
rebuild extent tree but not csum tree,
causing all data csum missing, fixing patch: 
https://patchwork.kernel.org/patch/5706501/)

For the later case, maybe the --init-extent-tree method can also help, 
since the old method didn't free the old
extents of csum tree, causing the csum tree takes twice the space and 
causing the ENOSPC BUG_ON.

Thanks,
Qu
>>
>> with 3.18.2 and 3.19-rc2. The check runs for hours completing reading up
>> to 90 % of the device.
>>
>> Find kern.log attached, but there's nothing in it afaik except 1
>> trillion complaints about missing csums... In case you wonder why
>> there're so many segmentation faults in crucial programs - It's from an
>> Ubuntu 14.10 system ;). I'm running the amd64 version.
>>
>> Best regards,
>> Kalle
>>
>> Am 16.02.2015 um 11:21 schrieb Tim DeNike:
>>> I just ran through with vanilla 3.19 kernel and btrfs-progs 3.18.2
>>> with the same result.  Nothing in kernel log at all. Output of btrfs
>>> check below.
>>>
>>> [root@938el btrfs-progs]# ./btrfs check --repair --init-csum-tree /dev/sda
>>> enabling repair mode
>>> Creating a new CRC tree
>>> Checking filesystem on /dev/sda
>>> UUID: 1de92eed-c588-4471-b853-7f6a0a22c9a6
>>> Reinit crc root
>>> extent-tree.c:2657: btrfs_reserve_extent: Assertion `ret` failed.
>>> ./btrfs[0x43c93f]
>>> ./btrfs(btrfs_reserve_extent+0xaf8)[0x441f83]
>>> ./btrfs(btrfs_alloc_free_block+0x57)[0x44202b]
>>> ./btrfs[0x435805]
>>> ./btrfs(btrfs_search_slot+0x12ce)[0x437666]
>>> ./btrfs(btrfs_csum_file_block+0x3c2)[0x4462d4]
>>> ./btrfs(cmd_check+0xf7d)[0x42564e]
>>> ./btrfs(main+0x15d)[0x4098e1]
>>> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fdb99224af5]
>>> ./btrfs[0x409499]
>>> [root@938el btrfs-progs]# ./btrfs --version
>>> Btrfs v3.18.2
>>>
>>> On Mon, Feb 16, 2015 at 3:42 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>>>> -------- Original Message --------
>>>> Subject: Re: btrfs check --init-csum-tree removes csums again
>>>> From: Chris Murphy <lists@colorremedies.com>
>>>> To: Karl-Philipp Richter <richter@richtercloud.de>
>>>> Date: 2015年02月16日 13:59
>>>>> On Sun, Feb 15, 2015 at 1:50 AM, Karl-Philipp Richter
>>>>> <richter@richtercloud.de> wrote:
>>>>>> Hi,
>>>>>> After running `btrfs check --init-csum-tree` 3.18.2 and 3.19-rc2 on a
>>>>>> btrfs all checksums are gone (thousands of line in the form of `no csum
>>>>>> found for inode X start Y` in `/var/log/kern.log`). I know that this
>>>>>> behavior (to delete all csums) was a stub in a dev version and remember
>>>>>> that it was fixed and that I even fixed a csum tree at one point. Could
>>>>>> someone please confirm and maybe even point me to a working version?
>>>>> I just tried this on CentOS 7 with kernel-3.19-0 and
>>>>> btrfs-progs-3.18.2 (from Fedora 21) and it rebuilt the csums, and took
>>>>> a little while to do it, unlike 3.12 which was very fast by just
>>>>> removing the csums. So... worksforme. However I used it with --repair,
>>>>> not by itself.
>>>>>
>>>>>
>>>> The behavior that deletes all csum tree but not to rebuilt them maybe a bug
>>>> happens when extent tree is also
>>>> corrupted or with '--init-extent-tree' in 3.18.2.
>>>>
>>>> And --init-csum-tree should imply --repair, so Chris' result should also be
>>>> OK.
>>>>
>>>> To Karl:
>>>> Would you please provide the full output of "btrfs check --init-csum-tree"
>>>> and the kernel log?
>>>> IMHO this should help to find the bug in btrfsck.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>> the body of a message to majordomo@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 majordomo@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>