Re: swap and /tmp

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.

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 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...

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.

I am not sure if this is a problem now, iirc, Debian developers have now
expect volatile behaviour of /var/run

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.

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.

--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Quantcast