[systemd-devel] systemd and nested Btrfs subvolumes

[Lennart Poettering]

On Sun, 22.03.15 23:15, Chris Murphy (lists at colorremedies.com) wrote:

> On Sun, Mar 22, 2015 at 10:50 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Thu, 19.03.15 19:27, Chris Murphy (lists at colorremedies.com) wrote:
> >
> >> Short version:
> >> ------------------
> >>   Instead of machinectl clone using btrfs snapshots, or even needing
> >> to store things in a var/lib/machines Btrfs subvolume, does it meet
> >> the requirements for Btrfs optimization to do this with cp -a
> >> --reflink instead?
> >
> > No. That is neither atomic nor efficient (since it requires opening
> > every single file in the tree), not particularly discoverable: I think
> > it's a good idea that users can enumerate subvolumes.
> >
> >> Why? Nested subvolumes are confusing. And nested subvolumes are
> >> excluded from snapshots. Subvolume B inside of Subvolume A, will not
> >> be snapshot or rolled back, if I snapshot Subvolume A and subsequently
> >> rollback to the snapshot of A. Is this the intended workflow?
> >
> > I am pretty sure the right answer to this problem to get recursive
> > snapshotting and subvolume deletion into place, so that the issues go
> > away.
> >
> > The right place to fix this in the kernel, but I figure in the worst
> > case this could even be emulated in userspace...
> 
> There is such a patch but there are concerns. And it looks like
> snapshot creation isn't atomic right now either. If a subvolume has
> heavy writes occurring, and is snapshot, it's uncertain what actually
> will end up in the snapshot.
> http://www.spinics.net/lists/linux-btrfs/msg29551.html

Since Chris said on the btrfs ML that he intends to add recursive
snapshot support to userspace I went forward and also added support
for recursive subvolume deletion and snapshotting to our
userspace. Should the kernel gain support for doing this natively
one day, we can easily change our code to make use of it.

Lennart

-- 
Lennart Poettering, Red Hat