Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
> 2012/6/1 Goswin von Brederlow wrote:
> > So tmpfs would basically never be used despite the benefits.
>
> Well, nobody named the benefits yet.
- You could mount your mail spool there, and make things go blazingly
fast [1]
- It speeds things up, especially on systems with loads of RAM and no
swapspace: whenever there's a possibility of disk access, no matter
how remote, you risk slowing things down due to that disk access.
Reducing disk access for things that don't need to be stored forever
is *good*.
- anything which reduces the number of possible disk accesses is good
for people using SSDs (I have a laptop with SSD, and no swap, and love
tmpfs for precisely that reason).
- In the (on laptops and desktops) fairly common
"one-partition-for-everything" set-up, there's no risk of a runaway
process eating up your diskspace with huge files in /tmp and therefore
making it impossible for syslogd to write anything to disk anymore so
you can figure out what the f*** happened
- It makes for an interesting "I need to compile something quickly just
to test something out" area, where it doesn't matter if you forget to
clean up after the fact (yes, this is a bit of an abuse of /tmp; never
the less, I find myself doing such things in /tmp fairly often now
that /tmp is a tmpfs)
- it's called *tmp*fs for a reason (no, that's not a benefit. Yes,
that's an argument in favour)
- There's no danger of a symlink attack or similar with things like
tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
system, and /tmp is clean again, no matter what was there before. This
is more than just a convenience.
[1] As demonstrated on FreeBSD in
<http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20041101/msg00145.html>.
No, I'm not being serious.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: