[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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