Re: [PATCH proxmox-backup v5 4/9] datastore: add move_namespace

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On March 19, 2026 5:13 pm, Hannes Laimer wrote:
> move_namespace relocates an entire namespace subtree (the given
> namespace, all child namespaces, and their groups) to a new location
> within the same datastore.
> 
> For the filesystem backend the entire subtree is relocated with a single
> atomic rename. For the S3 backend groups are moved one at a time via
> BackupGroup::move_to(). Groups that fail are left at the source and
> listed as an error in the task log so they can be retried with
> move_group individually. Source namespaces where all groups succeeded
> have their S3 markers and local cache directories removed,
> deepest-first.
> 
> Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
> ---
>  pbs-datastore/src/datastore.rs | 249 ++++++++++++++++++++++++++++++++-
>  1 file changed, 248 insertions(+), 1 deletion(-)
> 
> diff --git a/pbs-datastore/src/datastore.rs b/pbs-datastore/src/datastore.rs
> index d4c88452..3187cbc3 100644
> --- a/pbs-datastore/src/datastore.rs
> +++ b/pbs-datastore/src/datastore.rs
> @@ -31,7 +31,7 @@ use pbs_api_types::{
>      ArchiveType, Authid, BackupGroupDeleteStats, BackupNamespace, BackupType, ChunkOrder,
>      DataStoreConfig, DatastoreBackendConfig, DatastoreBackendType, DatastoreFSyncLevel,
>      DatastoreTuning, GarbageCollectionCacheStats, GarbageCollectionStatus, MaintenanceMode,
> -    MaintenanceType, Operation, UPID,
> +    MaintenanceType, Operation, MAX_NAMESPACE_DEPTH, UPID,
>  };
>  use pbs_config::s3::S3_CFG_TYPE_ID;
>  use pbs_config::{BackupLockGuard, ConfigVersionCache};
> @@ -1003,6 +1003,253 @@ impl DataStore {
>          Ok((removed_all_requested, stats))
>      }
>  
> +    /// Move a backup namespace (including all child namespaces and groups) to a new location.
> +    ///
> +    /// The entire subtree rooted at `source_ns` is relocated to `target_ns`. Exclusive namespace
> +    /// locks are held on both source and target namespaces for the duration to block concurrent
> +    /// readers and writers.
> +    ///
> +    /// For the filesystem backend the rename is atomic. For the S3 backend groups are moved
> +    /// one at a time. A group that fails to copy is left at the source and can be moved
> +    /// individually with `move_group`. The operation returns an error listing any such groups.

I think we want these semantics in both cases, since a move is only
atomic if you ignore a lot of the invariants you need to violate to make
it so, even in the filesystem case. and if we have such semantics, and
handle the invariants correctly, we only need the namespace locks if we
basically want to make the namespace lock a "per-NS-maintenance-mode" in
disguise.. which I don't think is what users actually want - they want
an option to bulk move groups from A to B without interrupting the
world..

I hope my comments on the other patches make it clear what I mean - I am
open for arguments for the current approach with namespace locks, but at
the moment I am not yet convinced this is the better approach..

skipping the rest of the implementation below (for now)

> +    ///
> +    /// Fails if:
> +    /// - `source_ns` is the root namespace
> +    /// - `source_ns` == `target_ns`
> +    /// - `source_ns` does not exist
> +    /// - `target_ns` already exists (to prevent silent merging)
> +    /// - `target_ns`'s parent does not exist
> +    /// - `source_ns` is an ancestor of `target_ns`
> +    /// - the move would exceed the maximum namespace depth
> +    pub fn move_namespace(

other than noting that this particular fn is *very* long ;)

> [..]