On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
> Again.. tmpfs is restricted to half the RAM size by default. You can't
> store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have already pointed out some time ago, isn't a bizarre situation
that as an application developer I can either use malloc() and store things
up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
things up to RAM/2 (lets' say 4/2=2GB)?
Once upon a time you used to use files to go *beyond* RAM limits.
And the answer to this objection is....? move to /var/tmp.
So patch everything (and good luck with closed source stuff).
An application (closed source or not) that plans to store non-trivial
amounts of data somewhere should have a mechanism/config option to let the
user specify where to store that data. Simply hoping that you can dump X
gigabytes of data in some hard-coded place is not a good idea.
Wouldn't have been more reasonable to create a /ramtmp and patch
the applications? (this would have just been "patched for speed", not
"patched for correctness" as the sort case).
Hey, wait, we already have /dev/shm. So we just had to patch
the applications (if anyone cares).
That way *every* application would have to be patched. Using /var/tmp is
only required for a small number of apps that actually have more specific
needs regarding the data they intend to put there.
Indeed in many cases it might be better for an application to actually
manage the "temporary-ness" of the file(s) in question themselves and
store/manage them in /var/lib/<app> instead.