| 1 |
Am Thu, 08 Feb 2018 16:42:23 -0700 schrieb Grant Taylor: |
| 2 |
|
| 3 |
> On 02/08/2018 03:32 PM, gevisz wrote: |
| 4 |
>> In this case it would be nice to hear a reason. |
| 5 |
> |
| 6 |
> I think the reason probably goes back a number of years. When /tmp was |
| 7 |
> made volatile (ram / swap backed) there was a need for non-volatile temp |
| 8 |
> space. Thus, /var/tmp was created as non-volatile specifically for the |
| 9 |
> purpose to of surviving across reboots. (At least that's my |
| 10 |
> understanding.) |
| 11 |
|
| 12 |
I don't think this is the reason. Both directories have been there since |
| 13 |
ages, long before someone even considered putting that into ram disks. |
| 14 |
Historically, there would even be /usr/tmp. |
| 15 |
|
| 16 |
The point here is that /var is "variable" data in contrast to "read-only" |
| 17 |
data on the other partitions. This makes /var a candidate for persistent |
| 18 |
OS-state. You could simply keep / and /usr on volatile storage (or even |
| 19 |
read-only storage) and all your variable, non-volatile data would be in |
| 20 |
/var. |
| 21 |
|
| 22 |
Having /tmp on tmpfs is then a logical consequence of this because / |
| 23 |
could be read-only. Also, /etc should be symlinked to /var/etc to enable |
| 24 |
and keep configuration changes over reboots, although this could also be |
| 25 |
populated by a boot-strapping process (e.g., IP configuration). |
| 26 |
|
| 27 |
This is especially interesting for container-based, dynamic cloud servers |
| 28 |
which would spawn and disappear on demand, you just need to keep the non- |
| 29 |
volatile state directory /var. Usually, such systems start with an empty |
| 30 |
/etc directory which is populated by a boot-strapping process. |
| 31 |
|
| 32 |
Following that idea, /var/tmp should also be non-volatile. |
| 33 |
|
| 34 |
Bringing this idea further forward, everything related to the OS-image |
| 35 |
should move to /usr (catchword "usrmerge"), and then / which contains |
| 36 |
/var and /etc could be writeable and non-volatile, /usr would contain |
| 37 |
boot-strapping configuration and be read-only, /etc would be populated on |
| 38 |
first boot. The idea of /tmp on tmpfs is just kept here. |
| 39 |
|
| 40 |
The idea of having everything boot-related in / doesn't apply since years |
| 41 |
(and wasn't the original idea anyways). These days, initramfs takes this |
| 42 |
role and /usr takes the role of /, and /home already took the role of /usr |
| 43 |
(that's why it's called /usr, it was user data in early unix). The |
| 44 |
splitting we have today is a result of size-constraints of early systems |
| 45 |
when the OS no longer fit one disk, when / became the early boot- |
| 46 |
environment (initramfs today). Today, the OS uses dynamic linking when |
| 47 |
most of it was statically linked in the early day, and thus there are |
| 48 |
dependencies between / and /usr that cannot be untangled easily, and |
| 49 |
renders the split for early boot-environments difficult to maintain. So |
| 50 |
everything might easily move to /usr and / can become a non-volatile |
| 51 |
state partition containing /var and /etc. And early boot lives in |
| 52 |
initramfs (to setup /usr mount). |
| 53 |
|
| 54 |
|
| 55 |
>> That's why I have asked if it does not harm. |
| 56 |
> |
| 57 |
> I don't think it will actually harm the Operating System. Some daemons |
| 58 |
> may get cross if files they know that they created no longer exist after |
| 59 |
> a reboot. |
| 60 |
> |
| 61 |
> Though things should gracefully handle the absence of such files and |
| 62 |
> re-create them. |
| 63 |
> |
| 64 |
> The biggest Ah Ha moment I ever saw someone have was when they spent |
| 65 |
> more than an hour getting a Solaris patch cluster to the machine, |
| 66 |
> extracted it to /tmp, rebooted into single user mode, and went where the |
| 67 |
> $&#* is the patch cluster? That's when someone more experienced asked |
| 68 |
> them where they put it and got to educate them on the error of their |
| 69 |
> ways. |
| 70 |
> |
| 71 |
> I doubt that having /var/tmp be volatile will actually break things. |
| 72 |
|
| 73 |
Usually not but it might be interesting to have it non-volatile in the |
| 74 |
scenario I described above: Something which survives the complete machine |
| 75 |
being discarded (except it's state) and then later boot-strapped again on |
| 76 |
demand. |
| 77 |
|
| 78 |
|
| 79 |
> But it will likely cause unexpected behavior. IMHO the biggest unknown |
| 80 |
> is if you will be caught by or adversely effected by said unknown. |
| 81 |
> |
| 82 |
> Seeing as how we're talking Linux, Gentoo in specific, you are likely |
| 83 |
> power users and configure your systems the way that /you/ want them to |
| 84 |
> be. So, by all means, do what you want. |
| 85 |
> |
| 86 |
> I just want to give you some data so that you can make an informed |
| 87 |
> decision. |
| 88 |
|
| 89 |
It's all a question of where you want to go. And having at least a |
| 90 |
minimum set of guarantees is important here. Otherwise no one is able to |
| 91 |
setup a system the way they want. Because if semantics change later you |
| 92 |
will upset one or another person. |
| 93 |
|
| 94 |
One example of this is having /usr split and / as early boot-environment: |
| 95 |
It never gave that guarantee due to dynamic linking (it could not) which |
| 96 |
led to inventions like initramfs. |
| 97 |
|
| 98 |
|
| 99 |
-- |
| 100 |
Regards, |
| 101 |
Kai |
| 102 |
|
| 103 |
Replies to list-only preferred. |
Archives