# ./btrfs-debug-tree -b 131072 /dev/sda4
https://pastebin.com/TDa0GuqB
# ./btrfs-debug-tree -b 61809344512 /dev/sda4
btrfs-progs v4.12-dirty
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
bytenr mismatch, want=61809344512, have=0
ERROR: failed to read 61809344512
# ./btrfs-debug-tree -b 61807755264 /dev/sda4
btrfs-progs v4.12-dirty
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
bytenr mismatch, want=61807755264, have=0
ERROR: failed to read 61807755264

And that last one you wanted me to run debug-tree on was a duplicate.

Bonus:
# ./btrfs-debug-tree -b 1085440000 /dev/sda4
btrfs-progs v4.12-dirty
bytenr mismatch, want=61809344512, have=0
Couldn't read tree root
node 1085440000 level 1 items 2 free 491 generation 325709 owner 1
fs uuid 29889b3a-1c10-48e4-ad6d-21d03d06e90b
chunk uuid 33f664ec-d0bc-42f9-87f1-d2c0bbbb5046
key (EXTENT_TREE ROOT_ITEM 0) block 1085456384 (66251) gen 325709
key (286 INODE_ITEM 0) block 1085505536 (66254) gen 325709

BTW, thank you for your quick responses and help so far.

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

Would you please try this patch?
https://patchwork.kernel.org/patch/9908173/

This should allow btrfs-debug-tree to output tree block even tree root is
corrupted.
You could apply it on lasted master branch (tagged as v4.12).

Then re-execute the following command (with patched btrfs-progs):
# btrfs-debug-tree -b 131072 /dev/sda4

And some new output:
# btrfs-debug-tree -b 61809344512 /dev/sda4
# btrfs-debug-tree -b 61807755264 /dev/sda4
# btrfs-debug-tree -b 61809344512 /dev/sda4

Thanks,
Qu


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

quoted

$ sudo btrfs check -r 1085440000 /dev/sda4
parent transid verify failed on 1085440000 wanted 325966 found 325709
parent transid verify failed on 1085440000 wanted 325966 found 325709
Ignoring transid failure
bytenr mismatch, want=61352312832, have=0
Couldn't setup device tree
ERROR: cannot open file system

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

quoted

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

quoted

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

quoted

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

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