From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:18732 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752258AbbBQFTN convert rfc822-to-8bit (ORCPT ); Tue, 17 Feb 2015 00:19:13 -0500 Message-ID: <54E2CF4D.10008@cn.fujitsu.com> Date: Tue, 17 Feb 2015 13:19:09 +0800 From: Qu Wenruo MIME-Version: 1.0 To: Karl-Philipp Richter , Tim DeNike , Btrfs BTRFS Subject: Re: btrfs check --init-csum-tree removes csums again References: <54E05DCD.3050508@richtercloud.de> <54E1AD61.7010007@cn.fujitsu.com> <54E1D25C.4090900@richtercloud.de> <54E2C0FC.8030300@richtercloud.de> In-Reply-To: <54E2C0FC.8030300@richtercloud.de> Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: -------- Original Message -------- Subject: Re: btrfs check --init-csum-tree removes csums again From: Karl-Philipp Richter To: Tim DeNike , Btrfs BTRFS 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 wrote: >>>> -------- Original Message -------- >>>> Subject: Re: btrfs check --init-csum-tree removes csums again >>>> From: Chris Murphy >>>> To: Karl-Philipp Richter >>>> Date: 2015年02月16日 13:59 >>>>> On Sun, Feb 15, 2015 at 1:50 AM, Karl-Philipp Richter >>>>> 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 >>