Re: Moving /tmp to tmpfs makes it useless
Nikolaus Rath <Nikolaus@rath.org> writes:
> Thomas Goirand <firstname.lastname@example.org> writes:
>> On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
>>>> What if we're installing Debian on a very small system, and that we
>>>> need operations with big files in /tmp?
>>> Increase your swap?
>> So, in this case, we will have the following scenario:
>> - An app writes in /tmp
>> - There's not enough space, so the system starts swapping,
>> including some apps.
Which happens regardless wether tmp is tmpfs or a real filesystem. The
more IO there is the more likely some app gets swapped out.
>> - The file gets written to /tmp, then gets read
>> - Finally, the file gets deleted
With tmps that instantly frees up all the memory and swap used by the
file. With a real FS the file data remains in the dirty cache until such
a time as the disk has cought up with writing it all and then it is
thrown away. So potentially memory is freed up much later.
>> - Then we have randomly very sloppy reaction of apps
>> that were swapped out so that the file could be written
>> in /tmp.
Which, without tmpfs, then has to additionaly first wait for the dirty
cached data to be written out causing huge delays because you get two
seeks per page, 4k read/writes and no read-ahead.
> I believe tmpfs memory is swapped out preferentially, so your scenario
> doesn't have to play out like that. However, paging being a complex
> process, it's not impossible either. Is that something people are
> actually seeing? Because I haven't encountered this.
It happens. But that isn't to say it doesn't equally (or worse) happen
with a real FS.
Paging is a complex process and there are so many factors involved that
predicting the behaviour becomes pure guesswork. I would say both Thomas
and my scenario are equally likely to occur. No matter what the default
is there will be some users that hit the worst case.