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

Re: /tmp as tmpfs and consequence for imaging software

I would like to agree with Roger in his response.

"simple well knowns, non-obstructing, no-new-bugsy, non-kernel-hack dep., ...". If linux allows "a single project need to break "softwares already prepared and working" it is not survivable to maintain and ignores justice in legacy.

(from response mail)
>> "you don't have to do umpteen metadata writes (including barriers!)" ~ "if there are multiple concurrent writers of large files". This is just making excuses "gain a feature". Many such excuses can also be made for the current /tmp system. Software can memory map if supported, the kernel does so otherwise IF NEED BE.

(btw i've read most filesystem & blocking code: not true). Blocking options change between hardware and kernel version to version (hopefully optional), sometimes it's just duplicity.

I have a few /tmp and /dev/tmpfs configurations by arising of situation. But the defaults should simply work for any boot disk and be [opensuse] (deeply compatible yet high unix efficient). Switching to /dev/tmpfs would screw me for no reason, I'm about sure.

Roger Leigh wrote:
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.


Reply to: