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 <quwenruo.bt...@gmx.com>
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
<jared.e...@gmail.com>
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 majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
