-------- Original Message --------
Subject: Re: btrfs check --init-csum-tree removes csums again
From: Karl-Philipp Richter <[email protected]>
To: Tim DeNike <[email protected]>, Btrfs BTRFS <[email protected]>
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 <[email protected]> wrote:
-------- Original Message --------
Subject: Re: btrfs check --init-csum-tree removes csums again
From: Chris Murphy <[email protected]>
To: Karl-Philipp Richter <[email protected]>
Date: 2015年02月16日 13:59
On Sun, Feb 15, 2015 at 1:50 AM, Karl-Philipp Richter
<[email protected]> 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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
