I'm sometimes seeing the same backup_tree_root used more than once.
Below you'll see backup 0 and backup 2 have the same address,
different generation. The concern is if this suggests backup 2 is
actually stale and not useful?
We've previously seen that Btrfs with discard mount option can very
quickly cause the locations pointed to by backup roots to return no
data (metadata deallocated and trimmed). I wonder if this is similar
where Btrfs has no concept of delaying metadata deallocation for a
while so that the backup trees remain valid for a while (few minutes?)
Anyway if these backup roots can become stale, if they're ever needed
they're not going to be useful.
superblock: bytenr=65536, device=/dev/mapper/sdc
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0xe0c01b78 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid ecd5e90e-6fb7-4b42-ab57-515a733c01f2
metadata_uuid ecd5e90e-6fb7-4b42-ab57-515a733c01f2
label third
generation 686
root 3355115520
sys_array_size 129
chunk_root_generation 685
root_level 1
chunk_root 4325376000
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 1000207335424
bytes_used 439356653568
sectorsize 4096
nodesize 32768
leafsize (deprecated) 32768
stripesize 4096
root_dir 6
num_devices 2
compat_flags 0x0
compat_ro_flags 0x3
( FREE_SPACE_TREE |
FREE_SPACE_TREE_VALID )
incompat_flags 0x171
( MIXED_BACKREF |
COMPRESS_ZSTD |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 18446744073709551615
uuid_tree_generation 686
dev_item.uuid de7a23cd-ec25-47d4-bbdb-fcf9c4dc705a
dev_item.fsid ecd5e90e-6fb7-4b42-ab57-515a733c01f2 [match]
dev_item.type 0
dev_item.total_bytes 500103667712
dev_item.bytes_used 442415185920
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 2
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 4325376000)
length 33554432 owner 2 stripe_len 65536 type SYSTEM|RAID1
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 1
stripe 0 devid 2 offset 1083179008
dev_uuid de7a23cd-ec25-47d4-bbdb-fcf9c4dc705a
stripe 1 devid 1 offset 1104150528
dev_uuid 15e28877-dbc7-446d-9991-618504a758ca
backup_roots[4]:
backup 0:
backup_tree_root: 3355115520 gen: 686 level: 1
backup_chunk_root: 4325376000 gen: 685 level: 1
backup_extent_root: 3358523392 gen: 686 level: 2
backup_fs_root: 3550511104 gen: 497 level: 0
backup_dev_root: 3358752768 gen: 685 level: 1
backup_csum_root: 3259400192 gen: 500 level: 2
backup_total_bytes: 1000207335424
backup_bytes_used: 439356653568
backup_num_devices: 2
backup 1:
backup_tree_root: 3358752768 gen: 683 level: 1
backup_chunk_root: 4325441536 gen: 677 level: 1
backup_extent_root: 3359506432 gen: 683 level: 2
backup_fs_root: 3550511104 gen: 497 level: 0
backup_dev_root: 3358982144 gen: 677 level: 1
backup_csum_root: 3259400192 gen: 500 level: 2
backup_total_bytes: 1000207335424
backup_bytes_used: 439356653568
backup_num_devices: 2
backup 2:
backup_tree_root: 3355115520 gen: 684 level: 1
backup_chunk_root: 4325441536 gen: 677 level: 1
backup_extent_root: 3358523392 gen: 684 level: 2
backup_fs_root: 3550511104 gen: 497 level: 0
backup_dev_root: 3358982144 gen: 677 level: 1
backup_csum_root: 3259400192 gen: 500 level: 2
backup_total_bytes: 1000207335424
backup_bytes_used: 439356653568
backup_num_devices: 2
backup 3:
backup_tree_root: 3359834112 gen: 685 level: 1
backup_chunk_root: 4325376000 gen: 685 level: 1
backup_extent_root: 3361898496 gen: 685 level: 2
backup_fs_root: 3550511104 gen: 497 level: 0
backup_dev_root: 3358752768 gen: 685 level: 1
backup_csum_root: 3259400192 gen: 500 level: 2
backup_total_bytes: 1000207335424
backup_bytes_used: 439356653568
backup_num_devices: 2
--
Chris Murphy
