"Replacing" a subvolume in presence of nested subvolumes

"Replacing" a subvolume in presence of nested subvolumes

[intelfx]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

Hi,

I'm currently developing a sort of high-level management CLI for btrfs
(loosely modeled after zfs CLI) and I believe I've hit a pretty crucial
missing feature in btrfs.

Given a subvolume tree like this:

FS_ROOT
├── foo
│   ├── baz
│   │   ├── foosub1
│   │   └── foosub2
│   └── foosub3
└── bar

Does there exist a way to atomically replace (or exchange) `foo` with
`bar`, preserving the nested subvolumes at their logical places (i.e.
beneath the new `foo`?

I'm pretty sure the answer right now is "no", but what I'm wondering
is: what would it take to implement something like it in btrfs? Or can
it be emulated with a clever sequence of VFS operations?

I tried to mess around with bind mounts to "emulate" this
functionality, but I don't see a way around it — if a directory is a
mountpoint, there is very little you can do with it.

This feature (or, rather, its absence) is in the way of implementing a
sort of "rollback" feature (in the hierarchy above, imagine that `bar`
is a snapshot of `foo` that the user wants to restore).

Now of course it is possible to take an easy way out by saying that
nested subvolumes are broken, but I don't think that would fly: nested,
user-creatable subvolumes are a very useful concept, docker/podman
creates them when used with a corresponding driver, etc. While for
system-wide docker/podman you can get around this by creating a top-
level `/docker` or `/podman` subvolume and mounting it into `/var/lib`,
this won't work for rootless podman.

Thoughts? Ideas?

-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

Re: "Replacing" a subvolume in presence of nested subvolumes

[Goffredo Baroncelli]

On 10/07/2024 06.35, intelfx@intelfx.name wrote:
> Hi,
>
> I'm currently developing a sort of high-level management CLI for btrfs
> (loosely modeled after zfs CLI) and I believe I've hit a pretty crucial
> missing feature in btrfs.
>
> Given a subvolume tree like this:
>
> FS_ROOT
> ├── foo
> │   ├── baz
> │   │   ├── foosub1
> │   │   └── foosub2
> │   └── foosub3
> └── bar
>
> Does there exist a way to atomically replace (or exchange) `foo` with
> `bar`, preserving the nested subvolumes at their logical places (i.e.
> beneath the new `foo`?


There are two basic models: a tree of subvolumes, and a flat lists of subvolumes that then have to be mounting using mount --bind.

The latter requires a lot of userspace activity to mount a FS, but it is more flexible. It allows you to swap a portion of a subvolumes hierarcy umounting a aubvolume and remounting the subvolumes in a different sequence

Regarding the word "atomically", this is a bigger constraint: assuming that you are able to swap subvolumes, what about a file opened in the "old" subvolume that doesn't exists in the new one ?

For now the best thing that I was able to find is to perform a reboot between the swaps of the subvolumes


>
> I'm pretty sure the answer right now is "no", but what I'm wondering
> is: what would it take to implement something like it in btrfs? Or can
> it be emulated with a clever sequence of VFS operations?
>
> I tried to mess around with bind mounts to "emulate" this
> functionality, but I don't see a way around it — if a directory is a
> mountpoint, there is very little you can do with it.
>
> This feature (or, rather, its absence) is in the way of implementing a
> sort of "rollback" feature (in the hierarchy above, imagine that `bar`
> is a snapshot of `foo` that the user wants to restore).
>
> Now of course it is possible to take an easy way out by saying that
> nested subvolumes are broken, but I don't think that would fly: nested,
> user-creatable subvolumes are a very useful concept, docker/podman
> creates them when used with a corresponding driver, etc. While for
> system-wide docker/podman you can get around this by creating a top-
> level `/docker` or `/podman` subvolume and mounting it into `/var/lib`,
> this won't work for rootless podman.
>
> Thoughts? Ideas?
>

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5