Re: Bad magic on superblock on /dev/sda at 65536
Fantastic! btrfs check had no error on either disk! I have now mounted the pool and am running a scrub. Thank you so much for all of your help. Thanks, Ben On 8 April 2018 at 13:05, Qu Wenruo wrote: > > > On 2018年04月08日 10:55, Ben Parsons wrote: >> just to confirm: >> >> I run the following dd command to fix the superblocks: >> dd if=super_dump.sdb of=/dev/sdb bs=1 count=4096 skip=64k >> dd if=super_dump.sdc1 of=/dev/sdc1 bs=1 count=4096 skip=64k > > Nope. > > it's seek=64K > > Thanks, > Qu >> >> Thanks, >> Ben >> >> On 8 April 2018 at 12:27, Qu Wenruo wrote: >>> Here you go, all patched super block attached. >>> >>> Thanks, >>> Qu >>> >>> On 2018年04月08日 10:14, Ben Parsons wrote: Super block of sdb as requested Thanks, Ben On 8 April 2018 at 11:53, Qu Wenruo wrote: > > > 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 wrote: >>> >>> >>> On 2018年04月08日 07:29, Ben Parsons wrote: On 7 April 2018 at 22:09, Qu Wenruo 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,
Re: Bad magic on superblock on /dev/sda at 65536
On 2018年04月08日 10:55, Ben Parsons wrote: > just to confirm: > > I run the following dd command to fix the superblocks: > dd if=super_dump.sdb of=/dev/sdb bs=1 count=4096 skip=64k > dd if=super_dump.sdc1 of=/dev/sdc1 bs=1 count=4096 skip=64k Nope. it's seek=64K Thanks, Qu > > Thanks, > Ben > > On 8 April 2018 at 12:27, Qu Wenruo wrote: >> Here you go, all patched super block attached. >> >> Thanks, >> Qu >> >> On 2018年04月08日 10:14, Ben Parsons wrote: >>> Super block of sdb as requested >>> >>> Thanks, >>> Ben >>> >>> On 8 April 2018 at 11:53, Qu Wenruo wrote: 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 wrote: >> >> >> On 2018年04月08日 07:29, Ben Parsons wrote: >>> On 7 April 2018 at 22:09, Qu Wenruo 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 shou
Re: Bad magic on superblock on /dev/sda at 65536
just to confirm: I run the following dd command to fix the superblocks: dd if=super_dump.sdb of=/dev/sdb bs=1 count=4096 skip=64k dd if=super_dump.sdc1 of=/dev/sdc1 bs=1 count=4096 skip=64k Thanks, Ben On 8 April 2018 at 12:27, Qu Wenruo wrote: > Here you go, all patched super block attached. > > Thanks, > Qu > > On 2018年04月08日 10:14, Ben Parsons wrote: >> Super block of sdb as requested >> >> Thanks, >> Ben >> >> On 8 April 2018 at 11:53, Qu Wenruo wrote: >>> >>> >>> 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 wrote: > > > On 2018年04月08日 07:29, Ben Parsons wrote: >> On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk >> ├─sda1 8:10 512M 0 part /boot >> ├─sda2 8:20 455.3G 0 part / >> └─sda3 8:3010
Re: Bad magic on superblock on /dev/sda at 65536
Here you go, all patched super block attached. Thanks, Qu On 2018年04月08日 10:14, Ben Parsons wrote: > Super block of sdb as requested > > Thanks, > Ben > > On 8 April 2018 at 11:53, Qu Wenruo wrote: >> >> >> 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 wrote: On 2018年04月08日 07:29, Ben Parsons wrote: > On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk > ├─sda1 8:10 512M 0 part /boot > ├─sda2 8:20 455.3G 0 part / > └─sda3 8:3010G 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 > super_dump.sdb Description: Binary data super_dump.sdc1 Description: Binary data
Re: Bad magic on superblock on /dev/sda at 65536
Super block of sdb as requested Thanks, Ben On 8 April 2018 at 11:53, Qu Wenruo wrote: > > > 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 wrote: >>> >>> >>> On 2018年04月08日 07:29, Ben Parsons wrote: On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk ├─sda1 8:10 512M 0 part /boot ├─sda2 8:20 455.3G 0 part / └─sda3 8:3010G 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 super_dump.sdb Description: Binary data
Re: Bad magic on superblock on /dev/sda at 65536
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 wrote: >> >> >> On 2018年04月08日 07:29, Ben Parsons wrote: >>> On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk >>> ├─sda1 8:10 512M 0 part /boot >>> ├─sda2 8:20 455.3G 0 part / >>> └─sda3 8:3010G 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
Re: Bad magic on superblock on /dev/sda at 65536
See attached for requested output. Do I still need to recover the super block of sdb? Could you please point me the right direction for doing the inplace recovery? I have not rebooterd or tried to recover / mount the disc btw. Thanks, Ben On 8 April 2018 at 10:02, Qu Wenruo wrote: > > > On 2018年04月08日 07:29, Ben Parsons wrote: >> On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk >> ├─sda1 8:10 512M 0 part /boot >> ├─sda2 8:20 455.3G 0 part / >> └─sda3 8:3010G 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 >> superblock: bytenr=65536, device=/dev/sdb - csum_type 41700 (INVALID) csum_size 32 csum 0x76e0389d [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid08e51c76-0068-45ba-bac8-9c1f57363ec6 label generation 1285351 root6485326479360 sys_array_size 129 chunk_root_generation 1273669 root_level 1 chunk_root 5518540881920 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 2979127844864 bytes_used 2924699414528 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 2 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x5b224169 ( MIXED_BACKREF |
Re: Bad magic on superblock on /dev/sda at 65536
On 2018年04月08日 07:29, Ben Parsons wrote: > On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk > ├─sda1 8:10 512M 0 part /boot > ├─sda2 8:20 455.3G 0 part / > └─sda3 8:3010G 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
Re: Bad magic on superblock on /dev/sda at 65536
On 7 April 2018 at 22:09, Qu Wenruo 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:00 465.8G 0 disk ├─sda1 8:10 512M 0 part /boot ├─sda2 8:20 455.3G 0 part / └─sda3 8:3010G 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 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. >>>>>>
Re: Bad magic on superblock on /dev/sda at 65536
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?) > > 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 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" 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 > > 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 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 >>>>> -- 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
Re: Bad magic on superblock on /dev/sda at 65536
First superblock is zero-ed and its not some random corruption, most probably someone else other than btrfs used the disk when it was unmounted? Or if the partition (if any) was changed? or if its a SAN storge hope the LUN wasn't recreated at the storage end. Thanks, Anand On 04/07/2018 08:56 AM, Qu Wenruo wrote: On 2018年04月07日 08:35, Ben Parsons wrote: btrfs inspect-internal dump-super -Ffa /path superblock: bytenr=65536, device=/dev/sda - csum_type0 (crc32c) csum_size4 csum0x [DON'T MATCH] bytenr0 flags0x0 magic [DON'T MATCH] fsid---- First super block is completely gone. label generation0 root0 sys_array_size0 chunk_root_generation0 root_level0 chunk_root0 chunk_root_level0 log_root0 log_root_transid0 log_root_level0 total_bytes0 bytes_used0 sectorsize0 nodesize0 leafsize (deprecated)0 stripesize0 root_dir0 num_devices0 compat_flags0x0 compat_ro_flags0x0 incompat_flags0x0 cache_generation0 uuid_tree_generation0 dev_item.uuid---- dev_item.fsid---- [match] dev_item.type0 dev_item.total_bytes0 dev_item.bytes_used0 dev_item.io_align0 dev_item.io_width0 dev_item.sector_size0 dev_item.devid0 dev_item.dev_group0 dev_item.seek_speed0 dev_item.bandwidth0 dev_item.generation0 sys_chunk_array[2048]: backup_roots[4]: -- 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
Re: Bad magic on superblock on /dev/sda at 65536
trying to open the program "cheese" and when I did, >> my machine hard locked and only alt+shift+sysrq+b got my screen to go >> black - and then did nothing else, so I held the power button for 3 >> seconds and then my machine rebooted. > > 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 how would i got about recovering the 2nd disk? attached is 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 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 >>>> superblock: bytenr=65536, device=/dev/sdc1 - csum_type 41700 (INVALID) csum_size 32 csum 0x3b252d3a [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid08e51c76-0068-45ba-bac8-9c1f57363ec6 label generation 1285351 root6485326479360 sys_array_size 129 chunk_root_generation 1273669 root_level 1 chunk_root 5518540881920 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 2979127844864 bytes_used 2924699414528 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 2 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x5b224169 ( MIXED_BACKREF | COMPRESS_LZO
Re: Bad magic on superblock on /dev/sda at 65536
we could at least try to recovery the superblock from the remaining disk. And is there special mount options used here like discard? Thanks, Qu > > Thanks, > Ben > > On 7 April 2018 at 09:44, Qu Wenruo 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 >>> -- 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
Re: Bad magic on superblock on /dev/sda at 65536
es:979511556 backup_bytes_used:16954280319857296 backup_num_devices:4207251235269916700 backup 2: backup_tree_root:2337992862355241844gen: 980101398level: 0 backup_chunk_root:43979460088399516gen: 4208659288774883361level: 0 backup_extent_root:18430163872154386432gen: 2464093681987837478level: 0 backup_fs_root:981019136gen: 1550706522330047level: 0 backup_dev_root:4214289213554047012gen: 18420310431198347264level: 218 backup_csum_root:2472256439130411120gen: 981084532level: 69 backup_total_bytes:13600035414614375 backup_bytes_used:4212037409428027428 backup_num_devices:1841470424815616 backup 3: backup_tree_root:980691220gen: 38077247303585464level: 230 backup_chunk_root:4218230876866361387gen: 18381783371962384384level: 156 backup_extent_root:2613838382487139074gen: 982264394 level: 58 backup_fs_root:14476045548981393gen: 4147599143226259496level: 0 backup_dev_root:17771694202552320gen: 2525173747637917895level: 186 backup_csum_root:965819255gen: 20112202281518468level: 57 backup_total_bytes:4148725034551949353 backup_bytes_used:10188439815192576 backup_num_devices:2553602728877791975 > 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. I dont know exactly what happened but here is some background: i am running Arch Linux on mainline kernel (4.16.0-1) and mesa-git (101352.498d9d0f4d-1) as I have a rx vega 64 over the past few months I have been getting hard locks when opening certain programs (usually due to a bad versions of mesa-git / llvm-git, etc). i was at the time trying to open the program "cheese" and when I did, my machine hard locked and only alt+shift+sysrq+b got my screen to go black - and then did nothing else, so I held the power button for 3 seconds and then my machine rebooted. 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. Thanks, Ben On 7 April 2018 at 09:44, Qu Wenruo 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 >> Apr 06 22:28:32 Mini-Arch kernel: R13: 000e R14: 7fff3da56788 R15: 560cd80c1b00 Apr 06 22:28:32 Mini-Arch kernel: R10: 560cd6727010 R11: 3246 R12: c0206440 Apr 06 22:28:32 Mini-Arch kernel: RBP: 7fff3da56710 R08: 560cd73a0f10 R09: 0004 Apr 06 22:28:32 Mini-Arch kernel: RDX: 7fff3da56710 RSI: c0206440 RDI: 000e Apr 06 22:28:32 Mini-Arch kernel: RAX: ffda RBX: 560cd73a0f10 RCX: 7f622a58ed87 Apr 06 22:28:32 Mini-Arch kernel: RSP: 002b:7fff3da5
Re: Bad magic on superblock on /dev/sda at 65536
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 > -- 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
Re: Bad magic on superblock on /dev/sda at 65536
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 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
Re: Bad magic on superblock on /dev/sda at 65536
On 6.04.2018 16:32, 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. Try recovering the super block from one of the backup copies via "btrfs rescue super-recover /dev/sda" > > Thanks, > Ben > -- > 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
Bad magic on superblock on /dev/sda at 65536
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.
Thanks,
Ben
--
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
