Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote: 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. So if we could somehow make this conditional on running on real iron, that would be a good compromise IMHO. I also agree with this. Having a special `btrfs rm -rf` (as is implemented now by systemd/src/shared/btrfs-util.c) copied into various projects is painful. There are a *lot* of tools that do packages in chroots that would all need to be taught this. I'll look at the seccomp approach, but the amount of pain versus gain here seems quite disproportionate right now. (OTOH, I want to use seccomp for RPM things in general, of which this is just one) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 05/21/2015 03:19 PM, Colin Walters wrote: On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote: 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. So if we could somehow make this conditional on running on real iron, that would be a good compromise IMHO. I also agree with this. Real or not makes no difference systemd should not be creating subvolumes et all or atleast there should be a system wide option to disable it altogether and that option should be disabled by default upstream. This breaks btrfs setup/administrations on host, breaks tools etc. so perhaps just best to get a second opinion with upstream btrfs community and get their opinion of having core/base component creating subvolumes on their own is the *smart* thing to do and see if their words are enough to change Lennart's mind about this. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Wed, 01.04.15 15:45, Jan Synacek (jsyna...@redhat.com) wrote: I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johan...@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? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Thu, 02.04.15 08:59, Jan Synacek (jsyna...@redhat.com) wrote: think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. Why not? Subvolumes are fully recursive, hence it doesn't really matter whether they are created on the host or in a chroot environment or a container or whatever else. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Thu, 02.04.15 08:59, Jan Synacek (jsyna...@redhat.com) wrote: think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. Why not? Subvolumes are fully recursive, hence it doesn't really matter whether they are created on the host or in a chroot environment or a container or whatever else. Ok, I discussed this with the maintainer of mock and wrote a patch for it to be able to deal with subvolumes. Thanks for the pointers! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/02/2015 08:31 AM, Lennart Poettering wrote: On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johan...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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? 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Thu, 02.04.15 12:31, Jóhann B. Guðmundsson (johan...@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. Well, first of all, we make decisions for the users all the times. I mean, we declared that /usr is where the OS is located, and not /foobar or any other user-chosen name. And this case isn't even one where we make such a decision, since the user can easily opt-out of the logic, by simple making the dir a dir, so that tmpfiles won't do anything anymore. 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. 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. 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 ) Hmm? where their space went? I am not sure I follow. Multiple subvolumes on the same btrfs volume are all fed from the same big pool. Please read up on btrfs subvolumes, I don't think they work the way you think they do. They aren't fixed size partitions, but simply directories with special semantics. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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. 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. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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
[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Creating subvolumes in chrooted environments makes them undeletable and breaks mock. https://bugzilla.redhat.com/show_bug.cgi?id=1205564 Jan Synacek (1): tmpfiles: don't create subvolumes in chroot src/tmpfiles/tmpfiles.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
---
src/tmpfiles/tmpfiles.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/01/2015 12:33 PM, Jan Synacek wrote:
---
src/tmpfiles/tmpfiles.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created
et all.
Just file a patch that replace v for d for the /var/lib/machines entry
in /usr/lib/tmpfiles.d/var.conf which you are undoubtedly trying to fix
here since it breaks among other things mock.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created et
all.
Why not?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 14:33, Jan Synacek (jsyna...@redhat.com) wrote: Creating subvolumes in chrooted environments makes them undeletable and breaks mock. Humm, I am not convinced that this is a good idea. The chroot environments are hardly undeletable, they just require you to delete them explicitly. There's work going on to tech btrfs-progs recursive deleting of subvolumes. I am pretty sure that's the right fix and mock should really be updated to deal with that... I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/01/2015 01:04 PM, Lennart Poettering wrote:
On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created et
all.
Why not?
Because you break factory,stateless,reproducible,verifiable, mock and
variety of servers setups with enterprise storage of any kind that uses
btrfs ( and whatever else 'v' switch might support in the future ).
( Prime example that covers a lot of usecase where this breaks on btrfs
/var/lib/machines )
Let's leave it up to vendor and downstream distributions to make an
enlighten choice of turning the 'v' feature on after careful
consideration and creating relevant documentation instead of breaking
for them and have every distributions patching this feature out for
example because they suddenly found themselves in a pile of bug reports
because users could not delete those directories in the traditional
manner they had expected ( rm ) but had to magically discover they will
have to use the relevant subvolume removal command for the file system
in question on those directories that it had been enabled on .
Bottom line upstream default should always be 'd' as in create a
directory if it does not exist yet, never v as in create a subvolume if
the path does not exist yet and the file system supports it.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 15:45, Jan Synacek (jsyna...@redhat.com) wrote: I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Wed, 01.04.15 14:33, Jan Synacek (jsyna...@redhat.com) wrote: Creating subvolumes in chrooted environments makes them undeletable and breaks mock. Humm, I am not convinced that this is a good idea. The chroot environments are hardly undeletable, they just require you to delete them explicitly. There's work going on to tech btrfs-progs recursive deleting of subvolumes. I am pretty sure that's the right fix and mock should really be updated to deal with that... undeletable was a bad wording from my side, sorry for that. What I really meant is that mock simply couldn't deal with it... I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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.
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.
So if we could somehow make this conditional on running on real
iron, that would be a good compromise IMHO.
(I don't have a strong enough opinion to start a real fight here, but
at least chalking up my vote)
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 16:02, Martin Pitt (martin.p...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
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. If and when the time comes and btrfs has become the default filesystem in all the major distribution using systemd and the knowledge and the experience of it's usage has become widespread enough, the decision to default to subvolume creation if on btrfs can be re-visited but until that time arrives sticking with directory creation is the right way to go because you are creating more problems for everybody than you are thinking you are solving. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
