Further history of Unix of /usr

Posted Jan 10, 2016 20:22 UTC (Sun) by mjg59 (subscriber, #23239)
In reply to: Further history of Unix of /usr by giraffedata
Parent article: Preparing for a merged /usr in Debian

Moving everything to / means either (a) you can't have a read-only /, or (b) /var and /etc need to be separate mountpoints. Merging to /usr means you can have a read-only /usr and a read-write /, and that makes it possible to do a/b upgrades by having two /usr partitions, writing the update into the second and rebooting into it while still using the same / and so maintaining mutable state.

Further history of Unix of /usr

Posted Jan 11, 2016 12:21 UTC (Mon) by tao (subscriber, #17563) [Link] (8 responses)

Having /etc and/or /var be a separate mountpoint is not a hurdle even if things are unified over / rather than /usr,
due to the wonderful awesome sauce called bind-mounts.

And I really don't get how you can first say that not being able to have a read-only / is a problem, then say that having everything in /usr is an advantage since you can have / read-write :P

Further history of Unix of /usr

Posted Jan 11, 2016 16:10 UTC (Mon) by raven667 (subscriber, #5198) [Link]

The files which he wants the read-only property applied to are the binaries and libraries, so the policy applies to the filesystem which contains them, if that's / then /etc and /var need to be separated, if its /usr then only /usr needs that policy applied and / can contain /etc and /var and be read-write.

Further history of Unix of /usr

Posted Jan 11, 2016 16:13 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (6 responses)

> And I really don't get how you can first say that not being able to have a read-only / is a problem, then say that having everything in /usr is an advantage since you can have / read-write :P

That's because the parts that need to be read-only have all been moved from / to /usr, leaving only /etc and /var as part of the root filesystem. The problem with making / read-only to protect /bin and /lib was that you needed a read-write filesystem for /var, and possibly for /etc as well.

Further history of Unix of /usr

Posted Jan 11, 2016 16:49 UTC (Mon) by giraffedata (guest, #1954) [Link] (5 responses)

Incidentally, I believe /etc is just as deserving of being read-only as /bin and /lib (and on my systems, it is). In particular, it's something that ought to change only via manual administrative process.

And there are many storage management reasons that the parts of a system that change a lot should be in a separate filesystem from the parts that change only as part of system administration events, and /var is perfect for that. To me, that's the very definition of /var, which fuels my belief that / should be r/o, which removes one of the reasons to have /usr .

Further history of Unix of /usr

Posted Jan 11, 2016 17:01 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (4 responses)

There's different kinds of read-only. A filesystem that's mounted read-only but can be remounted read-write is one, one that's fundamentally read-only (either because the underlying media is read-only, or because you're using something like dm-verity) is another. Having /etc on the latter is problematic, but it's well suited to /usr.

There's basically three regions of mutable state on a normal Linux system - /home, /etc and /var. They're all in /, so it's easier to retain / as read-write and push the non-mutable content to /usr than it is to have / as read-only and either move all the mutable content elsewhere or have some magical procedure to update it. There are certainly configurations where moving everything to / would work out fine, but moving things to /usr instead makes it possible to do some things that are otherwise difficult without interfering with anything other than certain aesthetic beliefs.

Further history of Unix of /usr

Posted Jan 12, 2016 4:30 UTC (Tue) by giraffedata (guest, #1954) [Link] (3 responses)

I guess there's no limit to the kind of system configurations there can be, each with its own ideal filesystem hierarchy. I think a system that has all the system executables on a read-only medium, without having the root filesystem on that same medium must be pretty rare. But I'm sure one can imagine it.

It's also my experience that /home gets split out into its own filesystem a lot more than /usr does, but there is probably some case where it makes sense to keep /home in the root filesystem even though it's not a single-filesystem system.

Further history of Unix of /usr

Posted Jan 12, 2016 4:32 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

> I think a system that has all the system executables on a read-only medium, without having the root filesystem on that same medium must be pretty rare.

It's how all of our users run, and that's a pretty large number.

Further history of Unix of /usr

Posted Jan 13, 2016 3:55 UTC (Wed) by giraffedata (guest, #1954) [Link] (1 responses)

I think a system that has all the system executables on a read-only medium, without having the root filesystem on that same medium must be pretty rare.
It's how all of our users run, and that's a pretty large number.

Are you talking about a network filesystem? Because "the network" is not a storage medium, so that's confusing.

Further history of Unix of /usr

Posted Jan 13, 2016 4:00 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

> Are you talking about a network filesystem? Because "the network" is not a storage medium, so that's confusing.

No. /usr is backed by dm-verity, so from the filesystem perspective it's a read-only block device.