On 2017年08月18日 17:08, Zirconium Hacker wrote:

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

Then try using btrfs check with new root:

# btrfs check -r 1085440000 /dev/sda4

Please note that, the generation in superblock differs quite a lot with 
find-root result.
So I'm afraid it will cause quite a lot of problems.

But least, it should help btrfs check to get over "Couldn't read tree 
root" error message.

And for btrfs-debug-tree error, I'll submit a patch soon to allow it to 
be run on such heavily damaged fs.

Thanks,
Qu

On Fri, Aug 18, 2017 at 5:03 AM, Qu Wenruo [off-list ref] wrote:

quoted

On 2017年08月18日 16:47, Zirconium Hacker wrote:

quoted

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

quoted

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.

quoted

$ 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

quoted

On Fri, Aug 18, 2017 at 4:15 AM, Qu Wenruo [off-list ref] wrote:

quoted

On 2017年08月18日 15:17, Zirconium Hacker wrote:

quoted

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

quoted

On Fri, Aug 18, 2017 at 12:10 AM, Chris Murphy [off-list ref]
wrote:

quoted

On Thu, Aug 17, 2017 at 4:42 PM, Qu Wenruo [off-list ref]
wrote:

quoted

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