On Sun, Mar 18, 2007 at 01:44:33PM -0400, Ivan Adzhubey wrote:
> Ну наконец-то хоть кто-то меня поддержал ;-) А то дискуссия стремительным 
> домкратом ушла в направлении обсуждения /tmp/.private, то есть мелких 
> деталей, которые меня пока не интересуют совершенно, а на мои вопросы, с 
> которых этот тред начался, господа разработчики забили.
> 
> > По сути дискусси - я не понял самого главного
> > - какая цель приследуются при переводе /tmp под tmpfs ? (предпологаю
> > повышения быстродействия системы ?)
> >
> > - в каких случаях это реально повышает быстродействие, а в каких нет ?
> 
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на 
> сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно 

Я измерял производительность sqlite3 на одном достаточно сложном запросе
(могу раскопать сам запрос и объяснить, как всё это запустить).  sqlite 
пишет write-ahead log с честным fdatasync(2).  На tmpfs этот запрос
отрабатывался в 60 раз быстрее, чем на ext3.  Несколько минут против
четырех часов.

По сути, любая "настоящая" файловая система слишком честно делает
много-много всего, чтобы в любой момент времени данные на диске
существовали в консистентном или хотя бы в предсказуемо-неконсистентном
(легко восстанавливаемом до консистентного) состоянии.  Если же принять
семантику /tmp, которая состоит в том, что данные из /tmp после
перезагрузки не имеют смысла, тогда можно не делать много-много всего,
что становится лишним.  По сути должно быть ясно, что содержимое свопа
имеет смысл только в связи с текущим состоянием kmem.

> я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А 
> когда может? Когда начинает расти производительность, а когда - падать? 
> Кто-нибудь вооще это мерял?

Ну, можно сделать своп на 80 гигабайтов.  Много от чего зависит, может и
не подойти.  Но выиграш сооблазнительный.