[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: