Re: Chunk-Recovery fails with alignment error

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Benjamin Beichler <hadrian2002@googlemail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Chunk-Recovery fails with alignment error
Date: Wed, 6 Dec 2017 08:42:59 +0800	[thread overview]
Message-ID: <211ded6e-5b02-0c33-b75e-b0ad6ff30ca4@gmx.com> (raw)
In-Reply-To: <CABi++uJj6x=ZT1QbB7vu5Zh3_Mf6nsLNMAO9QXNLEBQN_ngoYA@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2852 bytes --]

On 2017年12月06日 03:22, Benjamin Beichler wrote:
> Hi,
> 
> I have a setup as following:  (1,7TB drive + 128GB SSD in Bcache) <==>
> luks device <==> btrfs FS
> I have been running Arch linux with newest stable kernel 4.14.
> 
> After a reboot last week my btrfs volume becomes unmountable, because
> of checksum errors in the chunk root.
> 
> These are the outputs of check:
> "btrfs check /dev/mapper/root
> 
> checksum verify failed on 131072 found 1A98EC4A wanted B97166DB
> checksum verify failed on 131072 found 1A98EC4A wanted B97166DB
> bytenr mismatch, want=131072, have=9229526874648754029
> ERROR: cannot read chunk root
> ERROR: cannot open file system

That's the most serious problem for btrfs.
No chunk tree nothing can be recovered.

> "
> 
> Most other check/repair commands fail with the same error. The
> super-dump can be found here:
> https://gist.github.com/anonymous/33bd22696c37355c6cfd093f4c6bd226

Better with -fa option to show system chunk array and backup roots.

> 
>  After my attempts in initramfs failed I used a recent arch-live disk
> to compile newest btrfs-tools and use recent kernel (4.9) to recover
> the chunk tree.
> 
> Therefore I ran the chunk recover command on my drive.  It looks like
> the following here>
> https://gist.github.com/anonymous/5359c08734cf81ad3887b635536d9631
> 
> for better debugging I already used gdb to inspect the following error:
> 
> "ERROR: tree block bytenr 0 is not aligned to sectorsize 4096"
> 
> but as the exception raise is far to late to inspect the problem.
> Since most of my chunks seems to be recoverable, I hope a tree rebuild
> is possible, but I don't know how.

This seems to be related to __rebuikld_device_items(), where
btrfs_insert_item() return -EIO and triggered BUG_ON().

Despite the heavy (and mostly overkilled) method, we can do a lighter
version by checking every possible tree root in system chunk array.

Which needs the -fa option of super-dump subcommand.

The basic idea is:
1) Check the back_roots of output
   If backup_chunk_root of all backup roots are the same with chunk_root
   (which is 131072 in your case), skip to step 3)

2) Try all backup_chunk_root numbers with "btrfs check --chunk-root
   <bytenr>"
   If some number returns good result (no obvious problem reported),
   then with --repair option, finish the repair.
   If all fails, go step 3)

3) Try all bytenr aligned to 16K in system chunk
   Same "btrfs check --chunk-root <bytenr>" until one returns good
   result. Then --repair.

Thanks,
Qu
> 
> Do you have any suggestions?
> --
> 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
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]