From: Christian Ebner <c.ebner@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: Re: [pbs-devel] [PATCH proxmox-backup v8 3/4] fix #3935: datastore: move manifest locking to new locking method
Date: Tue, 25 Mar 2025 10:44:51 +0100 [thread overview]
Message-ID: <159d6640-1ce7-4466-8466-be20fd6359dc@proxmox.com> (raw)
In-Reply-To: <20250324125157.165976-4-s.sterz@proxmox.com>
On 3/24/25 13:51, Shannon Sterz wrote:
> adds double stat'ing and removes directory hierarchy to bring manifest
> locking in-line with other locks used by the BackupDir trait.
>
> if the old locking mechanism is still supposed to be used, this still
> falls back to the previous lock file. however, we already add double
> stat'ing since it is trivial to do here and should only provide better
> safety when it comes to removing locks.
>
> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
> ---
> pbs-datastore/src/backup_info.rs | 45 ++++++++++++++++++++------------
> 1 file changed, 29 insertions(+), 16 deletions(-)
>
> diff --git a/pbs-datastore/src/backup_info.rs b/pbs-datastore/src/backup_info.rs
> index b79e8196..0602867a 100644
> --- a/pbs-datastore/src/backup_info.rs
> +++ b/pbs-datastore/src/backup_info.rs
> @@ -469,25 +469,41 @@ impl BackupDir {
> /// Returns the filename to lock a manifest
> ///
> /// Also creates the basedir. The lockfile is located in
> - /// '/run/proxmox-backup/locks/{datastore}/[ns/{ns}/]+{type}/{id}/{timestamp}.index.json.lck'
> - fn manifest_lock_path(&self) -> Result<PathBuf, Error> {
> - let mut path = PathBuf::from(&format!("/run/proxmox-backup/locks/{}", self.store.name()));
> - path.push(self.relative_path());
> + /// `${DATASTORE_LOCKS_DIR}/${datastore name}/${lock_file_path_helper(rpath)}.index.json.lck`
> + /// where rpath is the relative path of the snapshot.
> + fn manifest_lock_path(&self) -> PathBuf {
> + let path = Path::new(DATASTORE_LOCKS_DIR).join(self.store.name());
>
> - std::fs::create_dir_all(&path)?;
> - let ts = self.backup_time_string();
> - path.push(format!("{ts}{MANIFEST_LOCK_NAME}"));
> + let rpath = Path::new(self.dir.group.ty.as_str())
> + .join(&self.dir.group.id)
> + .join(&self.backup_time_string)
> + .join(MANIFEST_LOCK_NAME);
>
> - Ok(path)
> + path.join(lock_file_path_helper(&self.ns, rpath))
> }
>
> /// Locks the manifest of a snapshot, for example, to update or delete it.
> pub(crate) fn lock_manifest(&self) -> Result<BackupLockGuard, Error> {
> - let path = self.manifest_lock_path()?;
> + let path = if *OLD_LOCKING {
> + // old manifest lock path
> + let path = Path::new(DATASTORE_LOCKS_DIR)
> + .join(self.store.name())
> + .join(self.relative_path());
>
> - // actions locking the manifest should be relatively short, only wait a few seconds
> - open_backup_lockfile(&path, Some(std::time::Duration::from_secs(5)), true)
> - .map_err(|err| format_err!("unable to acquire manifest lock {:?} - {}", &path, err))
> + std::fs::create_dir_all(&path)?;
> +
> + path.join(format!("{}{MANIFEST_LOCK_NAME}", self.backup_time_string()))
> + } else {
> + self.manifest_lock_path()
> + };
> +
> + lock_helper(self.store.name(), &path, |p| {
> + // update_manifest should never take a long time, so if
> + // someone else has the lock we can simply block a bit
> + // and should get it soon
> + open_backup_lockfile(p, Some(Duration::from_secs(5)), true)
> + .map_err(|err| format_err!("unable to acquire manifest lock {p:?} - {err}"))
nit: same as other patch. Should this use anyhow error context instead
of map_err?
> + })
> }
>
> /// Returns a file name for locking a snapshot.
> @@ -563,10 +579,7 @@ impl BackupDir {
> })?;
>
> // remove no longer needed lock files
> - if let Ok(path) = self.manifest_lock_path() {
> - let _ = std::fs::remove_file(path); // ignore errors
> - }
> -
> + let _ = std::fs::remove_file(self.manifest_lock_path()); // ignore errors
> let _ = std::fs::remove_file(self.lock_path()); // ignore errors
>
> Ok(())
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2025-03-25 9:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 12:51 [pbs-devel] [PATCH proxmox-backup v8 0/4] refactor datastore locking to use tmpfs Shannon Sterz
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 1/4] datastore/api/backup: prepare for fix of #3935 by adding lock helpers Shannon Sterz
2025-03-25 9:35 ` Christian Ebner
2025-03-25 9:57 ` Shannon Sterz
2025-03-25 10:12 ` Christian Ebner
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 2/4] fix #3935: datastore/api/backup: move datastore locking to '/run' Shannon Sterz
2025-03-25 9:43 ` Christian Ebner
2025-03-25 9:48 ` Christian Ebner
2025-03-25 11:25 ` Wolfgang Bumiller
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 3/4] fix #3935: datastore: move manifest locking to new locking method Shannon Sterz
2025-03-25 9:44 ` Christian Ebner [this message]
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 4/4] fix: api: avoid race condition in set_backup_owner Shannon Sterz
2025-03-25 10:00 ` Christian Ebner
2025-03-25 10:13 ` Shannon Sterz
2025-03-25 10:18 ` Christian Ebner
2025-03-25 11:26 ` [pbs-devel] [PATCH proxmox-backup v8 0/4] refactor datastore locking to use tmpfs Wolfgang Bumiller
2025-03-25 11:33 ` Shannon Sterz
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=159d6640-1ce7-4466-8466-be20fd6359dc@proxmox.com \
--to=c.ebner@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal