Re: swap and /tmp
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
Reply to: