Re: Moving /tmp to tmpfs makes it useless
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> What's a temporary file? Really, why would applications temporarily store
> its data in a file? They do that to *free some memory*. Placing those files
> back to memory renders the whole process of writing the file useless.
> If the files are small and can stay in memory why would application save it
> to file?
how, or why, would an application know that I have enough memory to keep
it all there, while you don't? The fail-safe way to code an application
without copious special-casing is to use a file and then let the systems
administrator decide what to do with it. If the application insists on
keeping everything in memory, the systems administrator can, at best,
add more swap, but if it uses a file, he can decide either way.
> Since it's only reasonable to store large data sets in temporary files,
> standard sets no size limits for these files. So if application's author
> had actually read FHS he should expect these directories to handle
> large files.
It's not, see below. Also, most of the time, /tmp goes into / (on
smaller systems), and is thus typically *very* much limited in space.
Granted, the user can relocate /tmp to another place later, once he
became aware of the limit...
Running out of space in /tmp should be a one-time event for any system
that one installs, since thereafter, /tmp will have enough space
configured for the desired purposes. No need to make it non-tmpfs.
> Who uses /tmp
> Let's check the real world and see what applications actually use /tmp.
> And the most important thing: file managers, browsers, image editors,
> cd burners — these are not some rare scientific stuff, but a common
> programs, that most people use every day. Putting them on a small tmpfs
> will break them. Putting them on large tmpfs may slow down or freeze
> the system due to heavy swapping.
I wanted to make the argument that php uses /tmp as the session save
path (it used to be there), but discovered, that someone has
re-configured that to now be in /var/lib/php5, so I'd say put that on a
tmpfs as well. Lots of small files with frequent accesses... whoever
wants those on a real disk?!?
> is to extend partitioner with a new option "Configure tmpfs partitions".
> That option should allow to mount anything as tmpfs (not just /tmp, but
> also /var/run, /media, /opt or whatever the user might want). It would be
> nice to have the `size` option there as well.
Having /var/run on a tmpfs may be a good idea, though.
> Q: I extremely care about my / fs and want to use it as rarely as possible.
> A: There're a lot of options:
> * symlink or mount-bind /tmp to i.e. /home/tmp
> * have /tmp on a separate partition (common and probably best solution)
> * you hate partitions? make /home/tmp_ext3fs.img and loop-mount it.
> That would solve your problem without making your system unstable because
> of high memory usage, or break programs because of no free space in /tmp.
It used to be /usr/tmp in olden days, just to have that out of / and
give it more space at the same time, too. One might also consider to
then merge /tmp with /var/tmp, eg. by way of symlinking them, as the one
who is strapped on memory, might as well be strapped on Internet
bandwidth to download that unfinished ISO that blew up his /tmp on
tmpfs, then re-getting the rest of it after rebooting...
> Q: /tmp on tmpfs increases apps performance.
> A: What apps? Real apps don't write files during performance-critical
> operations. Even if they do, they write large files. And large files are
Eg. web application's session data very frequently goes there, and/or
the sysadmin wants it to go onto a tmpfs.
> Q: gcc writes small files in /tmp
> A: usually it does not, especially when used with -pipe option
Changing all (generated?) Makefiles floating around out there, and
getting the changes committed upstream to actually benefit from that is
easier than using a tmpfs, of course.
> That's it. Thanks for reading.
> PS: should I had filled this as a bugreport?
I request that the bug be tagged wontfix.