On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini <bonz...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
