Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow <goswin-v-b@web.de>]

Nikolaus Rath <Nikolaus@rath.org> writes:

> Thomas Goirand <zigo@debian.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.

MfG
        Goswin