From: Dominik Csapak <d.csapak@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: [pbs-devel] [PATCH proxmox-backup] fix loading chunk_order from config
Date: Thu, 24 Feb 2022 08:57:40 +0100 [thread overview]
Message-ID: <20220224075740.392582-1-d.csapak@proxmox.com> (raw)
when we updated the chunk-order for a datastore, it was not reloaded
until a reload/restart of the daemon (or if the path or 'verify-new'
option was changed)
add it to the options that triggers a reload of the datastore config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
are we maybe at the point where we want to calculate a checksum of the
raw options for checking a reload trigger instead of the seperate
options? i find it slightly irritating that i have to parse the option
here twice when they have changed...
a checksum from the raw config lines(in deterministic order, e.g.
alphabetically) would include every config change, but we would not
have to maintain a list of options that trigger a change. this
could prevent someone to forget that mechanism exists (like i did)
pbs-datastore/src/datastore.rs | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/pbs-datastore/src/datastore.rs b/pbs-datastore/src/datastore.rs
index 8397da00..e01da2ba 100644
--- a/pbs-datastore/src/datastore.rs
+++ b/pbs-datastore/src/datastore.rs
@@ -76,7 +76,8 @@ impl DataStore {
if let Some(datastore) = map.get(name) {
// Compare Config - if changed, create new Datastore object!
if datastore.chunk_store.base() == path &&
- datastore.verify_new == config.verify_new.unwrap_or(false)
+ datastore.verify_new == config.verify_new.unwrap_or(false) &&
+ datastore.chunk_order == Self::parse_chunk_order(&config)?
{
return Ok(datastore.clone());
}
@@ -120,20 +121,22 @@ impl DataStore {
GarbageCollectionStatus::default()
};
- let tuning: DatastoreTuning = serde_json::from_value(
- DatastoreTuning::API_SCHEMA.parse_property_string(config.tuning.as_deref().unwrap_or(""))?
- )?;
- let chunk_order = tuning.chunk_order.unwrap_or(ChunkOrder::Inode);
-
Ok(Self {
chunk_store: Arc::new(chunk_store),
gc_mutex: Mutex::new(()),
last_gc_status: Mutex::new(gc_status),
verify_new: config.verify_new.unwrap_or(false),
- chunk_order,
+ chunk_order: Self::parse_chunk_order(&config)?,
})
}
+ fn parse_chunk_order(config: &DataStoreConfig) -> Result<ChunkOrder, Error> {
+ let tuning: DatastoreTuning = serde_json::from_value(
+ DatastoreTuning::API_SCHEMA.parse_property_string(config.tuning.as_deref().unwrap_or(""))?
+ )?;
+ Ok(tuning.chunk_order.unwrap_or(ChunkOrder::Inode))
+ }
+
pub fn get_chunk_iterator(
&self,
) -> Result<
--
2.30.2
next reply other threads:[~2022-02-24 7:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 7:57 Dominik Csapak [this message]
2022-02-24 8:55 Dietmar Maurer
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=20220224075740.392582-1-d.csapak@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/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