So, how does this scenario work?
* The machine has 4G of RAM,
* > 50% RAM is being used by actual software (firefox, eclipse, mail
client, etc), so the other < 50% is pagecache
* The machine has 4G of swap, none of which is active.
So then a user drops a 8.5G DVD image into /tmp.
On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC
and user things can't write to disk, but the OS will be fine since 5% is
reserved for root.
With tmpfs the pagecache will fill up and start to overflow to
swap...until swap fills up. What happens then? As I understand it, the
program gets ENOSPC and there is NO free RAM: pagecache is full of that
dvd data. swap is full of that dvd data. The rest of the RAM is
program data that has nowhere to page out to. The system may not have
crashed, but it is fubar: welcome to OOM killer territory
The answers of "don't do that, use /var/tmp" or "allocate more swap" are
crap. The software isn't broken if it writes to /tmp, regardless of how
many bugzilla entries get filed. Allocating more swap is a cop out
because you've only pushed the problem to some file size that is larger,
and you've tied up disk for a worst case scenario that may never come.
This introduces behavior that is highly dependent not only on the memory
configuration of the machine, but the usage at the time the allocation
happened, making this impossible to troubleshoot.
What are the benefits of this change again? Clearing /tmp at shutdown
is interesting, but can be accomplished in other ways (although not as
cleanly), and I have yet to see any hard numbers on I/O even though I
have asked repeatedly.
Brian
On 06/20/2012 01:18 PM, Gregory Maxwell wrote:
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp"
this is the wrong perspective
the right one is "the system must not crash if someone does"
Good thing it doesn't.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
