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
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@g.o 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


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