From: Chris Murphy <lists@colorremedies.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: life time of backup roots
Date: Tue, 2 Apr 2019 21:58:21 -0600 [thread overview]
Message-ID: <CAJCQCtTwrBS-ZCm=MWStBdfm4iRgMiCt9vnC-WZHYNr9m1dO_Q@mail.gmail.com> (raw)
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
next reply other threads:[~2019-04-03 3:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 3:58 Chris Murphy [this message]
2019-04-03 7:05 ` life time of backup roots Qu Wenruo
2019-04-03 8:04 ` Nikolay Borisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJCQCtTwrBS-ZCm=MWStBdfm4iRgMiCt9vnC-WZHYNr9m1dO_Q@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).