| |||||||||||||
Various notes on /usr unificationVarious notes on /usr unificationPosted Mar 1, 2012 20:42 UTC (Thu) by dskoll (subscriber, #1630)In reply to: Various notes on /usr unification by rgmoore Parent article: Various notes on /usr unification
/ Machine specific, read-only I'm sold. That's a beautiful, clear and logical explanation. Thanks. I guess /var/tmp either has to go or we have to separate the "volatile" filesystems into "volatile-and-likely-to-fit-in-RAM" vs. "volatile-and-possibly-enormous".
(Log in to post comments)
Various notes on /usr unification Posted Mar 1, 2012 21:28 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> I guess /var/tmp either has to go or we have to separate the "volatile" filesystems into "volatile-and-likely-to-fit-in-RAM" vs. "volatile-and-possibly-enormous".
I believe /var/tmp is generally considered to be "stable across reboots", so at least that much would remain consistent. *Old* files may be deleted from /var/tmp, of course, but while files in /tmp are only valid for the life of a single process (and thus can always be deleted after a reboot), files in /var/tmp represent transient data which may nonetheless remain useful well after the process which created it has exited.
Since /var/tmp is defined as stable it's unlikely to be located on a RAM disk, but applications using large temporary files must still be prepared for the possibility of running out of free space.
|
|||||||||||||