OK so from the 1MiB of md member number 2 that survived being wiped;
I've got this Btrfs superblock at offset 192KiB, and it decodes as:
superblock: bytenr=65536, device=/dev/mapper/vg-synology
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x21b26c4d [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid f4bc4bd1-af0d-4d54-9b05-6a719ddec086
label 2017.05.25-01:26:55 v15101
generation 1599066
root 7836911304704
sys_array_size 129
chunk_root_generation 1595847
root_level 1
chunk_root 20971520
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 11987484409856
bytes_used 7841685688320
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x8000000000000000
compat_ro_flags 0x0
incompat_flags 0x16b
( MIXED_BACKREF |
DEFAULT_SUBVOL |
COMPRESS_LZO |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 9
uuid_tree_generation 1599066
dev_item.uuid e40c544c-3d7d-4e01-93af-a5b70985d4f1
dev_item.fsid f4bc4bd1-af0d-4d54-9b05-6a719ddec086 [match]
dev_item.type 0
dev_item.total_bytes 11987484409856
dev_item.bytes_used 8161528381440
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
sys_chunk_array[2048]:
item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 0
stripe 0 devid 1 offset 20971520
dev_uuid e40c544c-3d7d-4e01-93af-a5b70985d4f1
stripe 1 devid 1 offset 29360128
dev_uuid e40c544c-3d7d-4e01-93af-a5b70985d4f1
backup_roots[4]:
backup 0:
backup_tree_root: 7836911124480 gen: 1599065 level: 1
backup_chunk_root: 20971520 gen: 1595847 level: 1
backup_extent_root: 7836910977024 gen: 1599065 level: 2
backup_fs_root: 29573120 gen: 7 level: 0
backup_dev_root: 7836738093056 gen: 1598949 level: 1
backup_csum_root: 7836910911488 gen: 1599065 level: 3
backup_total_bytes: 11987484409856
backup_bytes_used: 7841685688320
backup_num_devices: 1
backup 1:
backup_tree_root: 7836911304704 gen: 1599066 level: 1
backup_chunk_root: 20971520 gen: 1595847 level: 1
backup_extent_root: 7836911321088 gen: 1599066 level: 2
backup_fs_root: 29573120 gen: 7 level: 0
backup_dev_root: 7836738093056 gen: 1598949 level: 1
backup_csum_root: 7836910911488 gen: 1599065 level: 3
backup_total_bytes: 11987484409856
backup_bytes_used: 7841685688320
backup_num_devices: 1
backup 2:
backup_tree_root: 7836907847680 gen: 1599063 level: 1
backup_chunk_root: 20971520 gen: 1595847 level: 1
backup_extent_root: 7836907667456 gen: 1599063 level: 2
backup_fs_root: 29573120 gen: 7 level: 0
backup_dev_root: 7836738093056 gen: 1598949 level: 1
backup_csum_root: 7836908044288 gen: 1599064 level: 3
backup_total_bytes: 11987484409856
backup_bytes_used: 7841685733376
backup_num_devices: 1
backup 3:
backup_tree_root: 7836910469120 gen: 1599064 level: 1
backup_chunk_root: 20971520 gen: 1595847 level: 1
backup_extent_root: 7836909551616 gen: 1599064 level: 2
backup_fs_root: 29573120 gen: 7 level: 0
backup_dev_root: 7836738093056 gen: 1598949 level: 1
backup_csum_root: 7836908044288 gen: 1599064 level: 3
backup_total_bytes: 11987484409856
backup_bytes_used: 7841685704704
backup_num_devices: 1
The section I'm interested in is the sys_chunk_array. There is one
system chunk, and the profile is DUP, so two copies, one at 20MiB and
the other 28MiB offset. So the system chunk is outside the erased
area.
John, can you check the 10T drive backup of /dev/md3? I think it's
/dev/sdd1 so if that's still the case I'm curious if there's really
still only zeros in that first megabyte.
$ sudo dd if=/dev/sdd1 count=2048 2>/dev/null | hexdump -C
And then pastebin that somewhere with maybe a 7 day expiration. I
wonder if it's really zero, and if not it might actually be valid and
we wanna make sure that it's not stepped on when repairing LVM
metadata.
---
Chris Murphy
