Gentoo Archives: gentoo-dev

From: Joshua Kinard <kumba@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Date: Tue, 13 Mar 2012 01:23:26
In Reply to: Re: [gentoo-dev] Re: newsitem: unmasking udev-181 by William Hubbs
1 On 03/11/2012 13:33, William Hubbs wrote:
3 > I highly discourage moving more things to /. If you google for things
4 > like, "case for usr merge", "understanding bin split", etc, you will
5 > find much information that is very enlightening about the /usr merge and
6 > the reasons for the /bin, /lib, /sbin -> /usr/* split.
7 >
8 > I'll start another thread about this farely soon, but for now I'll say
9 > that even though Fedora is a strong advocate of the /usr merge, it
10 > didn't start there. Solaris started this 15 years ago, and I think it
11 > would be a good thing for gentoo to implement the /usr merge at some
12 > point to make us more compatible with other unixes. Another thing to add
13 > is that it appears that at least Fedora and Debian are doing this.
17 On a somewhat sarcastic note, why don't we just deprecate /usr and move
18 everything back to /? Isn't that, largely, what is being accomplished here?
19 Solaris at least keeps some kernel stuff in / off of /stand (I believe).
20 Linux, after this /usr thing is fully complete, about the only thing left in
21 / that is of any value will be /etc. Kernels were moved into /boot ages ago.
23 I mean, what really is / in the literal sense? It's the first filesystem
24 that the kernel mounts. If you put everything into /usr, including the init
25 scripts and /etc, create a few stub mount points for /var, /tmp, etc
26 (assuming those are separate partitions), then told the kernel that /usr is
27 /, what's the real difference? So I think Fedora's approach, while copying
28 existing behavior from Solaris, is partially broken in this regard.
30 We should be working to getting rid of /usr and bring it all back into /,
31 then create temporary /usr symlinks to point programs in the right
32 direction. After all, /usr was originally for user data, not system data,
33 until someone cooked up /home (I don't know the full exact history here, so
34 feel free to correct me).
36 Heck, why not redesign the original root filesystem layout while we're at it?
38 / - Root.
39 /boot - Kernels, bootloader.
40 /apps - Installed, non-system critical applications. Merges /bin,
41 /sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and
42 all of its multilib variants.
43 /core - System-critical apps needed to get the system into a MINIMAL,
44 usable state (core device detection, mounting disks, etc)
45 /conf - System configuration data.
46 /dev - Device nodes.
47 /home - User stuff.
48 /data - Variable data. /var's new name.
49 /tmp - System-wide temp dir.
50 /virt - virtual filesystems (proc, sys, ramfs).
51 /svcs - Data dir for services (Apache, LDAP, FTP, etc).
52 /ext - holds mount points for external devices (merges /mnt & /media).
53 /root - Superuser's /home.
56 From that, for the new proposed directories:
58 /apps/sys/bin - System binaries. Only non-critical, system-wide binaries
59 go here.
60 /apps/sys/lib - Like /apps/sys/bin above. Except this can also be
61 duplicated for multilib (lib32, lib64, lib128, etc).
63 /apps/std/bin - Standard program binaries for all non-system, non-critical
64 binaries.
65 /apps/std/lib - Like /apps/std/bin above. Ditto for multilib.
67 /apps/local - If on a stand-alone system, this is a symlink to /apps/std.
68 otherwise, this holds a bin/lib folder that is only for apps
69 installed locally, while /apps/std might be a network mount
70 that holds apps common to multiple systems of the
71 same/similar type of install.
73 /core/bin - Critical system, binaries needed to get the system into a
74 minimally-usable state. Predominantly occupied by various
75 filesystem tools.
76 /core/lib - Libraries, usually static, to support /core/bin. Can be
77 multilib, but a system should have a single ABI that can
78 successfully boot the userland components of the system.
79 /core/inf - Holds minimal information to identify and locate
80 boot-critical devices, typically in the form of a small
81 database of some design, but which can be parsed with
82 no additional dependencies.
83 /core/init - Home of your init system of choice, including all the
84 information needed for various run levels, etc. Its
85 sub-layout is dependent on the particular init system that
86 is installed.
88 /conf - Basically a rename of /etc. The "etc" name doesn't
89 convey any useful information to a user anymore about its
90 true purpose. /conf, however, does. Files stored here
91 will largely be comprised of text files that configure
92 various system services. Like /etc, it's sub-layout will
93 probably be a complete, unrestrained mess.
95 /virt - Everyone loves virtual filesystems. When there was just
96 /proc, everything was alright. Then /sys comes along, and
97 now we've polluted the / namespace with two virtual
98 filesystems. /virt provides a home for those (so /virt/proc
99 and /virt/sys), in addition to others like /virt/shm,
100 and /virt/pts, or even /virt/ramfs if you want. Anything
101 in here doesn't physically exist, and either changes rapidly
102 or is lost once the system loses power.
104 /data - Like "etc", /var's original function has been largely
105 overridden and hardly contains "variable" data anymore.
106 thus, it is reborn as /data, which conveys *exactly* what
107 it is for -- data of some kind, whose presence may be
108 permanent or transitory. Mail spools, caches, print spools,
109 whatever. Fill it with data from /dev/urandom if you want!
111 /svcs - Like /srv, which some people are resistant to using. The
112 original idea is quite a marvel, though, because it never
113 really made any sense to stick Apache into /var/www, or hang
114 the TFTP boot directory off of /, or chroot BIND inside of
115 /etc or /var (or both).
117 /ext - A place for external mounts, either filesystems or devices.
118 NFS, CD-ROMs, thumb drives, Samba/CIFS, etc, it goes here.
119 This replaces both /mnt and /media, the only difference
120 between the two being the same as the difference between
121 two shades of purple. The only exception to this rule is
122 /apps/local above.
124 All other directories retain their original, standard functionality.
127 I thought this up on a whim, it hasn't been tested nor vetted. It's largely
128 meant as a joke, but also to provoke discussion on the current filesystem
129 design and the direction we're getting pulled in with Fedora's declaration
130 that separate /usr is broken. I don't think it is and I don't find their
131 argument very convincing, and probably never will.
133 At some point after this change becomes fully adopted (and it will, trust
134 me), the difference between the / of old and /usr will be so minor, that you
135 could probably move a few files around, chop /usr off into a separate
136 partition, and then pass root=/dev/<where /usr is>, and bring a system fully
137 online, *without a /usr*. And then, after that, someone will come along and
138 propose "the new /usr", and the cycle repeats.
140 But I do, hesitantly, agree that the standard UNIX filesystem has a lot of
141 "traditions" to it that don't make a lot of sense anymore. It's a hallmark
142 of an era where machines usually kept a local copy of stuff needed to start
143 or stop themselves. Now we're in an era where machines aren't even physical
144 anymore. The location of actual data is somewhat meaningless, if you write
145 a program correctly and don't hardcode filesystem paths.
147 So it's probably time to have some kind of a discussion on the filesystem,
148 and what would need to change to bring it up to date with the era of
149 large-scale virtualization and embedded systems that run on your wristwatch,
150 in addition to the standard black (or beige) box sitting on a desk somewhere.
152 Food for thought. And yes, I've already tested out udev-181 on a VM with a
153 separate /usr. With devtmpfs, the system fully boots just fine, no
154 initramfs needed. Guess what the only piece of software to mess up is?
155 Udev. I largely think it's a timing issue in OpenRC, however, because /usr
156 DOES get mounted fairly quickly, but not before udevd starts. But udevd
157 does restart itself and everything looks to work fine. If you aren't
158 watching the terminal, you wouldn't even notice the failures.
160 Cheers,
162 --
163 Joshua Kinard
164 Gentoo/MIPS
165 kumba@g.o
166 4096R/D25D95E3 2011-03-28
168 "The past tempts us, the present confuses us, the future frightens us. And
169 our lives slip away, moment by moment, lost in that vast, terrible in-between."
171 --Emperor Turhan, Centauri Republic


File name MIME type
signature.asc application/pgp-signature