On 7 April 2018 at 22:09, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
>
>
> On 2018年04月07日 10:31, Ben Parsons wrote:
> [snip]
>>> Pretty common hard power reset.
>>>
>>>> looking at journalctl, there is a large stacktrace from kernel: amdgpu
>>>> (see attached).
>>>> then when I booted back up the pool (2 disks, 1TB + 2TB) wouldn't mount.
>>>
>>> I'd say such corruption is pretty serious.
>>>
>>> And what's the profile of the btrfs? If metadata is raid1, we could at
>>> least try to recovery the superblock from the remaining disk.
>>
>> I am not sure what the metadata was but the two disks had no parity
>> and just appeared as a single disk with total space of the two disks
>
> Strangely, for the 2nd disk, it's sdc1, which means it has partition table.
> While for the 1st disk, it's sda, without partition table at all.
> Is there any possibility that you just took run partition?
> (Or did some program uses it incorrectly?)
>

I dont quite understand what you are asking.
I was always under the impression I could run mount on either
partition and it would mount the pool

>>
>> how would i got about recovering the 2nd disk? attached is
>
> The 2nd disk looks good, however it's csum_type is wrong.
> 41700 looks like garbage.
>
> Despite that, incompact_flags also has garbage.
>
> The good news is, the system (and metadata) profile is RAID1, so it's
> highly possible for us to salvage (to be more accurate, rebuild) the
> superblock for the 1st device.
>
> Please dump the superblock of the 2nd device (sdc1) by the following
> command:
>
> # dd if=/dev/sdc1 of=super_dump.sdc1 bs=1 count=4096 skip=64k
>

See attached.

>
> Unfortunately, btrfs-sb-mod tool added recently doesn't have all needed
> fields, so I'm afraid I need to manually modify it.
>
> And just in case, please paste the following output to help us verify if
> it's really sda without offset:
>
> # lsblk /dev/sda
> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D"
>

dd if=/dev/sdb of=toGrep.sdb bs=1 count=128M status=progress
cat toGrep.sdb | grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D"

65600:_BHRfS_M
67108928:_BHRfS_M

>
> Above grep could be very slow since it will try to iterate the whole
> disk. It's recommended to dump the first 128M of the disk and then grep
> on that 128M image.
>
>
> BTW, with superblock of sdc1 patched, you should be able to mount the fs
> with -o ro,degraded, and salvage some data.
>
> Thanks,
> Qu

Thank you so much!

I am better off copying the data to another disk and then rebuilding the pool?
or can I just run a scrub after the super block is fixed?

For reference here is lsblk:

sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0   512M  0 part /boot
├─sda2   8:2    0 455.3G  0 part /
└─sda3   8:3    0    10G  0 part [SWAP]

sdb      8:16   0 931.5G  0 disk
-- first disk

sdc      8:32   0   1.8T  0 disk
└─sdc1   8:33   0   1.8T  0 part
-- 2nd disk

>>
>> btrfs inspect dump-super -Ffa
>>
>> for the second disk
>>
>>> And is there special mount options used here like discard?
>>
>> compress=lzo, noauto
>>
>>> Thanks,
>>> Qu
>>>
>>
>> Thank you for all your help so far.
>> Does this mean that the first disk is definatly gone? is there any way
>> to recover?
>>
>>
>> Thank,
>> Ben
>>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On 7 April 2018 at 09:44, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
>>>>>
>>>>>
>>>>> On 2018年04月07日 01:03, David Sterba wrote:
>>>>>> On Fri, Apr 06, 2018 at 11:32:34PM +1000, Ben Parsons wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just had an unexpected restart and now my btrfs pool wont mount.
>>>>>>> The error on mount is:
>>>>>>>
>>>>>>>     "ERROR: unsupported checksum algorithm 41700"
>>>>>>>
>>>>>>> and when running
>>>>>>>
>>>>>>>     btrfs inspect-internal dump-super /dev/sda
>>>>>>>     ERROR: bad magic on superblock on /dev/sda at 65536
>>>>>>>
>>>>>>> I saw a thread in the mailing list about it:
>>>>>>> https://www.spinics.net/lists/linux-btrfs/msg75326.html
>>>>>>> However I am told on IRC that Qu fixed it using magic.
>>>>>>>
>>>>>>> Any help would be much appreciated.
>>>>>>
>>>>>> In the previous report, there were 2 isolated areas of superblock
>>>>>> damaged. Please post output of
>>>>>>
>>>>>>       btrfs inspect dump-super /path
>>>>>
>>>>> And don't forget -Ffa option.
>>>>> -F to force btrfs-progs to recognize it as btrfs no matter what the magic 
>>>>> is
>>>>> -f shows all data so we could find all corruption and fix them if possible
>>>>> -a shows all backup superblocks, and if some backup is good, "btrfs
>>>>> rescue super-recovery" mentioned by Nikolay would be the best solution.
>>>>>
>>>>> Despite that, any extra info on how this happened is also appreciated,
>>>>> as similar problem happened twice, which means we need to pay attention
>>>>> on this.
>>>>>
>>>>> Thanks,
>>>>> Qu
>>>>>
>>>>> Thanks,
>>>>> Qu
>>>>>
>>>>>>
>>>>>> so we can see if it's a similar issue.
>>>>>>
>>>>>> In case it is, there's a tool in the btrfs-progs repo that can fix the
>>>>>> individual values.
>>>>>> --
>>>>>> 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
>>>>>>

Attachment: super_dump.sdc1
Description: Binary data

Reply via email to