On 7 April 2018 at 22:09, Qu Wenruo <quwenruo.btrfs@xxxxxxx> 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.btrfs@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>>
Attachment:
super_dump.sdc1
Description: Binary data
