Further history of Unix of /usr

Posted Jan 11, 2016 16:49 UTC (Mon) by giraffedata (guest, #1954)
In reply to: Further history of Unix of /usr by nybble41
Parent article: Preparing for a merged /usr in Debian

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.