| |||||||||||||
Various notes on /usr unificationVarious notes on /usr unificationPosted 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:
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
(Log in to post comments)
Various notes on /usr unification Posted Feb 29, 2012 0:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Also, while disks are a lot bigger today than in the past, there are still cases where drives are not large enough to store everything.
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 (subscriber, #36106) [Link]
I think this whole / -> /usr or /usr -> / discussion highlights the need to re-think the FHS more drastically. Clearly not everyone (like me, for example) is happy with moving / into /usr and I keep seeing complaints about use cases that break when you do this. I also see despair from some people who say that we're fooling ourselves if we pretend that there aren't programs that presume /usr is always there when they shouldn't.
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 (✭ supporter ✭, #313) [Link]
while I do not dispute that there are valid use cases for initramfs, why should it be a requirement on all systems?
Various notes on /usr unification Posted Mar 1, 2012 11:27 UTC (Thu) by sorpigal (subscriber, #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]
/me ducks ahead of time, but...
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]
replying to self after reading parent explanation more closely. I guess I understand better the shared vs machine-specific aspect as you enumerated/described. Though given the linking of /bin(actual) to /usr/bin (as opposed to symlinks for each content file/binary), would mean that if I understand correctly, that now there _is no non-shared/machine-specific_ place to put a 'binary' (i.e. under /bin in the old-way/your-explanation). In which case our question remains valid. (I think, still ducking). Or rather, you could say- under /usr/local, in which case I would go back to, why not /local.
/local vs /usr/local Posted Mar 1, 2012 18:25 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] I think something like
iff you accept /* -> /usr/*, then why not instead /usr/* -> /* Posted Mar 1, 2012 21:11 UTC (Thu) by jspaleta (subscriber, #50639) [Link]
You know....
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]
+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 /)
iff you accept /* -> /usr/*, then why not instead /usr/* -> /* Posted Mar 1, 2012 23:52 UTC (Thu) by filteredperception (guest, #5692) [Link]
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).
Various notes on /usr unification Posted Mar 1, 2012 20:42 UTC (Thu) by dskoll (subscriber, #1630) [Link] / Machine specific, read-only 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 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.
Various notes on /usr unification Posted Mar 2, 2012 5:37 UTC (Fri) by david.a.wheeler (guest, #72896) [Link]
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:
(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
Various notes on /usr unification Posted Mar 2, 2012 19:38 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
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.
Various notes on /usr unification Posted Mar 6, 2012 1:36 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] I don't see
Various notes on /usr unification Posted Mar 6, 2012 11:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
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:
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
Various notes on /usr unification Posted Mar 6, 2012 22:03 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
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.
|
|||||||||||||