On Sat, Nov 12, 2011 at 10:24:00PM +0100, Bastien ROUCARIES wrote:
Recently debian put /tmp under tmpfs.
Even if it increase reponsivness under desktop, it ruin completly
sciene and imaging software that do some off loading on /tmp.
For instance using gscan2pdf on 60pages document create more than 1.2G
of image file under /tmp and crash du to missing space.
What are the solution for this kind of problem ?
As mentioned elsewhere in this thread, this is discussed in detail
in #630615.
As touched on in the bug report, I think that being able to store
1.2GiB on /tmp is an unrealistic expectation. To qualify, I mean
to expect that to work *by default*. If you want to store such
large amounts of data, you will need to configure your system to
handle that, either by:
- provisioning of more swap and raising of the TMP_SIZE limit.
- disabling RAMTMP and using a disc-backed filesystem (either the
rootfs or dedicated /tmp mount).
Again, as mentioned in the report, due to the wide variation in
disc partitioning, filesystem utilisation and RAM capacity between
systems, we don't currently make *any* guarantees regarding a
minimum amount of space available in /tmp, when using a disc-backed
/tmp. If the rootfs fills up, /tmp will cease to allow creation of
new files. When using tmpfs, we do at least make a minimum
guarantee of having a certain amount of storage available (which
might albeit be used by other users).
I'm not sure that I can really add more at this point than which
was already included in the bug report. As a general rule, I think
it's fair to say that if you want to *guarantee* the availability of
that much storage, the defaults will not typically be sufficient.a But
the defaults are just defaults--you are free to configure your system
to satisfy your needs as you see fit.
Regards,
Roger