Various notes on /usr unification
Various notes on /usr unification
Posted Feb 28, 2012 23:51 UTC (Tue) by rgmoore (✭ supporter ✭, #75)In reply to: Various notes on /usr unification by dskoll
Parent article: Various notes on /usr unification
No seriously, what's the point of even having /usr?
The idea is that you should be able to have a separate partition for each different kind of data. It should be possible to keep read-only data (or data that is only supposed to be written by a sysadmin) on a separate partition from data that's frequently written, data that's specific to a particular machine separate from data that can be shared across multiple machines, and data that is volatile across a reboot separate from data that needs to be preserved across reboots. So the idea is that standard partitions are supposed to be:
/ 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
Note that not all combinations make sense. It only makes sense to have a volatile partition that's read-write (how would a volatile read-only partition accumulate any files after being wiped?) and machine specific (whose reboot would a shared volatile partition be volatile across?). Other than that, though, you have all the possible combinations.
I think that part of the problem right now is that there's a legitimate disagreement about the function of /. Some people are big believers in the "separate partition for separate kinds of data" idea, and they want to move all binaries and libraries into /usr. Other people see the main function of / as a minimal system partition that can be used to bring the rest of the system up, and they want to keep essential binaries and libraries in /.
(Log in to post comments)
Various notes on /usr unification
Posted Feb 29, 2012 0:02 UTC (Wed) by dlang (guest, #313) [Link]
you may want your main system on a small SSD for fast reading, while data that is being archived (and seldom read like log files) are on a slower, but large SATA drive, and other data may need to be on a raid array for redundancy.
Various notes on /usr unification
Posted Feb 29, 2012 13:42 UTC (Wed) by sorpigal (guest, #36106) [Link]
Maybe it's time to lay out a new FHS, beginning by describing all of the uses we need to get out of it, and make one big painful move instead of this piecemeal nobody-is-happy stuff.
Q: If initramfs is the new "minimal root" and we have to maintain it anyway just to boot, can we maintain it in its own partition mounted on /init/ and re-do the boot process to use that path at all times whether it's a real disk or a ramfs?
Q: If /tmp and and /etc are local-only, but /usr is not, is there a way we can signal that in the FHS so that people can't be easily confused in the future?
I don't know, but it seems like fighting about what should go in /usr and whether anybody really needs to share it over NFS is idiotic and tangential to the real issue, which is how to solve problems people actually have. Nobody seriously cares where files are located as long as everyone can still do what they need to do.
It's a bit like Debian's multi-arch. There are a lot of ways to solve a lot of little problems but only a few that solve them in a big way for a long time.
Various notes on /usr unification
Posted Feb 29, 2012 20:22 UTC (Wed) by dlang (guest, #313) [Link]
Various notes on /usr unification
Posted Mar 1, 2012 11:27 UTC (Thu) by sorpigal (guest, #36106) [Link]
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.
iff you accept /* -> /usr/*, then why not instead /usr/* -> /*
Posted Mar 1, 2012 7:29 UTC (Thu) by filteredperception (guest, #5692) [Link]
While your answer to the question I was trudging through dozens of comments to get to (not worth a sentence in the article?) was quite long, I don't think it was sufficient. I think your answer was still within the debate of 'should the move happen'. But what I think the original ducking questioner was asking was-
If you are one of the people who believe in moving /* stuff to /usr/, then please explain why you specifically think that is better than the opposite of moving /usr/* stuff to /, as that would achieve shorter paths, and since, at least from a limited perspective, _once you are in the usrmove camp_, it seems hard (unless us duckers are missing something obvious) to explain what the point of /usr is at all.
iff you accept /* -> /usr/*, then why not instead /usr/* -> /*
Posted Mar 1, 2012 8:00 UTC (Thu) by filteredperception (guest, #5692) [Link]
/local vs /usr/local
Posted Mar 1, 2012 18:25 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]
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.
iff you accept /* -> /usr/*, then why not instead /usr/* -> /*
Posted Mar 1, 2012 21:11 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
bringing the /me directory into the conversation is just unnecessary complexity.
-jef
iff you accept /* -> /usr/*, then why not instead /usr/* -> /*
Posted Mar 1, 2012 23:48 UTC (Thu) by filteredperception (guest, #5692) [Link]
iff you accept /* -> /usr/*, then why not instead /usr/* -> /*
Posted Mar 1, 2012 23:52 UTC (Thu) by filteredperception (guest, #5692) [Link]
Various notes on /usr unification
Posted Mar 1, 2012 20:42 UTC (Thu) by dskoll (subscriber, #1630) [Link]
/ 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".
Various notes on /usr unification
Posted Mar 1, 2012 21:28 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
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.
Various notes on /usr unification
Posted Mar 2, 2012 5:37 UTC (Fri) by david.a.wheeler (guest, #72896) [Link]
/ 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.
Various notes on /usr unification
Posted Mar 2, 2012 15:54 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]
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
Posted Mar 2, 2012 19:38 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
After all, the only major remaining filesystem is /home and maybe a swap partition.
Various notes on /usr unification
Posted Mar 6, 2012 1:36 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]
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
Posted Mar 6, 2012 11:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
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
Posted Mar 6, 2012 21:48 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]
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
Posted Mar 6, 2012 22:03 UTC (Tue) by dlang (guest, #313) [Link]
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.