From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DA94C1382C5 for ; Sat, 10 Feb 2018 18:57:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03571E0A5A; Sat, 10 Feb 2018 18:57:07 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7A49EE0938 for ; Sat, 10 Feb 2018 18:57:06 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ekaIF-0006wG-LC for gentoo-user@lists.gentoo.org; Sat, 10 Feb 2018 19:54:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Kai Krakow Subject: [gentoo-user] Re: /var/tmp on tmpfs Date: Sat, 10 Feb 2018 19:56:30 +0100 Message-ID: References: <6b002bec-6fc8-8555-defe-878e08f88cd6@spamtrap.tnetconsulting.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.142 (He slipped to Sam a double gin; 01b5bf4 git.gnome.org/pan2) X-Archives-Salt: 0e67197b-7c8d-41b7-b1d1-08751889e485 X-Archives-Hash: 9204771fbc5687582d316f7fdcdeb31e 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.