The idea that separate / from /usr is archaic or wrong is incorrect. Just
saying... Think about it for a bit... Because if you still believe that to be
true...then it is /usr that must go away. Sure, we are like lemmings and we
follow whoever we think should lead...I'm just saying we need to be careful
with making broad statements just because it's some kind of new tradition.
Isn't one of the ideas of systemd is that sysv init wasn't good enough? Just
seems strange to hold onto bad premise because of the need to support bad
assumptions... Especially when advocating change to accomodate systemd. Just
an observation It makes one seem hypocritical.
- Reply message -
From: "Kay Sievers"
To: "Paolo Bonzini"
Cc:
Subject: [systemd-devel] [PATCH] readahead: read /usr files last for rotational
media, skip /var
Date: Fri, Sep 30, 2011 6:32 am
On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini wrote:
> On 09/30/2011 01:05 PM, Tom Gundersen wrote:
>>
>> I think a better heuristic is needed if we want to plan for
>> the future. If I understand correctly, there seems to be a shift
>> towards moving stuff from /lib, /bin and /sbin to /usr/lib, /usr/bin
>> and /usr/sbin, respectively (and requiring /usr to be mounted when
>> systemd starts). That means that at some point in the future we will
>> be back to square one.
Yes, that's right:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
https://fedoraproject.org/wiki/Features/UsrMove
> Requiring /usr to be mounted when systemd starts would sound like a very
> strange thing to me.
There is nothing in systemd requiring that, but in fact, booting with
an empty /usr is not supported and goes wrong all over the place. And
that will not be fixed, or worked around. The split between / and /usr
is a weird UNIX heritage that makes no sense on Linux today, and the
plan is to move all stuff back to /usr, where it belongs, over time.
> And I'm not even that much of a Unix maven. If there
> is any place where a barrier can be placed, that is /usr.
I don't mind having some rules to prioritize things like kernel
modules or some config files, but keying of the /usr directory makes
not much sense to have in the upstream code.
> So much that I've
> been thinking about adding "virtual" mount units that become active as soon
> as any directory above it is mounted. This way, units that require /usr
> could be made to depend on usr.mount.
No, this will all not work for any non-trivial (like a web server or
something very simple) setup. The tools from /usr are needed to boot
up for any modern system.
> In fact, I think it is very wrong to make binfmt load from
> /usr/lib/binfmt.d. Personally, I would have made it /lib/systemd/binfmt.d
> (likewise for tmpfiles).
There should be no early boot tools that need binfmt.
> If you really want to use /usr, there should be two instances of
> binfmt/tmpfiles/etc. one that is activated very early (loading from /etc and
> /lib) and one that is activated after remote-fs.target (in the lack of
> usr.mount---yes, remote!) that loads from /usr/lib and /usr/local/lib.
It's not needed, the stuff in the rootfs will go away over time and
the top-level dirs there will be replaced with compat symlinks.
> As I said, the heuristic is not perfect. However, it is a huge improvement
> and right now the only /usr files that my system needs early are
> binfmt/tmpfiles configuration, plus some coreutils that perhaps should be
> moved to bin (id, tr, getopt).
Nope, all should be in /usr, nothing in the rootfs. The split makes
almost zero sense these days, creates a ton of problems and provides
no real benefit.
>> Also, I'm not sure if I understand your suggestion that /var should be
>> ignored. In particular I think /var/tmp would be useful to readahead
>> (albeit probably as one of the last things to do).
>
> You could add that as a third group, after / and /usr. The patch makes that
> kind of extensibility very easy.
Rules which files to prioritize *might* make sense, sorting by
top-level dir doesn't really.
>> Lots of
>> pregenerated stuff that rarely changes is stored there that we want to
>> load as quickly as possible at boot (e.g. kde's caches).
>
> Yes, /var/tmp is part of why I omitted that part of the patch (despite
> leaving it by mistake in the subject). However, because I use GNOME :) my
> /.readahead doesn't have anything from /var/tmp; only from /var/log.
> Perhaps /var/log should be ignored instead.
Kay
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
