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

[Lennart Poettering]

On Thu, 02.04.15 14:33, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:

> 
> 
> On 04/02/2015 01:21 PM, Lennart Poettering wrote:
> >Well, I disagree. And yeah, I still think that /var/lib/machines
> >should be a subvolume, if it is not created manually as something else
> >before. I hear no convincing case why it shouldn't be one.
> 
> I argue that we should default to directory creation for all filesystems
> that it is the sane upstream default you say we should default to subvolumes
> creation for those that are supported ( currently just btrfs )
> 
> Now let's hear it from you since you seem to be so eager to dismiss both my
> arguments along with Martin's, what value does it add, problems it solves
> and why we ( and thus distribution, administrators, end users and vendors
> basically all consumers of systemd and btrfs ) should default to create
> subvolumes.

Well, you have not listed any "arguments" yourself, or what did I
miss?

Among other things, subvolumes give you the ability to atomically
snapshot, atomically delete, apply quota limits, query quota usage,
and manage per-subvolume read-only states. This is all very useful for
home directories as well as container images. In fact, machined
actually even exposes the quota on /var/lib/machines in high-level
commands, see "machinectl set-limit" for details. The atomically
deletion magic is useful for factory reset purposes. The read-only
flag management is good for allowing root to be read-only while /home
being writable, and so on.

It would be quite weird if we had all the quota magic exposed in
btrfs, but it always fails even on btrfs because we ourselves set
things up incorrectly for this to work.

> Btw my knowledge on btrfs is fine thank you, yours from my pov seems to be
> limited to a single host implementations where it's more implemented for
> development than practicality and you somehow seem to be again not taking
> into account the ramification outside the systemd project itself and it's
> community, the same thing you did with regards to your *visionary* changes
> to hostnames, it's meaning and usage which we discussed on one of the
> hackfests or you recent approval in another thread regarding timedate where
> I side with and say Kay was and is right.

Hmm, visionary changes to hostnames? What's that about?

Lennart

-- 
Lennart Poettering, Red Hat