Am Thu, 08 Feb 2018 16:42:23 -0700 schrieb Grant Taylor: > On 02/08/2018 03:32 PM, gevisz wrote: >> In this case it would be nice to hear a reason. > > I think the reason probably goes back a number of years. When /tmp was > made volatile (ram / swap backed) there was a need for non-volatile temp > space. Thus, /var/tmp was created as non-volatile specifically for the > purpose to of surviving across reboots. (At least that's my > understanding.)
I don't think this is the reason. Both directories have been there since ages, long before someone even considered putting that into ram disks. Historically, there would even be /usr/tmp. The point here is that /var is "variable" data in contrast to "read-only" data on the other partitions. This makes /var a candidate for persistent OS-state. You could simply keep / and /usr on volatile storage (or even read-only storage) and all your variable, non-volatile data would be in /var. Having /tmp on tmpfs is then a logical consequence of this because / could be read-only. Also, /etc should be symlinked to /var/etc to enable and keep configuration changes over reboots, although this could also be populated by a boot-strapping process (e.g., IP configuration). This is especially interesting for container-based, dynamic cloud servers which would spawn and disappear on demand, you just need to keep the non- volatile state directory /var. Usually, such systems start with an empty /etc directory which is populated by a boot-strapping process. Following that idea, /var/tmp should also be non-volatile. Bringing this idea further forward, everything related to the OS-image should move to /usr (catchword "usrmerge"), and then / which contains /var and /etc could be writeable and non-volatile, /usr would contain boot-strapping configuration and be read-only, /etc would be populated on first boot. The idea of /tmp on tmpfs is just kept here. The idea of having everything boot-related in / doesn't apply since years (and wasn't the original idea anyways). These days, initramfs takes this role and /usr takes the role of /, and /home already took the role of /usr (that's why it's called /usr, it was user data in early unix). The splitting we have today is a result of size-constraints of early systems when the OS no longer fit one disk, when / became the early boot- environment (initramfs today). Today, the OS uses dynamic linking when most of it was statically linked in the early day, and thus there are dependencies between / and /usr that cannot be untangled easily, and renders the split for early boot-environments difficult to maintain. So everything might easily move to /usr and / can become a non-volatile state partition containing /var and /etc. And early boot lives in initramfs (to setup /usr mount). >> That's why I have asked if it does not harm. > > I don't think it will actually harm the Operating System. Some daemons > may get cross if files they know that they created no longer exist after > a reboot. > > Though things should gracefully handle the absence of such files and > re-create them. > > The biggest Ah Ha moment I ever saw someone have was when they spent > more than an hour getting a Solaris patch cluster to the machine, > extracted it to /tmp, rebooted into single user mode, and went where the > $&#* is the patch cluster? That's when someone more experienced asked > them where they put it and got to educate them on the error of their > ways. > > I doubt that having /var/tmp be volatile will actually break things. Usually not but it might be interesting to have it non-volatile in the scenario I described above: Something which survives the complete machine being discarded (except it's state) and then later boot-strapped again on demand. > But it will likely cause unexpected behavior. IMHO the biggest unknown > is if you will be caught by or adversely effected by said unknown. > > Seeing as how we're talking Linux, Gentoo in specific, you are likely > power users and configure your systems the way that /you/ want them to > be. So, by all means, do what you want. > > I just want to give you some data so that you can make an informed > decision. It's all a question of where you want to go. And having at least a minimum set of guarantees is important here. Otherwise no one is able to setup a system the way they want. Because if semantics change later you will upset one or another person. One example of this is having /usr split and / as early boot-environment: It never gave that guarantee due to dynamic linking (it could not) which led to inventions like initramfs. -- Regards, Kai Replies to list-only preferred.
