All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Nix <nix@esperi.org.uk>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	Chris Lightfoot <chris@ex-parrot.com>
Subject: Re: [uml-devel] When /tmp is not tmpfs.
Date: Fri, 25 Nov 2005 14:18:43 -0600	[thread overview]
Message-ID: <200511251418.43866.rob@landley.net> (raw)
In-Reply-To: <87k6ewikte.fsf@amaterasu.srvr.nix>

On Friday 25 November 2005 13:33, Nix wrote:
> On Fri, 25 Nov 2005, Rob Landley uttered the following:
> > A) mlock would be a bad thing.  Not only is it a trivial DOS waiting to
> > happen but I like the UML physmem being swapped out under memory
> > pressure.  I just don't want uselessly writing it to disk over and over
> > in the absence of any memory pressure whatosever to consume all I/O
> > bandwidth to no purpose, which is the effect when it's not on tmpfs.
>
> Maybe this is a stupid question, but... why do *any* systems other than
> extremely memory-constrained ones not mount tmpfs on /tmp? It seems to
> me to have numerous advantages and no disadvantages.

Actually, I consider the fact the OOM killer doesn't delete files out of tmpfs 
mounts to be a potential disadvantage in this context.

Using /tmp for anything has been kind of discouraged for a while, because 
throwing any insufficiently randomized filename in there is a security hole 
waiting to happen.  By the time tmpfs was widely available as something you 
might mount on /tmp, the use of /tmp had been largely replaced with things 
like the ~/.kde directory or /var/spool/appdir with ownership and permissions 
enforced.

Most of the remaining uses of /tmp are actually for things like named sockets 
(where tmpfs really doesn't help at all), or for tiny little files (like all 
the mcop crap) that on a different day would live under /var.  It's used for 
inter-process communications, not for temporary storage space.  Long ago 
things like vi would create temporary files in /tmp, but these days it uses .
${filename}.swp in the same directory as the file being edited.  (As a matter 
of fact, there's even a /var/tmp that konqueror recently started storing its 
cache in.  It used to be in ~/.kde.  So there isn't just _one_ tmp directory; 
if you try to tmpfs mount your /tmp than you need to do more than one.)

I suspect that the real reason nobody mounts tmpfs on /tmp is that nobody 
_bothers_.  Nobody in their right mind puts anything big under /tmp, the few 
remaining uses are largely IPC between different users on the same machine, 
and even X11 has mostly moved away from that.  Things like postfix and cups 
use subdirectories under /var/spool that aren't world readable.

Keep in mind that tmpfs used to be shmfs, and what it's good at is providing 
shared memory.  What UML really _wants_ is shared memory, which has 
traditionally been available through /dev/shm.  Insisting that /tmp behave 
like /dev/shm because otherwise what you get doesn't behave like shared 
memory A) doesn't make make a whole lot of sense, B) doesn't match existing 
practice.

> In fact, even when you're memory-constrained, if you *have* diskspace that
> you could spend on /tmp, you can swap to it instead, and spend the space
> on virtual memory when you're not spending it on /tmp.

"can" doesn't mean "should".  Yes you can make a 10 gigabyte swap partition, 
but most people actively don't want one because if your system ever winds up 
using more than about twice as much swap space as it has physical memory, 
it's likely that the amount of swap thrashing you're doing is getting 
pathological.  Having a runaway app have to churn through 10 gigabytes of 
swap space before the OOM killer terminates it can turn 30 seconds of 
paralysis into 10 minutes.  Not an improvement.

Also, although it's pretty common to have 10 gigabytes of spare disk space on 
a modern laptop, it is _not_ common to have 10 gigabytes of spare swap space, 
and that's for a reason.  Extra space in your filesystem can be used for all 
sorts of things.  Extra swap space is normally wasted.

So having tmp just be a normal directory isn't really that bad of a choice.  
It normally manifests no downsides whatsoever.  And encouraging people to 
use /tmp is considered a security hole.

> So, er, why?

/dev/shm appears to be is the widely available tmpfs mount, because its 
purpose is to provide shared memory.  It is not and never has been the 
purpose of /tmp to provide shared memory.

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2005-11-25 20:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-24 12:11 [uml-devel] When /tmp is not tmpfs Rob Landley
2005-11-24 20:40 ` Blaisorblade
2005-11-25  8:26   ` Rob Landley
2005-11-25  9:55 ` Jeff Dike
2005-11-25  9:48   ` Rob Landley
2005-11-25 10:52     ` Rob Landley
2005-11-25 11:26       ` Rob Landley
2005-11-25 14:56 ` Nix
2005-11-25 15:03   ` Chris Lightfoot
2005-11-25 15:36     ` Nix
2005-11-25 16:03     ` Rob Landley
2005-11-25 19:33       ` Nix
2005-11-25 20:18         ` Rob Landley [this message]
2005-11-25 21:04           ` Nix
2005-11-25 22:31             ` Rob Landley
2005-11-27 16:48               ` Blaisorblade
2005-11-27 18:17               ` Nix
2005-11-27 19:24                 ` Rob Landley
2005-11-25 23:33             ` Blaisorblade
2005-11-26  2:12               ` Nix
2005-11-26 11:47                 ` Rob Landley
2005-11-27 17:37                   ` Blaisorblade
2005-11-27 18:35                     ` Nix
2005-11-27 19:10                       ` Blaisorblade
2005-11-27 19:43                         ` Nix
2005-11-27 21:21                       ` Rob Landley
2005-11-27 18:59                     ` Rob Landley
2005-11-27 19:20                       ` Blaisorblade
2005-11-27 21:41                         ` Rob Landley
2005-11-29 16:52                           ` Blaisorblade
2005-11-27 18:31                   ` Nix
2005-11-28  1:07                     ` Rob Landley
2005-11-29 16:08                       ` Blaisorblade
2005-11-29 19:38                         ` Rob Landley
2005-11-26 10:44               ` Rob Landley
2005-11-27 16:38                 ` Blaisorblade
2005-11-27 18:49                   ` Nix
2005-11-27 21:25                     ` Rob Landley
2005-11-27 17:10                 ` Blaisorblade
2005-11-25 23:46           ` Chris Lightfoot
2005-11-26 10:03             ` Rob Landley
2005-11-26 10:15               ` Chris Lightfoot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511251418.43866.rob@landley.net \
    --to=rob@landley.net \
    --cc=chris@ex-parrot.com \
    --cc=nix@esperi.org.uk \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.