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

["Jóhann B. Guðmundsson"]

On 04/02/2015 03:48 PM, Lennart Poettering wrote:
> 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?

?

I have made many arguments why subvolumes should not be enabled by 
default and why that power to enable that should be delegated to the 
distributions themselves at the time of their choosing (which most 
likely will be around the time they default to btrfs ).

I'm not arguing against systemd integrating itself with all the bells 
and whistle btrfs has to offer, I'm arguing against those implementation 
being enabled by default on btrfs since currently they cause more 
problems then they solve ( due to the fact btrfs has not become 
widespread enough for users to have learned to manage it ).

>
> 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.

The only use case ( which seem to be the use case you are fixated on in 
this particular case ) that we can manage to setup this correctly is for 
a single host on an local disk and systemd somehow magically takes care 
of everything with no end user administrator involvement whatsoever so 
it only works for one consumer group ( desktop ) not two ( embedded + 
desktop or server + desktop ) or all ( embedded + servers + desktop ).

For an upstream default I would say that the default needs to be 
beneficial to at least two consumer groups, preferably three with the 
least havoc caused downstream.

>
>> 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?

Your view on hostnames which conflicted with the entire IT industry's 
view on hostnames and their historic uses.

That discussion happened when we were discussing one of the bugs filed 
against systemd on one of the systemd hackfest in brno @ Red Hat which 
ended with the correct resolution once discussed ( in other words you 
change your mind after that discussion ).

It was the hackfest that got recorded if memory serves me correct.

JBG