Re: Moving /tmp to tmpfs is fine
2012/5/27 Ben Hutchings wrote:
>> then /tmp using tmpfs *will* lead to issues that many wont understand.
> As will /tmp on a small root partition.
> As will a small dedicated /tmp partition.
True. But debian does not have small root partition *by default*. And it
does not install with a small dedicated /tmp partition *by default* as
well. Then why does it installs with /tmp on tmpfs *by default*?
Users don't like thinking about partitions size, and they don't care much
about fragmentation or number of I/O. The most common configuration would
probably be entire system on a single partition, optionally in dual-boot
with other OSes (i.e. there could be other FAT/NTFS partitions there).
TMPDIR on a root partition is the best and only option there. It's good
for large files, isn't limited by memory size, don't cause system swapping
and is as fast as cached local storage can be.
> A shared /tmp also results in various security problems
Agree, having a shared /tmp may sometimes be an interesting idea, but it
is also bad to have it *by default*
> We should be thinking about implementing per-user temporary directories
There're a lot of other places where TMPDIR can be. Let's consider all of
them. Where else we can put tmp directory:
1. /tmp (TMPDIR on a root partition)
Good for systems of regular users. But bad for systems with read-only or
small root partition (rare, *never* happens in default install, but still
happens).
2. /home/tmp (TMPDIR on a home partition)
Good for systems that want users to obey /home quotas or having read-only
root. But bad for shared (NFS) /home (not that rare, but still possible).
Also bad for users with separate /home partition, who care about their
data: when / dies you can recover data from your /home, and tmp on /home
will just increase chances of /home death.
3. /home/USER/tmp
Same as above, but in addition it's also bad for ssh servers where users
share files over /tmp directory (they just don't have a choice there).
4. /bin/tmp
Not really useful. But if we name it /bin/trash... hey, we have a trash
in a bin! ;)
5. /var/tmp
Oh, we already have that.
6. /tmp on a separate partition
Common for servers, eats no RAM, have all the limits/quotas working.
But needs some brain work and complex in resizing, so it's bad for regular
users.
7. /OTHERDIR/tmp
Same as above, if OTHERDIR on a separate partition. And same as #1 if
OTHERDIR is on a root partition.
8. /tmp on tmpfs
Bad for large files. Bad for low-memory systems (i.e. routers, cheap
netbooks, tablet PCs, mobiles), which are more and more common nowadays.
But still the only option for systems that have slow (network-mounted)
/home and /var partitions, and read-only root, and need to work FAST with
a lot of small files (I've never seen such case myself, but it is still
possible anyway).
As you can see each of them have problems. So the one, that causes the
fewest problems in default setup should be the default. Isn't it?
People, with some unusual installations are customizing their defaults
anyway, so they can change /tmp location themselves as well (i.e. do a
`mount --bind /tmp /home/tmp` for read-only setup).
> We should be thinking about implementing per-user temporary directories
> and making sure that programs respect $TMPDIR.
That's not enough. Applications need a special temporary directory. The
one that is cleaned on reboot. Of course apps should clean their files
themselves, but they should not worry about cleaning files after i.e.
an unexpected power outage. That's what /tmp is good for.
So if you click on a few files in firefox and then your lights turn off,
on next reboot firefox should not look through $TMPDIR and delete files
that were created by it on last boot. Of course we can write an
additional init-script that will automatically clean all user-specific
TMPDIRs, it would have to be a very smart script, it should work for
local /home as well as i.e. NFS /home, and must not clean all the
directories when one of machines reboots. It should probably support
things like LDAP, or unusual home-directories like /var/guest. It will
surely require a lot of work and probably will cause a lot of problems.
But it is possible... I don't see what for, but it's possible.
Or maybe we can just leave /tmp as a part of / partition *by default*,
since by default it's large enough, cleaned on boot, works for all
programs and causes no worries? ;)
> I'm not sure whether that's compatible with historical use of /tmp by
> the X window system.)
I guess it's not. Because when X starts you don't know what user will log
in there.
PS: see also idea about on-demand mount of /tmp to tmpfs for systems
with disk space check. It would make the defaults working even for small
and read-only root fs.
--
Serge
Reply to: