[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot

[Lennart Poettering]

On Wed, 01.04.15 16:02, Martin Pitt (martin.pitt at ubuntu.com) wrote:

> Lennart Poettering [2015-04-01 15:48 +0200]:
> > But why do you say "when it doesn't make sense"? Why do you think this
> > doesn't make sense...
> 
> As someone who has added hideous workarounds like
> 
> |  # old rootfs might contain btrfs subvolumes, remove them
> |  subvols=$(btrfs subvolume list -o $LXCDIR/${NAME}/rootfs.old 2>/dev/null | awk "/\/rootfs.old/ {print \$(NF)}") || true
> |  for vol in $subvols; do
> |      btrfs subvolume delete "/${vol#@}"
> |  done
> |  rm -rf $LXCDIR/${NAME}/rootfs.old
> 
> several times to a project of mine (autopkgtest), and keeps finding
> more in e. g. LXC, I must say I agree that creating subvolumes in
> things like chroots or LXC containers etc. makes very little sense to
> me too. I vaguely see how it's useful for the host's
> /var/lib/machines/, but for temporary/guest systemd instances like
> chroot or LXC it's nothing but a nuisance.

Again, this is being worked on on the btrfs side:

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42476.html

> IMHO subvolumes, like hard disk partitions, are something that the
> administrator of a host should create deliberately only. Automatically
> created ones just create confusion about "why the heck can't I remove
> that directory".. It's roughly equivalent of some random package
> messing with your partitions and/or fstab.

Well, it's a full OS container you ran there, not some arbitrary
thing.

btrfs subvolumes are going to become more common in the future, not
less common. If you put together a container manager you need to deal
with it sooner or later, and systemd is not going to be the only user
of this.

I will add recursive btrfs subvolume removal to machined, and I am
very sure LXC should do the same.

Note that I intend to add more subvolume lines to tmpfiles even. For
example, I am pretty sure /home should be created as subvolume if it
doesn't exist already, and similar.

Lennart

-- 
Lennart Poettering, Red Hat