On 04/02/2015 03:48 PM, Lennart Poettering wrote:
On Thu, 02.04.15 14:33, Jóhann B. Guðmundsson (johan...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
