Файловая система, живущая в виртуальной памяти (RAM+swap). Много чего не умеет, но как простая/быстрая ФС для некритичной информации — вполне.
Ниже приведены подобранные на скорую руку выдержки из обсуждения применимости в sisyphus@.
> > По сути дискусси – я не понял самого главного > > – какая цель приследуются при переводе /tmp под tmpfs ? > > (предпологаю повышения быстродействия системы ?) Насколько понимаю, мало кто делает выделенный раздел /tmp. Таким образом, он оказывается на корне (мало кто делает bind mount /var/tmp туда, а те немногие — уже ходили в багзилу с жалобами на mount). Отсюда забитие /tmp порождает забитие / со всеми вытекающими. Выход: отрезать отдельный раздел, который будет преимущественно "гулять", или снизить использование /tmp. Первый вариант реализуется /tmp на tmpfs, которая живёт в RAM+swap; увеличив своп на размер потенциально выделенного под отдельный /tmp дискового пространства, получаем одним байтом двоих зайцев: когда нужен своп, это место будет использовано под него; когда нужен /tmp — под него. Более динамическое использование ресурса — ср. с необходимостью забивать руками при сборке ядра выделение памяти под page cache в OpenBSD несколько лет тому против линуксового динамического. > > – в каких случаях это реально повышает быстродействие, > > а в каких нет ? В тех, когда работа с временными файлами напряжённая. > Вот-вот. В чем идея-то?? И как реализация на tmpfs практически > повлияет на сервер/кластер работающий с 80 гигабайтами > временных файлов в /tmp? Правильно я понимаю, что в таком > случае ни о каком /tmp на tmpfs не может идти речи? Скорее да. > А когда может? Когда начинает расти производительность, а когда > – падать? Кто-нибудь вооще это мерял? Можно попробовать поставить такой эксперимент (тут тоже по 80Gb в /tmp при RAM 8Gb), но мне почему-то кажется более осмысленным на такие /tmp совать reiserfs -o notail,noatime. Возможно, потому, что баланс объёма данных и типичной работы с ними тут скорее отличается от "положить одну исошку" или даже "собрать kde".
http://lists.altlinux.org/pipermail/sisyphus/2007-March/095099.html
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на > сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно > я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А > когда может? Когда начинает расти производительность, а когда – падать? Зависит от характера работы. Типичный для сборочного сервера характер работы такой: – несколько гигабайт RAM; – tmpfs на 8*N гигабайт (где N – это число параллельных сборок); около 8G нужно для сборки OOo, остальным надо меньше; – swap размером 2*RAM+sizeof(tmpfs). При этом производительность заметно выше чем если бы сборка велась на обычной файловой системе. Разумеется, чем больше занят swap, тем ниже выигрыш в производительности. Что касается падения производительности, то при наличии достаточного свободного места в swap'е я этого падения не замечал. Мне _кажется_, что этого свободного места должно быть не меньше чем размера RAM. Ну и, конечно, необходимо помнить, что 64-битное ядро поддерживает tmpfs лучше чем 32-битное. Особенно это заметно, когда на tmpfs очень много файлов, которые суммарно занимают много места. > Кто-нибудь вооще это мерял? Я попробую специально замерить производительность в ситуации, когда заполненная часть tmpfs больше размера RAM в 4, 8, 16, 32, 64, 128 раз.