On Wed, May 03, 2006 at 11:52:39AM +0200, Matus UHLAR - fantomas wrote: > > Digby Tarvin wrote: > > > I am thinking of using a tmpfs for /tmp, and would be interested > > > to hear any thoughts that others have on this issue. > > On 28.04.06 20:41, Dennis Stosberg wrote: > > I use tmpfs for /tmp on all of my machines and have so far not found > > a good reason why I should not. > > I use this for ages, I was born at Solaris which mounts /tmp on tmpfs since > early 90s, when Solaris 2 came out ;) without problems. I have even used > small ramdisks with 2.2 kernels.
I have now adopted it for my Linux systems, and was pleasantly surprised with the functionality provided. The 'on demand' allocation makes it much more efficent that a statically allocated partition where any space not used for temp files is unavailable for anything else. That, coupled with the ability to set an upper limit to reserve a minimum amount of space for stop leads me to believe there is no real disadvantage. The other bonus is that if I need more tmp space, it is perfectly possible to dynamically and temporarily add extra swap space (eg via a swap file) and then bump up the limit on the tmp filesystem. And of course there is a performance improvement... What puzzles me is that this option is not better documented. The installer for my BSD system makes you explicitly decline during the install process if you don't want it. > The only problem is/was either virtual memory limitation or limitation of > /tmp partition. However, with 128MB of /tmp I don't have problems. > (Last time a problem happened when I downloaded more video files, > temporarily stored to /tmp) I recently had a problem downloading an ISO image using netscape on a SuSE system because it insisted on downloading initially to /tmp regardless of the ultimate final destination - and my 512MB was not quite big enough to hold it, resulting in several irritating last minute aborts... > I also use tmpfs for /var/lock and I've used is for /var/run until problems > raised with some debian packages expecting to have subdirs (with special > privileges) there. I filled up some bugreports and they were solved, but > they re-appeared a few times... It isn't obvious to me why these and any other repositories of volatile information that has no value after a reboot should not be put into directories created in /tmp... > I even contacted FHS people (FHS says that files have to be cleaned upor > reboot on /var/run but it does not clearly says if directories may be > removed too), iirc because of my MySQL bug report. Keeping a 'skeleton' directory in /var which is used to initialise the /tmp filesystem at boot time would be my suggested solution to that problem. It could be used to create a /tmp/run and /tmp/lock, and backward compatability maintained by creating symlinks in /var.... In fact I might try that... > I am not sure if this is a problem now, iirc, Debian developers have now > expect volatile behaviour of /var/run Do you know what their solution was? I imagine it would be tedious to have to modify all applications to check for and dynamically create missing directories... > > > Obviously it would mean that /tmp would be volatile, which sames > > > having to clean it up, but is sometimes annoying if you have grown > > > used to being able to leave things there... > > > > /tmp is volatile by definition. See /etc/init.d/bootclean.sh on your > > Debian system. Other distributions have similar mechanisms. It isn't volatile by default on my old SuSE system, and I don't think Gentoo was either. My BSD was the only other one I recall doing the auto temp cleaning by default. > Solaris 2 and higher also expects /tmp to be completely empty after reboot. > Everything that expect anything to be in /tmp after reboot is broken. Absolutely - it was only user expectation that I was referring to, not programs. If you have a crash with a partition based /tmp, and someone had something valuable there at the critical moment, it can usually be retrieved by booting into single user mode initially. If you were using ramfs, then it is pretty well lost - especially if the crash results in a crash memory dump to swap (as my BSD system does). But overall I find that an acceptible trade-off. Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
