* life time of backup roots
@ 2019-04-03 3:58 Chris Murphy
2019-04-03 7:05 ` Qu Wenruo
0 siblings, 1 reply; 3+ messages in thread
From: Chris Murphy @ 2019-04-03 3:58 UTC (permalink / raw)
To: Btrfs BTRFS
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: life time of backup roots
2019-04-03 3:58 life time of backup roots Chris Murphy
@ 2019-04-03 7:05 ` Qu Wenruo
2019-04-03 8:04 ` Nikolay Borisov
0 siblings, 1 reply; 3+ messages in thread
From: Qu Wenruo @ 2019-04-03 7:05 UTC (permalink / raw)
To: Chris Murphy, Btrfs BTRFS
[-- Attachment #1.1: Type: text/plain, Size: 5683 bytes --]
On 2019/4/3 上午11:58, Chris Murphy wrote:
> 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?
Currently, backup root of btrfs only has a life time of one generation.
That's to say, any backup older than current generation - 1 is already
stale.
Filipe had tried to make btrfs to pin down extents up to 4 generations.
Thus btrfs could make all 4 backup roots valid, but that leaded to a lot
of ENOSPC. So he gave up that idea.
Thanks,
Qu
>
> 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
>
>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: life time of backup roots
2019-04-03 7:05 ` Qu Wenruo
@ 2019-04-03 8:04 ` Nikolay Borisov
0 siblings, 0 replies; 3+ messages in thread
From: Nikolay Borisov @ 2019-04-03 8:04 UTC (permalink / raw)
To: Qu Wenruo, Chris Murphy, Btrfs BTRFS
On 3.04.19 г. 10:05 ч., Qu Wenruo wrote:
>
>
> On 2019/4/3 上午11:58, Chris Murphy wrote:
>> 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?
>
> Currently, backup root of btrfs only has a life time of one generation.
>
> That's to say, any backup older than current generation - 1 is already
> stale.
Yeah, backup roots should really be perceived as a "best-effort" type of
mechanism rather than something guaranteeing you can go back 4
generations w.r.t fs state.
>
> Filipe had tried to make btrfs to pin down extents up to 4 generations.
> Thus btrfs could make all 4 backup roots valid, but that leaded to a lot
> of ENOSPC. So he gave up that idea.
>
> Thanks,
> Qu
>
>>
>> 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
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-04-03 8:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-03 3:58 life time of backup roots Chris Murphy
2019-04-03 7:05 ` Qu Wenruo
2019-04-03 8:04 ` Nikolay Borisov
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).