[systemd-devel] [PATCH] readahead: read /usr files last for rotational media, skip /var

[Kay Sievers]

On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini <bonzini at gnu.org> 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