Re: BTRFS error (device sda4): failed to read chunk tree: -5

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2017年08月18日 11:49, Qu Wenruo wrote:
> 
> 
> On 2017年08月18日 11:13, Zirconium Hacker wrote:
>> I hope "Reply All" is the right option here.  Again, first time
>> interacting with a mailing list.  Google said that was what to do.
> 
> You're doing quite well, and yes, Reply All is the right option.
> 
>>
>> I have found no I/O errors in dmesg -- at least, none mentioning
>> 'I/O', 'IO', or anything triggered by mount besides BTRFS's
>> complaints.
>>
>> $ sudo btrfs rescue chunk -v /dev/sda4
>> (See https://pastebin.com/YaRHuKeT -- the output hasn't visibly
>> changed since I tried this around a week ago, but this output is
>> recent)
>> $ man btrfs | grep show-super -A1
>>         btrfs-show-super
>>             moved to btrfs inspect-internal dump-super
>> $ sudo btrfs inspect-internal dump-super -fa /dev/sda4
>> (See https://pastebin.com/DbABqXGQ)
> 
> All your superblocks are saying that chunk root locates at 131072, which 
> at least matches with your system chunk array.
> 
> But the problem is, your system chunk restored in superblock says that 
> your system chunk is located in the very beginning of your first device.
> Which is invalid as for each device, 0~1M is reserved and no chunk 
> should be allocated to that range.
> 
> Quite strange to me.
> 
> Is this image a native btrfs? Or converted from ext*?

Finally I get answer why there will be such strange chunk layout.

I reproduced it by making a btrfs with "-r" option.
Then it will create such strange chunk layout.

I'll try to fix that option, to make it follow the correct method to 
create file system.

Thanks,
Qu

> 
>> $ sudo btrfs-find-root -o 5 /dev/sda4
>> (See 
>> https://zerobin.net/?496ed00aed01ab0c#Kvp+FqrF6mfqQLZvUYJ1ODWYIzGayJbdyuMXc9RTauA= 
>>
>>     -- Pastebin wouldn't let me paste that much)
> 
> I'm sorry that my previous comment has something wrong.
> The magic number is not 5, but should be 3.
> 
> Please dump it again, and I think this time output will be much shorter.
> 
> Thanks,
> Qu
>>
>> I hope the way I'm organizing the output is OK.
>>
>> On Thu, Aug 17, 2017 at 6:42 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> 
>> wrote:
>>>
>>>
>>> On 2017年08月18日 00:53, Chris Murphy wrote:
>>>>
>>>> Readding Btrfslist, and adding Qu:
>>>>
>>>>
>>>> On Thu, Aug 17, 2017 at 12:48 AM, Zirconium Hacker 
>>>> <jared.e.vb@gmail.com>
>>>> wrote:
>>>>>
>>>>> Oh, sorry, I guess the output of the command I ran wasn't clear -- it
>>>>> was collecting the output of running the debug command on all 1,084
>>>>> and showing that it was the same.  Here's specifically what you asked
>>>>> for:
>>>>>
>>>>> $ sudo btrfs-debug-tree -b 61809344512 /dev/sda4
>>>>> btrfs-progs v4.12
>>>>> bytenr mismatch, want=61809344512, have=0
>>>>> Couldn't read tree root
>>>>> ERROR: unable to open /dev/sda4
>>>>> $ sudo btrfs-debug-tree -b 1085440000 /dev/sda4
>>>>> btrfs-progs v4.12
>>>>> bytenr mismatch, want=61809344512, have=0
>>>
>>>
>>> This means either chunk root is corrupted, or system chunk array in
>>> superblock is corrupted.
>>> Bytenr mismatch is normally impossible for normal operation.
>>>
>>> BTW are you using discard mount option? Sometimes it can cause problem.
>>>
>>> And please also paste the following output:
>>>
>>> # btrfs-show-super -fa /dev/sda4
>>> # btrfs-find-root -o 5 /dev/sda4
>>>
>>> The first is to output the full backup roots and current chunk root 
>>> for us
>>> to debug.
>>> The second one will try to iterate your whole disk to find a valid 
>>> but old
>>> chunk root.
>>> If we could find one (even a little old), it may make it possible to 
>>> mount
>>> the fs.
>>>
>>> Thanks,
>>> Qu
>>>
>>>>> Couldn't read tree root
>>>>> ERROR: unable to open /dev/sda4
>>>>>
>>>>> I'm using GMail, and it's confusing me by trimming off quotes and
>>>>> stuff, so sorry if I miss something.
>>>>>
>>>>
>>>> OK well now we're in the bad part of Btrfs repair where the error
>>>> messages don't help. > It's one thing for it to complain about
>>>> 1085440000 being invalid, because by now it might have been
>>>> overwritten, but to say it wants some other root that we already know
>>>> it can't read, and then fail reading that root is not helpful
>>>> information.
>>>> Maybe Qu has an idea. But it does sound like something really
>>>> catastrophic happened to blow away all of the backup root trees.
>>>>
>>>> Going back to your first email, -o ro,usebackuproot failed with a
>>>> chunk tree error. I wonder if 'rescue chunk' might help.
>>>>
>>>> Try 'btrfs rescue chunk -v' and see what you get.
>>>>
>>>>
>>>
>> -- 
>> 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
>>