linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [help] bad csum and magic on both superblocks
@ 2020-08-23 19:36 Tristan Plumb
  2020-08-28 20:27 ` Tristan Plumb
  0 siblings, 1 reply; 2+ messages in thread
From: Tristan Plumb @ 2020-08-23 19:36 UTC (permalink / raw)
  To: linux-btrfs

I had two nvme drives set up with raid1 metadata and rai0 data. One of
them failed, as far as I
can tell it shorted the 3.3v rail to ground, but the other is mostly
fine. However, neither of the two
superblocks have correct checksums or magic, though they appear to be
practically identical.

None of the tools that I've tried to use so far, other than
inspect-internal dump-super, have
provided an option to skip the superblock checksum and magic test, so
I get results like:

[root@ping:~]# btrfs restore -l -i /dev/nvme1n1p2
No valid Btrfs found on /dev/nvme1n1p2
Could not open root, trying backup super
ERROR: superblock checksum mismatch
No valid Btrfs found on /dev/nvme1n1p2
Could not open root, trying backup super
ERROR: superblock bytenr 274877906944 is larger than device size 190805180416
Could not open root, trying backup super

The other contents of the superblock looks fairly reasonable however.
Would people
recommend that I add an option to ignore the checksum/magic errors
(which is my inclination),
or that I repair the superblock manually somehow? Or (and my real
reason for bothering you all)
is there another option/approach that someone would suggest?

Cheers,
Tristan

[root@ping:~]# uname -a; btrfs --version
Linux ping 5.4.59 #1-NixOS SMP Wed Aug 19 06:16:29 UTC 2020 x86_64 GNU/Linux
btrfs-progs v5.7

[root@ping:~]# btrfs inspect-internal dump-super -s 0 --force /dev/nvme1n1p2
superblock: bytenr=65536, device=/dev/nvme1n1p2
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x344a5afc [DON'T MATCH]
bytenr 65536
flags 0x1
( WRITTEN )
magic ........ [DON'T MATCH]
fsid badf716b-44c3-42a5-af84-bb91fccf0f47
metadata_uuid badf716b-44c3-42a5-af84-bb91fccf0f47
label
generation 730413
root 914966282240
sys_array_size 97
chunk_root_generation 730413
root_level 1
chunk_root 912808476672
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 2171858845696
bytes_used 369171148800
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
  BIG_METADATA |
  EXTENDED_IREF |
  SKINNY_METADATA )
cache_generation 730413
uuid_tree_generation 730413
dev_item.uuid a792e7c4-88a8-4e2e-9d68-39baa50b6d0d
dev_item.fsid badf716b-44c3-42a5-af84-bb91fccf0f47 [match]
dev_item.type 0
dev_item.total_bytes 190805180416
dev_item.bytes_used 4328521728
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0

[root@ping:~]# btrfs inspect-internal dump-super -s 1 --force /dev/nvme1n1p2
superblock: bytenr=67108864, device=/dev/nvme1n1p2
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x942b7232 [DON'T MATCH]
bytenr 67108864
flags 0x1
( WRITTEN )
magic ........ [DON'T MATCH]
fsid badf716b-44c3-42a5-af84-bb91fccf0f47
metadata_uuid badf716b-44c3-42a5-af84-bb91fccf0f47
label
generation 730413
root 914966282240
sys_array_size 97
chunk_root_generation 730413
root_level 1
chunk_root 912808476672
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 2171858845696
bytes_used 369171148800
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
  BIG_METADATA |
  EXTENDED_IREF |
  SKINNY_METADATA )
cache_generation 730413
uuid_tree_generation 730413
dev_item.uuid a792e7c4-88a8-4e2e-9d68-39baa50b6d0d
dev_item.fsid badf716b-44c3-42a5-af84-bb91fccf0f47 [match]
dev_item.type 0
dev_item.total_bytes 190805180416
dev_item.bytes_used 4328521728
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [help] bad csum and magic on both superblocks
  2020-08-23 19:36 [help] bad csum and magic on both superblocks Tristan Plumb
@ 2020-08-28 20:27 ` Tristan Plumb
  0 siblings, 0 replies; 2+ messages in thread
From: Tristan Plumb @ 2020-08-28 20:27 UTC (permalink / raw)
  To: linux-btrfs

In case someone comes across this having seen something similar. This
is what it looks like when you have removed a disk from a multi-disk
btrfs. I've recovered my old drive enough to get the data off and
found that it wasn't using the old drive anymore.

Cheers,
Tristan

On Sun, Aug 23, 2020 at 3:36 PM Tristan Plumb <wild.rugosa@gmail.com> wrote:
>
> I had two nvme drives set up with raid1 metadata and rai0 data. One of
> them failed, as far as I
> can tell it shorted the 3.3v rail to ground, but the other is mostly
> fine. However, neither of the two
> superblocks have correct checksums or magic, though they appear to be
> practically identical.
>
> None of the tools that I've tried to use so far, other than
> inspect-internal dump-super, have
> provided an option to skip the superblock checksum and magic test, so
> I get results like:
>
> [root@ping:~]# btrfs restore -l -i /dev/nvme1n1p2
> No valid Btrfs found on /dev/nvme1n1p2
> Could not open root, trying backup super
> ERROR: superblock checksum mismatch
> No valid Btrfs found on /dev/nvme1n1p2
> Could not open root, trying backup super
> ERROR: superblock bytenr 274877906944 is larger than device size 190805180416
> Could not open root, trying backup super
>
> The other contents of the superblock looks fairly reasonable however.
> Would people
> recommend that I add an option to ignore the checksum/magic errors
> (which is my inclination),
> or that I repair the superblock manually somehow? Or (and my real
> reason for bothering you all)
> is there another option/approach that someone would suggest?
>
> Cheers,
> Tristan
>
> [root@ping:~]# uname -a; btrfs --version
> Linux ping 5.4.59 #1-NixOS SMP Wed Aug 19 06:16:29 UTC 2020 x86_64 GNU/Linux
> btrfs-progs v5.7
>
> [root@ping:~]# btrfs inspect-internal dump-super -s 0 --force /dev/nvme1n1p2
> superblock: bytenr=65536, device=/dev/nvme1n1p2
> ---------------------------------------------------------
> csum_type 0 (crc32c)
> csum_size 4
> csum 0x344a5afc [DON'T MATCH]
> bytenr 65536
> flags 0x1
> ( WRITTEN )
> magic ........ [DON'T MATCH]
> fsid badf716b-44c3-42a5-af84-bb91fccf0f47
> metadata_uuid badf716b-44c3-42a5-af84-bb91fccf0f47
> label
> generation 730413
> root 914966282240
> sys_array_size 97
> chunk_root_generation 730413
> root_level 1
> chunk_root 912808476672
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 2171858845696
> bytes_used 369171148800
> sectorsize 4096
> nodesize 16384
> leafsize (deprecated) 16384
> stripesize 4096
> root_dir 6
> num_devices 2
> compat_flags 0x0
> compat_ro_flags 0x0
> incompat_flags 0x161
> ( MIXED_BACKREF |
>   BIG_METADATA |
>   EXTENDED_IREF |
>   SKINNY_METADATA )
> cache_generation 730413
> uuid_tree_generation 730413
> dev_item.uuid a792e7c4-88a8-4e2e-9d68-39baa50b6d0d
> dev_item.fsid badf716b-44c3-42a5-af84-bb91fccf0f47 [match]
> dev_item.type 0
> dev_item.total_bytes 190805180416
> dev_item.bytes_used 4328521728
> dev_item.io_align 4096
> dev_item.io_width 4096
> dev_item.sector_size 4096
> dev_item.devid 1
> dev_item.dev_group 0
> dev_item.seek_speed 0
> dev_item.bandwidth 0
> dev_item.generation 0
>
> [root@ping:~]# btrfs inspect-internal dump-super -s 1 --force /dev/nvme1n1p2
> superblock: bytenr=67108864, device=/dev/nvme1n1p2
> ---------------------------------------------------------
> csum_type 0 (crc32c)
> csum_size 4
> csum 0x942b7232 [DON'T MATCH]
> bytenr 67108864
> flags 0x1
> ( WRITTEN )
> magic ........ [DON'T MATCH]
> fsid badf716b-44c3-42a5-af84-bb91fccf0f47
> metadata_uuid badf716b-44c3-42a5-af84-bb91fccf0f47
> label
> generation 730413
> root 914966282240
> sys_array_size 97
> chunk_root_generation 730413
> root_level 1
> chunk_root 912808476672
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 2171858845696
> bytes_used 369171148800
> sectorsize 4096
> nodesize 16384
> leafsize (deprecated) 16384
> stripesize 4096
> root_dir 6
> num_devices 2
> compat_flags 0x0
> compat_ro_flags 0x0
> incompat_flags 0x161
> ( MIXED_BACKREF |
>   BIG_METADATA |
>   EXTENDED_IREF |
>   SKINNY_METADATA )
> cache_generation 730413
> uuid_tree_generation 730413
> dev_item.uuid a792e7c4-88a8-4e2e-9d68-39baa50b6d0d
> dev_item.fsid badf716b-44c3-42a5-af84-bb91fccf0f47 [match]
> dev_item.type 0
> dev_item.total_bytes 190805180416
> dev_item.bytes_used 4328521728
> dev_item.io_align 4096
> dev_item.io_width 4096
> dev_item.sector_size 4096
> dev_item.devid 1
> dev_item.dev_group 0
> dev_item.seek_speed 0
> dev_item.bandwidth 0
> dev_item.generation 0

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-08-28 20:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-23 19:36 [help] bad csum and magic on both superblocks Tristan Plumb
2020-08-28 20:27 ` Tristan Plumb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).