From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net ([212.227.17.21]:59179 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754019AbdHVC2T (ORCPT ); Mon, 21 Aug 2017 22:28:19 -0400 Subject: Re: BTRFS error (device sda4): failed to read chunk tree: -5 From: Qu Wenruo To: Zirconium Hacker Cc: Chris Murphy , Btrfs BTRFS References: <38bbcea5-882b-1637-1970-e147cb141d39@gmx.com> Message-ID: <49e37b86-43d1-4238-fa3b-57b9c69f5901@gmx.com> Date: Tue, 22 Aug 2017 10:28:11 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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 >> 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 >>>> >>>> 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 >>