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

"Jóhann B. Guðmundsson" johannbg at gmail.com
Thu Apr 2 05:31:02 PDT 2015



On 04/02/2015 08:31 AM, Lennart Poettering wrote:
> On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
>
>>
>> On 04/01/2015 02:37 PM, Lennart Poettering wrote:
>>> 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.
>> I'm afraid that will still only work on a single host setup ( laptop/desktop
>> ) and I'm pretty sure if the intent from you is to default to more subvolume
>> creation i'm afraid you will start conflicting with installers on top of
>> everything else as well.
> Why would this conflict with installers?


Beside the obvious point that you on your own accord have started to 
decide *for* the end user what his intend are based on your own 
assumption ( which is something the end user decided at install time or 
later on if he administrates said host ) after install time, last time I 
checked installers ( as many other tools ) had a hard time themselves 
dealing properly with subvolumes and support btrfs properly.

You thought that /var/lib/machines being a subvolume was the right thing 
to do and you were wrong, it only works for you on your own host but 
never in practice for administrators whom are the target audience for 
that feature.

You think that /home should be created as subvolume by default, again 
wrong not only for the end user who will be scratching their heads 
wondering where their space went but also for administrators whom have 
this stored on NAS/SAN with their own specific btrfs policy build on top 
of storage pools ( if they are using btrfs )

As I said before subvolumes should not be created et all by default just 
directories which is the sane default from upstream until btrfs has 
become widespread enough and tools, application and end users have 
gotten used to it.

JBG


More information about the systemd-devel mailing list