On Sun, Nov 13, 2011 at 9:50 AM, Josselin Mouette <j...@debian.org> wrote: > 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.
Yes it the problem file bigger than memory. >> 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. Ok could we made some policy about /tmp use ? Like do not create file above 10M ? And fill RC bug if the apps do this ? $HOME is not really nice but it could work. I have a tmp dir under my home directry and some script to clean up at every log on. Could we agree to mass report bug on this issue? Bastien > -- > .''`. Josselin Mouette > : :' : > `. `' > `- > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaa20camtusxfn1p6xz0p5fodn7y5jwh1csaz2tb7aj...@mail.gmail.com
