[Pkg-sysvinit-devel] Bug#585543: initscripts: provide RAMTMP and RAMVARTMP similar to RAMRUN/RAMLOCK

[Christoph Anton Mitterer]

Package: initscripts
Version: 2.88dsf-7
Severity: wishlist


Hi friends.

Again, referring to the more and more common SSDs, it would be really nice to
have in addition to RAMRUN/RAMLOCK, tha same thingy for /tmp and even for
/var/tmp.
Of course again with corresponding TMP_SIZE/VARTMP_SIZE options in /etc/defaults/tmpfs.

I guess it's quite clear that it makes sense for /tmp.


/var/tmp is considered to be "more persistent" than /tmp and I must admit, that I have
no idea if and how Debian handles /var/tmp at the moment (mening are there any cleanups
at all?).

Nevertheless, I think FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE)
is a little bit unlogical regarding /var/tmp.
It says "Files and directories located in /var/tmp must not be deleted when the system
is booted." but on the same line "Although data stored in /var/tmp is typically deleted
in a site-specific manner, it is recommended that deletions occur at a less frequent
interval than /tmp."

Having both is obviously impossible, as one never knows, whether an application would
require the persistance right now/for the following reboot.

So what I'd suggest is, make it configurable to have /var/tmp at tmpfs just as /tmp
but give some big warning in the documentation, that this is more or less incompatible
with FHS and possibly dangerous for applications relying on it.


The nice thingy about supporting RAM{RUN,LOCK,TMP,VARTMP} would be, that future
versions of the debian installer could automatically detect whether /tmp and/or
/var/run and/or /var/lock is going to be on an SSD, and suggest the user to
automatically enable those options :)


Cheers,
Chris.