Date: Sun, 1 Apr 2012 09:40:25 -0400 From: Gary Palmer <gpalmer@freebsd.org> To: deeptech71@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Using TMPFS for /tmp and /var/run? Message-ID: <20120401134025.GC76647@in-addr.com> In-Reply-To: <4F765682.5040707@gmail.com> References: <4F746F1E.6090702@mail.zedat.fu-berlin.de> <4F74BCE8.2030802@vangyzen.net> <CACM2%2B-7Ahn6J=CTASe0g48%2BSD2vvLVd_hG3DRZmvO31QszG5Xw@mail.gmail.com> <20120330.151848.41706133.sthaug@nethelp.no> <CADGWnjXj5W_UCHPExNjxHgq3EZHP1GwocnK4kOHLch5y3gNG0A@mail.gmail.com> <4F765682.5040707@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 31, 2012 at 02:57:38AM +0200, deeptech71@gmail.com wrote: > C. P. Ghost wrote: > >Not clearing /tmp on reboot has been > >the norm for way too long and it is too late to change now. > > We either evolve or be in a stalemate forever. > > >It's not just POLA, it also involves deleting data of unaware > >users, and that should be avoided. > > Mounting on a directory (/tmp) does *not* clear that directory, so > automatic data loss will not occur. > > > Adrian Chadd wrote: > > One of those reasons people stick/stuck with BSD is that we don't go > > and change this stuff so quickly. > > Yes, it would be a total of ~20 years before we finally decided to switch > to using TMPFS for /tmp. > > > > Changes that potentially break the POLA can be categorized; a change has a > combination of the following properties: > (1) the change fixes a bug (ie., the change is about something that should > have been different in the first place, eg., the change fixes the > misspelling of a command name) > (2) the change can be prepared for (ie., enough time is given for the user > base to slowly switch the new method of doing things) > (3) the change is evolutional (ie., the change is based on a decision to > yield a net benefit (not necessarily a benefit in all cases)) > (4) the change has priorly been given room (ie., is expectable as defined > by standards and the documentation) > > The TMPFS-for-/tmp change obviously falls into (4), and surely into (3). > With the support of UPDATING entries, release notifications, and perhaps > announcements, the change also falls into (2). Furthermore, using TMPFS for > /tmp is analogous to adding assert()s to code. Noone is really breaking the > POLA that much. > The TMPFS-for-/var/run should not even bother anyone. Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? Has consideration been paid to low-memory systems? I think this discussion is fast becoming a bikeshed and distracting people from real work on improving FreeBSD. Without clear advantages from a switch to tmpfs(5) or md(4) non-persistent storage the default should stay the same, especially on release branches. If people want that behaviour, the switches are already there and while I may have missed it, I don't believe there hasn't yet been suitable justification for making the change. Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120401134025.GC76647>