/tmp and /var/tmp

Posted Mar 30, 2011 19:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: /tmp and /var/tmp by dmarti
Parent article: Introducing /run

In a couple of cases I've used /tmp to hold several hundred gigabytes of data. I don't think tmpfs can cope with such usage.

/tmp and /var/tmp

Posted Mar 30, 2011 23:36 UTC (Wed) by roblucid (guest, #48964) [Link] (12 responses)

100's of GB in /tmp, that's GUI error (Gross User Incompetence) or just bad taste if you prefer.

/tmp is meant to be small, fast and ephemeral, with a purge across a reboot being acceptable or clean out if the file's not accessed for a day or so.

Of course if you *must* have a /tmp/humungeous then nothing to stop a mount under /tmp, or a symlink to fallow area, for you to fill.

/tmp and /var/tmp

Posted Mar 31, 2011 2:20 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

1 - tmp is not meant to be small, it is meant to be temporary, it is only broken unixes which used special filessytems for tmp which could not support large temporary files, which do exist

2 - on Linux, at least (this is LWN) there is little advantage of tmpfs over a normal filesystem for tmp. Linux's filesystem layer is quite good about not needing to send out data to disk when unnecessary (a truly shortlived file may never see the disk at all), and for the longer lived or large file case you get perfectly reasonable behavior as well

/tmp and /var/tmp

Posted Mar 31, 2011 21:36 UTC (Thu) by jond (subscriber, #37669) [Link]

Absolutely. And I've seen veteran UNIX sysadmins dump e.g. Oracle install data in /tmp on solaris systems, which *do* use tmpfs for /tmp, thus knackering the box... it's expected to be able to do it, even when it isn't a good idea :-)

/tmp and /var/tmp

Posted Mar 31, 2011 12:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

That 100GB were for intermediate data in video processing. They are put in /tmp by default.

And why shouldn't they?

/tmp and /var/tmp

Posted Mar 31, 2011 17:00 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (7 responses)

Because /tmp is supposed to be off-limits for users, it being the place for system temporaries?

/tmp and /var/tmp

Posted Mar 31, 2011 17:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Whiskey Tango Foxtrot?

Sticky bit for directories was specifically invented for the world-writable /tmp. Also, where should user processes store their temporary data (for example, if a user opens a .tgz file in Nautilus)?

/home might be on a slow NFS link, so it's an incorrect answer.

/tmp and /var/tmp

Posted Mar 31, 2011 19:43 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

The user temporary files are supposed to go in /var/tmp

/tmp and /var/tmp

Posted Mar 31, 2011 19:56 UTC (Thu) by martinfick (subscriber, #4455) [Link]

Where do you get that rationale from? The FHS does not think so:

/tmp : Temporary files Purpose

The /tmp directory must be made available for programs that require temporary files. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. Tip Rationale

IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.

/var/tmp : Temporary files preserved between system reboots Purpose

The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.

/tmp and /var/tmp

Posted Apr 1, 2011 15:55 UTC (Fri) by k8to (guest, #15413) [Link]

If /tmp was not for users, then the sticky bit would not have been added to unix to specifically support /tmp for users.

/tmp and /var/tmp

Posted Apr 1, 2011 17:30 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

Uh, GCC dumps stuff in /tmp if you don't specify -pipe. Is the compiler something normal users shouldn't run now?

(FWIW I too have never heard this before. /tmp is transient: /var/tmp is not. That's all.)

/tmp and /var/tmp

Posted Apr 2, 2011 15:15 UTC (Sat) by vonbrand (subscriber, #4458) [Link] (1 responses)

The compiler is not a "normal user", it is a system program (run by normal users under their UID, thus the sticky bit on /tmp).

/tmp and /var/tmp

Posted Apr 2, 2011 17:11 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

1) I notice you're still not bothering to provide a citation for "/tmp is for the system and off-limits to ordinary applications".

2) In my world, the C compiler is an ordinary user application, so should use filesystems in the manner appropriate to ordinary user applications.

/tmp and /var/tmp

Posted Mar 31, 2011 13:43 UTC (Thu) by jschrod (subscriber, #1646) [Link]

GUI judgement is gross arrogance, or just bad human judgement if you prefer.

In my world, if one uses applications that place there temporary files in /tmp and produce several GBs of them, it is surely *not* gross user incompetence if one decides not to spend one's time trying to detect how each and every of these apps can be persuaded to place their temporary files somewhere else. Instead one just gives /tmp more space. In my world, this is called pragmatic. Maybe you've heard of that term, but with your quick judgement of others, there is some doubt about that.

Maybe that information is new, but setting aside a few hundred GBs of disk space for /tmp is not really a problem with today's disk sizes. The 90s are over, really. And in no way that stops /tmp from being purged at reboot time.

Btw, if I would really clean out every day all /tmp files not accessed in a day, my desktop would not function any more. /tmp cleaning while user sessions are active needs more care than such coarse treatments; it needs blacklists, and most often also longer retention times.

/tmp and /var/tmp

Posted Apr 1, 2011 21:23 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

tmpfs can cope with huge amounts of data no problem.

BUT it *defaults* to "half available ram".

I got bitten by this when I put /var/tmp into tmpfs on gentoo, and then wondered why OpenOffice wouldn't compile :-)

I always set swap to (at least) twice available ram, which on my system is 32Gb (kernel 2.4 proved that the "twice ram" rule was NOT obsolete, and nobody has yet given me any reason to believe things have changed since then).

I think my tmpfs partitions are all set to about 10-16Gb in size. They're all fine. If you use enough space on the partition, it will simply spill into swap.

Cheers,
Wol

/tmp and /var/tmp

Posted Apr 2, 2011 14:28 UTC (Sat) by dtlin (subscriber, #36537) [Link] (2 responses)

Spinning disk filesystems try hard to keep data contiguous; swap does a relatively poorer job of it. So if you're constantly swapping your tmpfs, it's likely slower than if you just used a dedicated filesystem.

/tmp and /var/tmp

Posted Apr 2, 2011 23:05 UTC (Sat) by Wol (subscriber, #4433) [Link]

:-)

But with 8Gb of ram, my system hardly ever swaps, even with /tmp as tmpfs.

However, portage occasionally chews up large amounts of temporary space. Compiling OOo, it recommends you have 10Gb of disk space free in /var/tmp/portage. Chances are, if anything ever gets flushed to swap, it'll never be wanted again, which is why I stick it in tmpfs rather than have it chew up real space in a real partition.

And with 1.5Tb disk across two drives, why should I care about losing 32Gb to swap? :-) It's there if it's needed - which it hardly ever is.

Cheers,
Wol

You 100% right - and still wrong :-)

Posted Apr 3, 2011 14:59 UTC (Sun) by khim (subscriber, #9252) [Link]

Yes, if you're constantly swapping your tmpfs you are slowing everything down. But more often then not it's not the case. 80/20> rules is valid for temporary files too. Most temporary files are accessed rarely, but few are accessed constantly - and they don't ever hit the disk with tmpfs. I know that incremental Chromium build is faster on tmpfs then on real fs if you have beefy system (16GB of RAM, 100GB of temporary files in tmpfs).