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. Regards, Dennis -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
