Re: /tmp as tmpfs and consequence for imaging software
Roger Leigh <rleigh@codelibre.net> writes:
> 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).
Correct me if I'm wrong but doesn't having a real filesystem for /tmp in
/etc/fstab prevent tmpfs from being mounted there? And wouldn't everyone
expecting to frequently store 1.2GB files in /tmp create such a
filesystem during installation?
Having /tmp on / would quickly degrade performance as the filesystems
free space becomes fragmented over time. So if you end up with a tmpfs
for /tmp on such a system you already did install your systems wrong for
your use case under the old setup. So only suboptimal configurations are
hurt by defaulting to tmpfs. :)
> 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
MfG
Goswin
Reply to: