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

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

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
>>>
>>