Re: Summary: Moving /tmp to tmpfs makes it useless
On Fri, 22 Jun 2012, Andrei POPESCU wrote:
> On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
> > Fine let’s talk. Why can’t we find a compromise? Additional to our
> > disk /tmp we create a /ramtmp (so the name suggests that this tmp is
> > a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
> > release notes should mention it. And those who wish can patch their
> > programs to use the ramdisk if they think their program uses only
> > small temporary files. In this way, we get some data and experience.
> > And we have both worlds. /tmp on disk for even large temporary files
> > and /ramtmp as fast ramdisk.
>
> Why not use /run instead?
Feel free to add a *mountpoint* at /run/tmp and provide a second tmpfs
there[1]. But if you do that, we'd have /tmp, /run/tmp, and /var/tmp so to
me it just looks like a mess...
Well, /var/tmp is always disk-backed and it is supposed to last across
reboots, and files there should last for a while before any automated
cleaning. It is written nowhere that you can leave large files in there,
though, but it is not supposed to be too space-constrained.
/run/tmp might be defined from the get go to be tmpfs, and not some place
you should expect to be able to abuse (i.e. can't be automatically used to
unpack large amounts of crap, host the tile cache of a pixel editor or the
browser's cache, etc). What good would it do, I don't know: you'd need to
set TMPDIR=/run/tmp to use it anyway, so might as well just do it to /tmp...
[1] Should you fill /run or cause a filename colision, very bad things
can happen. You don't use /var/lock and /var/run as a general dumping
ground for random crap, and the same rule applies to /run.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: