On 2018年04月08日 08:57, Ben Parsons wrote: > See attached for requested output. > > Do I still need to recover the super block of sdb?
Yep. Please also attach the binary dump of superblock of sdb. > > Could you please point me the right direction for doing the inplace recovery? I'll provide the patched superblock for both disks (sdb and sdc1) And with them written back to disk, just run "btrfs check" first, if nothing wrong, mount it RW and run scrub. Pretty straightforward. Thanks, Qu > > I have not rebooterd or tried to recover / mount the disc btw. > > Thanks, > Ben > > On 8 April 2018 at 10:02, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >> >> >> On 2018年04月08日 07:29, Ben Parsons wrote: >>> 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 >> >> Well, the magic number is completely correct, and at correct location. >> >> Would you please run "btrfs inspect dump-super -fFa /dev/sdb" again? >> This time it should provide good data. >> >>> >>>> >>>> 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? >> >> According to your latest grep output, strangely the 1st device is not >> that corrupted as before. >> >> So I think in-place recover should save you a lot of time. >> >> Thanks, >> Qu >> >>> >>> 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 >>> -- 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
