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
