From: Zirconium Hacker <jared.e.vb@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS error (device sda4): failed to read chunk tree: -5
Date: Fri, 18 Aug 2017 05:08:01 -0400 [thread overview]
Message-ID: <CALsQ4_x48t6FmnswR1Bjmy9pQ9KnBpwfoihm7n55sUp6tfHOcA@mail.gmail.com> (raw)
In-Reply-To: <585f0572-cfd1-ee0d-3fc3-a7fdc4f48b0b@gmx.com>
I already ran that earlier, here's the pastebin: https://pastebin.com/KGB8nVRA
Running debug-tree on all 1084 of them (I guess that was unnecessary)
gave the same errors every time:
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
ERROR: unable to open /dev/sda4
On Fri, Aug 18, 2017 at 5:03 AM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
> On 2017年08月18日 16:47, Zirconium Hacker wrote:
>>
>> $ sudo btrfs-debug-tree -b 131072 /dev/sda4
>> btrfs-progs v4.12
>> bytenr mismatch, want=61809344512, have=0
>> Couldn't read tree root
>> ERROR: unable to open /dev/sda4
>
>
> I think this can be improved for case like this.
> I'll try to submit a patch to enhance btrfs-debug-tree.
>
> Would you please try "btrfs-find-root /dev/sda4"?
> This will try to locate on-disk old tree root, and if we're lucky, old tree
> root can allow us to mount the fs.
>
>>
>> Mounting with degraded,ro does not fix the multi-device issue. The
>> system was never really intended to have a second device, though:
>
>
> Wait for a minute, did you mean this btrfs doesn't ever have a second
> device?
> This seems quite weird now.
>
>>
>> $ sudo btrfs fi show /dev/sda4
>> bytenr mismatch, want=61809344512, have=0
>> Couldn't read tree root
>> Label: none uuid: 29889b3a-1c10-48e4-ad6d-21d03d06e90b
>> Total devices 2 FS bytes used 49.52GiB
>> devid 1 size 54.07GiB used 54.07GiB path /dev/sda4
>> *** Some devices missing
>>
>> I vaguely remember following this guide at some point:
>>
>> http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html
>> -- specifically the "Balance cannot run because the filesystem is
>> full" part. This may have broken some things?
>
>
> Not sure, at least from your superblock, too many things are in doubt.
> From the number of devices, to strange system chunk.
>
>
> Thanks,
> Qu
>>
>>
>> On Fri, Aug 18, 2017 at 4:15 AM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>
>>>
>>>
>>> On 2017年08月18日 15:17, Zirconium Hacker wrote:
>>>>
>>>>
>>>> I checked my fstab, and my mount options for that partition are:
>>>> nodev,nosuid (so no discard).
>>>> As far as I remember, I had some issues converting from ext4 with
>>>> existing tools (I think that was on Debian so the tools were likely
>>>> older) so I did a manual conversion backup, wipe, copy files back).
>>>>
>>>> $ sudo btrfs-find-root -o 3 /dev/sda4
>>>> Couldn't read tree root
>>>> Superblock thinks the generation is 311252
>>>> Superblock thinks the level is 0
>>>> ERROR: tree block bytenr 0 is not aligned to sectorsize 4096
>>>> Found tree root at 131072 gen 311252 level 0
>>>
>>>
>>>
>>> So chunk root (and since it's level 0, the whole chunk tree) seems good.
>>>
>>> Could you please try the following command?
>>> # btrfs-debug-tree -b 131072 /dev/sda4
>>>
>>> I assume it may fail due to the fact that root tree is corrupted.
>>> But maybe we are lucky?
>>>
>>>
>>> And further investigating your super dump and the code, it's shows some
>>> clue, mostly related to your multi-device setup.
>>>
>>> Your find-root output shows that, the only chunk leaf in /dev/sda4 seems
>>> good.
>>> And in btrfs_read_chunk_tree(), which returned -EIO and caused the error
>>> message, will first search chunk root.
>>>
>>> Since your chunk leaf is good, such search itself should not cause too
>>> much
>>> problem.
>>>
>>> Then btrfs_read_chunk_tree() will try to read out each device, by calling
>>> read_one_dev().
>>> Which can return -EIO if any device is missing and you're not using
>>> degraded
>>> mount option.
>>>
>>> Is your 2nd device missing? If so, would you please try to mount with
>>> "degraded,ro" mount option?
>>>
>>> BTW, if you didn't manually convert chunk profiles, did you first create
>>> btrfs on single device, and then added a new device to the btrfs?
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> On Fri, Aug 18, 2017 at 12:10 AM, Chris Murphy <lists@colorremedies.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Thu, Aug 17, 2017 at 4:42 PM, Qu Wenruo <quwenruo.btrfs@gmx.com>
>>>>> wrote:
>>>>>
>>>>>> BTW are you using discard mount option? Sometimes it can cause
>>>>>> problem.
>>>>>
>>>>>
>>>>>
>>>>> OP did not say if it was using discard mount option; but did say some
>>>>> time before this (I'm not sure how recent) he had used fstrim. The
>>>>> firmware for this SSD model is current.
>>>>>
>>>>>
>>>>> --
>>>>> Chris Murphy
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>
next prev parent reply other threads:[~2017-08-18 9:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 22:25 BTRFS error (device sda4): failed to read chunk tree: -5 Zirconium Hacker
2017-08-16 22:52 ` Chris Murphy
[not found] ` <CALsQ4_x13pBuZ0wDmO=28m6xAEXFjOkORJsxDeFASOeA5oDeLg@mail.gmail.com>
[not found] ` <CAJCQCtRTiZy2YNZNLLx_KWuLMuNxPK26u1Orz91MqtDRFNRVNg@mail.gmail.com>
[not found] ` <CALsQ4_xkiyWuwJ4mVOV7QhWx6RFD80Y23fDNdPam2UFpRi1Gxw@mail.gmail.com>
[not found] ` <CAJCQCtTx_i_PrqgRbA-P9+zKX926KKeT1nwAJT=dkr-qcOpCCg@mail.gmail.com>
[not found] ` <CALsQ4_wZLvdqHdKa9DyjRXTmf1CV47+11-O_SqLRQJoQDT+gqQ@mail.gmail.com>
[not found] ` <CAJCQCtRYxb4QdN__WcUX_Jhs=GyguwJV79pKUp4PYhC9h_H-xA@mail.gmail.com>
[not found] ` <CALsQ4_xWte-vOJD-ppOPkvfHpLtu_-24KZPj2H9Tp99S7jDGcw@mail.gmail.com>
[not found] ` <CAJCQCtR-+o_GA7fCfSe8Lfwp8h6FzfiSR=qz8ekc4=dy98mtiQ@mail.gmail.com>
[not found] ` <CALsQ4_zTdxgfN25pkbhtXfj5EMVUbZ2=FrUHUocNxjynHhYhuA@mail.gmail.com>
2017-08-17 16:53 ` Chris Murphy
2017-08-17 22:42 ` Qu Wenruo
2017-08-18 3:13 ` Zirconium Hacker
2017-08-18 3:49 ` Qu Wenruo
2017-08-22 2:28 ` Qu Wenruo
2017-08-18 4:10 ` Chris Murphy
2017-08-18 7:17 ` Zirconium Hacker
2017-08-18 8:15 ` Qu Wenruo
2017-08-18 8:47 ` Zirconium Hacker
2017-08-18 9:03 ` Qu Wenruo
2017-08-18 9:08 ` Zirconium Hacker [this message]
2017-08-18 9:19 ` Qu Wenruo
2017-08-18 9:29 ` Zirconium Hacker
2017-08-18 9:46 ` Qu Wenruo
2017-08-18 10:20 ` Zirconium Hacker
2017-08-18 11:32 ` Qu Wenruo
2017-08-18 15:00 ` Chris Murphy
2017-08-18 21:52 ` Zirconium Hacker
2017-08-18 23:21 ` Qu Wenruo
2017-08-19 2:28 ` Zirconium Hacker
2017-08-19 3:45 ` Zirconium Hacker
2017-08-17 20:51 ` Omar Sandoval
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALsQ4_x48t6FmnswR1Bjmy9pQ9KnBpwfoihm7n55sUp6tfHOcA@mail.gmail.com \
--to=jared.e.vb@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).