LWN: Comments on "Various notes on /usr unification"

Various notes on /usr unification

immibis — Thu, 19 Aug 2021 09:17:28 +0000

And now initramfs would be the strict necessary software to boot, and / would be mounted from THE server.

I actually have one system which has a real partition instead of an initramfs. It works fine. Apparently the only problem is that the tools to maintain it don't exist.

initramfs typically terminates by mounting something else over / using the pivot_root syscall. But there's no reason only an initramfs can do that! You are free to install a minimal system locally and then have its init set up the network and NFS and then pivot_root to NFS.

The most important question not asked

mirabilos — Thu, 13 Dec 2012 15:18:44 +0000

I’ve done C:\WIN for 3.x, 9x and 2000 (NT-based) successfully.

The most important question not asked

farnz — Thu, 08 Mar 2012 18:45:57 +0000

Windows 95 is not a fair comparison here, though. It, Windows 98 and Windows ME were all stop-gaps until Windows NT was able to replace them (which it got close to with Windows 2000, and managed with Windows XP), and they did a variety of interesting things related to their ability to use MS-DOS device drivers for low level filesystem access. It's much the same situation as criticising Linux, because when you run certain apps on a FreeBSD system with their Linux compatibility layer they don't work well.

Of course, this shows one side of the "gradual change" coin - Windows XP was released in 2001, so it took Microsoft 6 years to shift people in their preferred direction.

If you could repeat the experiment with NT-based Windows, that would be interesting; I don't know if any NT Windows could install to a directory other than C:\Windows or C:\WINNT, however.

The most important question not asked

khim — Thu, 08 Mar 2012 14:46:25 +0000

And, of course “c:\Windows” is not “c:\Windows System” because Windows itself does not like spaces (or long file names). Typical for Microsoft: everyone else should fix their programs when they port to new version of Windows (old programs saw “C:\PROGRA~1” and were happy), but Microsoft don't.

P.S. This is not a speculation: Windows9x gave you ability to select name of directory where you can install it. I've installed it in “c:\Program Files\Windows” (to keep it confined to a single subdirectory) and then various Microsoft packages started complaining that they should be moved from “c:\Program Files\Windows” to “c:\PROGRA~1\WINDOWS”… When I've reported it as a bug in DirectX the bug was closed as INVALID with comment that you should not use non-MSDOS names from the main Windows directory.

The most important question not asked

nye — Thu, 08 Mar 2012 14:05:05 +0000

>While we're at it, fstab is so 70s, how about /etc/filesystems.

ITYM '/Et Cetera/My Filesystem Table'

(So apparently one of the reasons for 'c:\Program Files', when other options like 'c:\Programs' seem more sensible is that it was a way to flush out programs which didn't handle spaces in file paths.)

Various notes on /usr unification

slashdot — Thu, 08 Mar 2012 09:48:31 +0000

Just use a custom init that mounts /usr and then execs the real init.

Various notes on /usr unification

kragil — Thu, 08 Mar 2012 09:28:20 +0000

Stupid Debian-bashing (from a person who probably does not use it)
In place upgrades generally work just great and are supported on Debian. Sure they are not 100% perfect for everyone, but they have been for me.

Your Canonical-bashing is a lot better than this.

Various notes on /usr unification

dlang — Tue, 06 Mar 2012 22:03:49 +0000

why would there be enough benefit in a more human readable fstab (which is mostly not manipulated by humans anyway) that would make it worth breaking all existing tools that understand the current format?

while I would agree that there are nicer ways to configure what's managed by fstab, there is a large pool of tools and training that know the existing format, what may have been a great change to make 30 years ago needs much more justification now.

Various notes on /usr unification

rgmoore — Tue, 06 Mar 2012 21:48:58 +0000

I could definitely see a reworked fstab format. Even if you don't want to work in dependencies- there's some concept of ordering, at least- the format is also terse and cryptic. I wouldn't mind something a bit more verbose and readable. Just don't let Lennart Poettering get involved, or it'll generate another tempest in a teapot no matter how good an idea it is.

Various notes on /usr unification

Cyberax — Tue, 06 Mar 2012 11:37:04 +0000

I wouldn't mind something fstab-y but a little bit more modern. Fstab format is way too obsolete, there are no real notions of dependencies and ordering.

For example, Amazon EC2 nodes have specialized disks for scratch space. I want to assemble a RAID-0 of them, format them as XFS and then mount them on /tmp.

In my ideal world the fstab-ng would have entry like:
>none /tmp xfs defaults,noatime depends-on=assemble-scratch-raid

Where assemble-scratch-raid is, perhaps, a systemd task.

Various notes on /usr unification

rgmoore — Tue, 06 Mar 2012 01:36:47 +0000

I don't see fstab as losing its importance. You still need some place to record the identifiers and mount points for the key partitions, which may include things like /var, /tmp, /opt, and /usr/local in addition to the ones you mentioned. That information has to remain available after initramfs has done its job, and root still needs to be able to edit it in case the hardware configuration changes. It seems to me that it's simpler to have one canonical copy of fstab that's located on the one disk that initramfs knows about by itself. The mount process is a bit more complicated than it would be if initramfs had its own copy of fstab- you have to mount that disk, read fstab, and then mount any other disks mentioned there- but that's still simpler than trying to keep two copies of fstab in sync by rebuilding initramfs any time the canonical copy is edited.

Various notes on /usr unification

man_ls — Mon, 05 Mar 2012 22:41:33 +0000

Sounds like a smokescreen to me. All we are saying is that live upgrading a Debian system is supported, while on Fedora it is not. Not that it is flawless.

Various notes on /usr unification

jwakely — Mon, 05 Mar 2012 12:12:43 +0000

You can, but it means the same as #!./bash so probably doesn't do what you wanted.

Various notes on /usr unification

Cyberax — Mon, 05 Mar 2012 10:55:12 +0000

I never understood why can't we just write:
>#!bash
or
>#!env bash

instead of using absolute paths.

Various notes on /usr unification

jschrod — Mon, 05 Mar 2012 09:53:27 +0000

But with /bin being a symlink to /usr/bin this would actually work, for once.

Not like now, where you can't write a bash script for both Linux (/bin/bash) and FreeBSD (/usr/bin/bash) without using #!/usr/bin/env. Then it could just be /usr/bin/bash and we would be done. Just as in Solaris, since many years.

Various notes on /usr unification

Cyberax — Sun, 04 Mar 2012 22:36:48 +0000

As I understand, unionfs in FUSE is pretty complete.

However, FUSE itself is not ready at all for high-performance filesystems. It's fine for things like sshfs over WAN but totally sucks for local filesystems.

Various notes on /usr unification

dpquigl — Sun, 04 Mar 2012 18:02:39 +0000

If you want to go with file system approaches unionfs and aufs have been around long before the FUSE version of unionfs. How full featured is the FUSE one? From what I understand everyone has been focusing on the most common case which is one RW branch and one RO branch. They don't want to do an arbitrary number of branches.

Various notes on /usr unification

dirtyepic — Sun, 04 Mar 2012 17:45:35 +0000

> A lot of software doesn't support being upgraded while it's running

I'm going to have to call bullshit on that one. See every rolling distro ever.

> or config files get rewritten by upgrade processes to fit the new version
> and then the old version overwrites the changes when it's flushing state
> to disk while quitting

Well, first of all, don't overwrite config files. Store the new config somewhere else and give the user an interactive diff tool. Second, any service that writes state to a file that would get overwritten on a reinstall is broken. Any service that can't recognize state information from its previous version is broken.

> "Being replaced while running" is a scenario very few projects test for.

Because it rarely causes problems. The majority of Gentoo systems are upgraded continually while in use. The biggest problem I had after upgrading and recompiling every package installed on a system that hadn't been updated in six months, which included major gcc and glibc updates, was Firefox wouldn't open links sent to it from external programs until I restarted it.

Various notes on /usr unification

cmccabe — Sun, 04 Mar 2012 06:25:51 +0000

And if a Boeing 747 crash-lands on top of the computer, that would probably be bad too. But how is it related to what we were talking about?

Just to be clear, the issue we were talking about was version skew in libraries causing applications to misbehave during the upgrade.

Various notes on /usr unification

Cyberax — Sat, 03 Mar 2012 22:07:07 +0000

FUSE union mounts actually work, but way too slow for real use.

And no, I'm not aware of any progress in that area.

Various notes on /usr unification

dpquigl — Sat, 03 Mar 2012 17:00:59 +0000

Has there been any progress on union mounts in the last year? Last I saw the conversation ended with the proposal dead in the water. I don't believe they ever determined who's responsibility it was to do culling of duplicate entries (the kernel, or glibc). Also the FUSE guy chimed in and claimed all the work was unnecessary and he could just do it in fuse.

The most important question not asked

anselm — Fri, 02 Mar 2012 22:52:11 +0000

That's already spoken for.

Various notes on /usr unification

Cyberax — Fri, 02 Mar 2012 19:38:49 +0000

fstab is becoming more and more useless by the day. If initramfs is going to be mounting the real / and /usr then maybe we could move mounting of other filesystems there?

After all, the only major remaining filesystem is /home and maybe a swap partition.

The most important question not asked

dmm — Fri, 02 Mar 2012 16:08:37 +0000

While we're at it, fstab is so 70s, how about /etc/filesystems.

Various notes on /usr unification

rgmoore — Fri, 02 Mar 2012 15:54:11 +0000

But there's no particular reason to split /etc out as a separate directory. It's already a subdirectory of /, which has the same general requirements of being machine specific and only alterable by root. And you probably don't want it as a separate partition because it contains fstab. which is important to have immediately on mounting /.

Various notes on /usr unification

david.a.wheeler — Fri, 02 Mar 2012 05:37:17 +0000

Parent said, "The idea is that you should be able to have a separate partition for each different kind of data...." and listed:
/ Machine specific, read-only
/var Machine specific, read-write, stable across reboots
/tmp Machine specific, read-write, volatile across reboots
/usr Shared, read-only
/home Shared, read-write

Also add:
/etc Machine specific, read-only

(Where "read-only" means "written only by special sys admin actions")

BTW, I am *glad* that there was a usrmove argument. When someone proposes a big change to some convention that is widely used, people should examine it for problems BEFORE it's changed, and any change has some pain. I think usrmove is overall a good idea, though.

iff you accept /* -> /usr/, then why not instead /usr/ -> /*

filteredperception — Thu, 01 Mar 2012 23:52:28 +0000

actually maybe I'm just being stupid. network mounted /usr. Probably I should follow one of these links and either read for the first time, or more likely discover something I never bothered to remember, as to what 'usr' means. (?SharedResource).

iff you accept /* -> /usr/, then why not instead /usr/ -> /*

filteredperception — Thu, 01 Mar 2012 23:48:21 +0000

+1 for the joke jef, but cmon, I know _you_ could have given a legitimate answer to my question... Seriously, what is the short answer for 'why have /usr at all in the post merge world?' (as anything but the compatability symlink, versus putting the opposite compatability symplinks under /)

Various notes on /usr unification

nybble41 — Thu, 01 Mar 2012 21:28:09 +0000

> I guess /var/tmp either has to go or we have to separate the "volatile" filesystems into "volatile-and-likely-to-fit-in-RAM" vs. "volatile-and-possibly-enormous".

I believe /var/tmp is generally considered to be "stable across reboots", so at least that much would remain consistent. *Old* files may be deleted from /var/tmp, of course, but while files in /tmp are only valid for the life of a single process (and thus can always be deleted after a reboot), files in /var/tmp represent transient data which may nonetheless remain useful well after the process which created it has exited.

Since /var/tmp is defined as stable it's unlikely to be located on a RAM disk, but applications using large temporary files must still be prepared for the possibility of running out of free space.

iff you accept /* -> /usr/, then why not instead /usr/ -> /*

jspaleta — Thu, 01 Mar 2012 21:11:32 +0000

You know....
bringing the /me directory into the conversation is just unnecessary complexity.

-jef

Various notes on /usr unification

dskoll — Thu, 01 Mar 2012 20:42:34 +0000

/ Machine specific, read-only
/var Machine specific, read-write, stable across reboots
/tmp Machine specific, read-write, volatile across reboots
/usr Shared, read-only
/home Shared, read-write

I'm sold. That's a beautiful, clear and logical explanation. Thanks.

I guess /var/tmp either has to go or we have to separate the "volatile" filesystems into "volatile-and-likely-to-fit-in-RAM" vs. "volatile-and-possibly-enormous".

/local vs /usr/local

rgmoore — Thu, 01 Mar 2012 18:25:15 +0000

I think something like /local for code that is specific to an individual machine makes sense. Of course, software that's specific to an individual machine is probably being handled outside the distribution, or it would go wherever the distro decides it belongs. That makes dealing with it a local policy issue, so you're free to name and deal with it however you see fit.

Various notes on /usr unification

pboddie — Thu, 01 Mar 2012 18:12:49 +0000

I actually forgot to suggest accusations of trolling, along with "correlation does not imply causation" and "the plural of anecdote is not data". Of course such terms and phrases describe actual phenomena, but they also seem to take the role of the panic button in any discussion.

Various notes on /usr unification

drago01 — Thu, 01 Mar 2012 16:27:44 +0000

> On a somewhat related note, I'd like to make a motion to retire the term "bikeshedding".

The term at least has a meaning. I'd rather retire the term "power user" ;)

Various notes on /usr unification

nix — Thu, 01 Mar 2012 14:34:29 +0000

This is called the euphemism treadmill.

Mass rebuilds

smurf — Thu, 01 Mar 2012 12:59:51 +0000

Same for Debian, except that it's usually a single developer with too much free time and/or raw CPU power on their hands who decides to do their own personal mass rebuild – and file bugs about everything that fails to build.

Various notes on /usr unification

Cyberax — Thu, 01 Mar 2012 12:56:58 +0000

Well, in this case /root might be necessary. But it still strikes me as an extra top-level directory which is hardly ever needed now.

Maybe it could be a job for union mounts (once Valerie Aurora gets them mainlined).

Various notes on /usr unification

smurf — Thu, 01 Mar 2012 12:38:58 +0000

Not always, no.
Some login methods require files in $HOME. sshd with authorized_keys is only one of them. Not every system has a console, and even if it has one I don't want to force somebody to go to the data center and plug something magic into some blade system just because a reboot has managed not to mount $HOME.
(Which might as well be on NFS. To require a working NFS for root login is stupid.)

Various notes on /usr unification

sorpigal — Thu, 01 Mar 2012 11:27:19 +0000

I don't insist on one. If the issue is packaging effort it seems logical to take what is built for initramfs purposes and make that the "minimal root" stuff for people without an initramfs, just place it on disk as usual.

Various notes on /usr unification

AndreE — Thu, 01 Mar 2012 08:45:53 +0000

Should we get rid of the word "wolves" though?

LWN: Comments on "Various notes on /usr unification"

Various notes on /usr unification

The most important question not asked

The most important question not asked

The most important question not asked

The most important question not asked

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

The most important question not asked

Various notes on /usr unification

The most important question not asked

Various notes on /usr unification

Various notes on /usr unification

iff you accept /* -> /usr/*, then why not instead /usr/* -> /*

iff you accept /* -> /usr/*, then why not instead /usr/* -> /*

Various notes on /usr unification

iff you accept /* -> /usr/*, then why not instead /usr/* -> /*

Various notes on /usr unification

/local vs /usr/local

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Mass rebuilds

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

Various notes on /usr unification

iff you accept /* -> /usr/, then why not instead /usr/ -> /*

iff you accept /* -> /usr/, then why not instead /usr/ -> /*

iff you accept /* -> /usr/, then why not instead /usr/ -> /*