[gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard <kumba@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 9074 bytes --]

On 03/11/2012 13:33, William Hubbs wrote:

> I highly discourage moving more things to /.  If you google for things 
> like, "case for usr merge", "understanding bin split", etc, you will
> find much information that is very enlightening about the /usr merge and
> the reasons for the /bin, /lib, /sbin -> /usr/* split.
> 
> I'll start another thread about this farely soon, but for now I'll say 
> that even though Fedora is a strong advocate of the /usr merge, it
> didn't start there. Solaris started this 15 years ago, and I think it
> would be a good thing for gentoo to implement the /usr merge at some
> point to make us more compatible with other unixes. Another thing to add
> is that it appears that at least Fedora and Debian are doing this.



On a somewhat sarcastic note, why don't we just deprecate /usr and move
everything back to /?  Isn't that, largely, what is being accomplished here?
 Solaris at least keeps some kernel stuff in / off of /stand (I believe).
Linux, after this /usr thing is fully complete, about the only thing left in
/ that is of any value will be /etc.  Kernels were moved into /boot ages ago.

I mean, what really is / in the literal sense?  It's the first filesystem
that the kernel mounts.  If you put everything into /usr, including the init
scripts and /etc, create a few stub mount points for /var, /tmp, etc
(assuming those are separate partitions), then told the kernel that /usr is
/, what's the real difference?  So I think Fedora's approach, while copying
existing behavior from Solaris, is partially broken in this regard.

We should be working to getting rid of /usr and bring it all back into /,
then create temporary /usr symlinks to point programs in the right
direction.  After all, /usr was originally for user data, not system data,
until someone cooked up /home (I don't know the full exact history here, so
feel free to correct me).

Heck, why not redesign the original root filesystem layout while we're at it?

/     - Root.
/boot - Kernels, bootloader.
/apps - Installed, non-system critical applications.  Merges /bin,
        /sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and
        all of its multilib variants.
/core - System-critical apps needed to get the system into a MINIMAL,
        usable state (core device detection, mounting disks, etc)
/conf - System configuration data.
/dev  - Device nodes.
/home - User stuff.
/data - Variable data.  /var's new name.
/tmp  - System-wide temp dir.
/virt - virtual filesystems (proc, sys, ramfs).
/svcs - Data dir for services (Apache, LDAP, FTP, etc).
/ext  - holds mount points for external devices (merges /mnt & /media).
/root - Superuser's /home.


From that, for the new proposed directories:

/apps/sys/bin - System binaries.  Only non-critical, system-wide binaries
                go here.
/apps/sys/lib - Like /apps/sys/bin above.  Except this can also be
                duplicated for multilib (lib32, lib64, lib128, etc).

/apps/std/bin - Standard program binaries for all non-system, non-critical
                binaries.
/apps/std/lib - Like /apps/std/bin above.  Ditto for multilib.

/apps/local   - If on a stand-alone system, this is a symlink to /apps/std.
                otherwise, this holds a bin/lib folder that is only for apps
                installed locally, while /apps/std might be a network mount
                that holds apps common to multiple systems of the
                same/similar type of install.

/core/bin     - Critical system, binaries needed to get the system into a
                minimally-usable state.  Predominantly occupied by various
                filesystem tools.
/core/lib     - Libraries, usually static, to support /core/bin.  Can be
                multilib, but a system should have a single ABI that can
                successfully boot the userland components of the system.
/core/inf     - Holds minimal information to identify and locate
                boot-critical devices, typically in the form of a small
                database of some design, but which can be parsed with
                no additional dependencies.
/core/init    - Home of your init system of choice, including all the
                information needed for various run levels, etc.  Its
                sub-layout is dependent on the particular init system that
                is installed.

/conf         - Basically a rename of /etc.  The "etc" name doesn't
                convey any useful information to a user anymore about its
                true purpose.  /conf, however, does.  Files stored here
                will largely be comprised of text files that configure
                various system services.  Like /etc, it's sub-layout will
                probably be a complete, unrestrained mess.

/virt         - Everyone loves virtual filesystems.  When there was just
                /proc, everything was alright.  Then /sys comes along, and
                now we've polluted the / namespace with two virtual
                filesystems.  /virt provides a home for those (so /virt/proc
                and /virt/sys), in addition to others like /virt/shm,
                and /virt/pts, or even /virt/ramfs if you want.  Anything
                in here doesn't physically exist, and either changes rapidly
                or is lost once the system loses power.

/data         - Like "etc", /var's original function has been largely
                overridden and hardly contains "variable" data anymore.
                thus, it is reborn as /data, which conveys *exactly* what
                it is for -- data of some kind, whose presence may be
                permanent or transitory.  Mail spools, caches, print spools,
                whatever.  Fill it with data from /dev/urandom if you want!

/svcs         - Like /srv, which some people are resistant to using.  The
                original idea is quite a marvel, though, because it never
                really made any sense to stick Apache into /var/www, or hang
                the TFTP boot directory off of /, or chroot BIND inside of
                /etc or /var (or both).

/ext          - A place for external mounts, either filesystems or devices.
                NFS, CD-ROMs, thumb drives, Samba/CIFS, etc, it goes here.
                This replaces both /mnt and /media, the only difference
                between the two being the same as the difference between
                two shades of purple.  The only exception to this rule is
                /apps/local above.

All other directories retain their original, standard functionality.


I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
meant as a joke, but also to provoke discussion on the current filesystem
design and the direction we're getting pulled in with Fedora's declaration
that separate /usr is broken.  I don't think it is and I don't find their
argument very convincing, and probably never will.

At some point after this change becomes fully adopted (and it will, trust
me), the difference between the / of old and /usr will be so minor, that you
could probably move a few files around, chop /usr off into a separate
partition, and then pass root=/dev/<where /usr is>, and bring a system fully
online, *without a /usr*.  And then, after that, someone will come along and
propose "the new /usr", and the cycle repeats.

But I do, hesitantly, agree that the standard UNIX filesystem has a lot of
"traditions" to it that don't make a lot of sense anymore.  It's a hallmark
of an era where machines usually kept a local copy of stuff needed to start
or stop themselves.  Now we're in an era where machines aren't even physical
anymore.  The location of actual data is somewhat meaningless, if you write
a program correctly and don't hardcode filesystem paths.

So it's probably time to have some kind of a discussion on the filesystem,
and what would need to change to bring it up to date with the era of
large-scale virtualization and embedded systems that run on your wristwatch,
in addition to the standard black (or beige) box sitting on a desk somewhere.

Food for thought.  And yes, I've already tested out udev-181 on a VM with a
separate /usr.  With devtmpfs, the system fully boots just fine, no
initramfs needed.  Guess what the only piece of software to mess up is?
Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
DOES get mounted fairly quickly, but not before udevd starts.  But udevd
does restart itself and everything looks to work fine.  If you aren't
watching the terminal, you wouldn't even notice the failures.

Cheers,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]