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

Re: /tmp as tmpfs and consequence for imaging software



Le dimanche 13 novembre 2011 à 09:40 +0100, Bastien ROUCARIES a écrit : 
> No it is not true. Science and imaging software are better to use true
> disk baked file. For instance, if I want ot invert a big matrix they
> are pretty good algorithm that force only some part of the file to be
> keep on disk. They known better than kernel when to put somepart on
> the data on the slow disk.

The application might know better its usage profile, but the kernel
knows better how the actual hardware behaves. This is why there are now
some APIs to give hints to the kernel instead of assume the application
can deal with everything by itself.

> And do not ask user to choose. Imageging software and movie maker
> software have the same requirement than high performance science
> software.

Having to deal with quite a lot of HPC software, I can assure you that
most of such applications do not know how to use disk or memory
correctly. They see considerable speedup when using tmpfs - as soon as
you don’t use it for too large files, of course.

> Now that are the solution ? We could not increase tmpfs over 50% to
> 70% of physical ram without deadlock (OOM and so on). And it is not
> enought for your use. Should we use /var/tmp  ? But it does not fit
> due to "Files and directories located in /var/tmp must not be deleted
> when the system is booted" (FHS). Whereas this kind of software want
> to be non persistant and tru file backed.
> 
> Any suggestion is welcome

In all cases, do not assume /tmp was ever made for such a use case. You
need to locate your data somewhere else. Doing like gimp, which uses
$HOME but allows the user to specify something else, is a good way to
go.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: