2012/6/10 Wouter Verhelst wrote:
>> A lot of people (including you) said that tmpfs makes things faster. But
>> there were no examples of popular use-cases becoming faster because
>> of /tmp on tmpfs, so I had nothing to quote.
>
> You're not even trying.
>
> if tmpfs is faster than (say) ext4, then anything which uses /tmp will
> obviously speed up.
That's not true. Only applications, that are limited by /tmp speed will
become faster then. Do you know such applications?
> Can I provide a use case where this will matter? Not necessarily. But
> then, can you provide a use case where this will *not* matter? Really?
Yes. Everything. Every popular /tmp usage that most users expect to work
is limited either by CPU (gcc compiling) or by network speed (browser or
flash temporaries), or is just too fast already (bash heredoc). So moving
/tmp to tmpfs does not make them faster, but can break them instead (if
there's not enough space to store a streamed video, for example).
>> Nobody could provide examples or numbers of how much /tmp on tmpfs
>> reduces amount of writes, and tests showed that tmpfs+swap may even
>> increase amount of writes (hence not always good for SSD),
>
> True, but then swapping to an SSD is the "best" idea since "640kB is
> enough for everyone" :-)
Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea
to use tmpfs without swap, since it would be too small and may even
trigger OOM killer. When is it good to use tmpfs then? ;)
>> tmpfs does not have 5% overflow safety,
>
> Because it doesn't need it.
> The 5% overflow safety exists for two reasons:
> - to avoid excessive fragmentation (which is not relevant for tmpfs)
> - to allow you to clean up when the filesystem does fill up.
You missed one more reason. When user fills the entire /tmp on disk, it
does not break system services, since root can still use those 5%. User
cannot break the system filling /tmp on disk. But he can do that if he
fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure
for servers.
--
Serge