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" <kay.sievers@vrfy.org> To: "Paolo Bonzini" <bonzini@gnu.org> Cc: <systemd-devel@lists.freedesktop.org> 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 <bonzini@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