Используете ли вы tmpfs (и с каким размахом, параметрами и успехом)

[InterChaynik]

Навеяно темой Как перенести /tmp в /home?

Ну, думаю суть опроса понятна: использует ли простой (и не очень) юзер такую фишку как tmpfs и если "да", то с какими параметрами, при каком ОЗУ и вообще - как оно у него там вообще (глючит - не глючит, переполняется (и на скока?) - не переполняется, надо оно ему или на фиг сдалось, лучше без него)?

[Bizdelnick]

Оченно замечательно в нём что-нибудь не очень большое собирать. Или даже просто архив распаковать временно.

[InterChaynik]

А вот тут http://unixforum.org/index.php?act=findpost&pid=1179608 drBatty высказал, так я так и не понял, целесообразно, по его мнению, держать tmpfs или нет:

Держать /tmp в памяти или хотя-бы на отдельном разделе практичнее. В первом случае временные файлы читаются/пишутся быстрее

а это НЕ правда. Вы забыли про кеширование. У нас не венда.

т.е. на отдельном разделе /tmp/ нужно держать. Но не в памяти. на отдельном разделе по соображениям безопасности, ибо это общедоступный раздел. А вот в памяти не обязательно (хотя можно, из-за той-же безопасности)

если вы всё же пожелаете держать /tmp/ на диске, то нужно продумать меры его очистки при выходе из системы.

[ishitori]

А вот тут http://unixforum.org/index.php?act=findpost&pid=1179608 drBatty высказал, так я так и не понял, целесообразно, по его мнению, держать tmpfs или нет:

держать /tmp в памяти хорошо со всех сторон. единственная проблема - если у вас этой памяти мало.
а вообще использую tmpfs очень давно и с параметрами из арчвики (кроме размера, конечно):

tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0

да, если в генте собирать какой-нибудь офис, то 3 ГБ может и не хватить. но, к счастью, теперь у меня есть замечательный арчик, в котором данная проблема более неактуальна.

[Bizdelnick]

Если говорить про /tmp, то, на мой взгляд, выигрыш от использования tmpfs стремится к нулю. Разумеется, если не пользоваться программами, гадящими в /tmp при каждой загрузке и не подчищающими за собой (ну вы поняли, о чём я).

[InterChaynik]

Если говорить про /tmp, то, на мой взгляд, выигрыш от использования tmpfs стремится к нулю. Разумеется, если не пользоваться программами, гадящими в /tmp при каждой загрузке и не подчищающими за собой (ну вы поняли, о чём я).

Ну почему же к нулю? А как же скорость работы? : с оперативной памятью работать вроде побыстрее чем с записью на диск...

держать /tmp в памяти хорошо со всех сторон. единственная проблема - если у вас этой памяти мало.
а вообще использую tmpfs очень давно и с параметрами из арчвики (кроме размера, конечно):

tmpfs /tmp tmpfs nodev,nosuid,size=3G 0 0

да, если в генте собирать какой-нибудь офис, то 3 ГБ может и не хватить. но, к счастью, теперь у меня есть замечательный арчик, в котором данная проблема более неактуальна.

ishitori, где то на этом форуме кажется промелькнуло, что у вас вроде 8 Гб оперативки, это правда? Интересно, а как собирать этот Офис другим, у кого нет этих 3 Гб?

[Red Gremlin]

Разумеется, если не пользоваться программами, гадящими в /tmp при каждой загрузке и не подчищающими за собой

Некоторые программы, например atop, гадят в /tmp непрерывно. Да и всякие mc активно используют /tmp, так что выгоду от tmpfs лично я для себя вижу.

[Bizdelnick]

А как же скорость работы?

Не вижу разницы. В /tmp не так много чего пишется, чтобы это было критично.

[Bizdelnick]

Некоторые программы, например atop, гадят в /tmp непрерывно. Да и всякие mc активно используют /tmp, так что выгоду от tmpfs лично я для себя вижу.

Забыл упомянуть, что есть всякие tmpwath и tmpreaper, от которых при большом аптайме пользы больше, чем от tmpfs.

[InterChaynik]

Я, конкретно для себя, tmpfs лишь с /тмп и ассоциирую, но находятся умельцы, использующие tmpfs и для других целей. Ну, и вот вы писали "Если говорить про /tmp...", что значит можно и "не про /tmp": как там обстоят дела с выигрышем от использования tmpfs ?

[SinClaus]

tmpfs активно использует ось (ARCH), мне в общем до этого мало дела
А я использую nullfs, что бы "размножить" порты BSD по jail'ам.

[drBatty]

Некоторые программы, например atop, гадят в /tmp непрерывно. Да и всякие mc активно используют /tmp, так что выгоду от tmpfs лично я для себя вижу.

я не вижу выгоды в atop'е и mc.

[drBatty]

drBatty высказал, так я так и не понял, целесообразно, по его мнению, держать tmpfs или нет:

с точки зрения производительности - для большинства случаев НЕ целесообразно. Временные файлы они на то и временные, что существуют недолго. Потому всякая мелочь и файлы, которые постоянно меняются, попросту не дойдут до поверхности диска. Т.е. у вас есть скрипт, который создаёт временный файл, что-то туда пишет/читает, а потом удаляет. Так вот, вне зависимости, где делать /tmp, файл НЕ доберётся до диска - просто не успеет. Потому смысла в tmpfs лично я не вижу никакого. Хотя, если вы например постоянно клонируете разные DVD-R, то вам есть смысл насильно запретить временному образу сбрасываться на диск, смонтировав tmp в память. Правда, тогда оно всё равно будет сбрасываться из-за свопинга при нехватке оперативной памяти. Лично я клонировал DVD в посл. раз несколько лет назад, да и памяти у мну тогда было всего 512Мб, т.ч. для меня это не играет роли.

А в цитате говориться о годности и секьюрности tmpfs, ибо RAM не восстанавливается уже через несколько минут после отключения. А в /tmp/ злоумышленник в принципе может найти полезные обрывки (вряд-ли, ибо секьюрные программы юзают секьюрную память, которая не свопится и не в /tmp)

[drBatty]

Ну почему же к нулю? А как же скорость работы? : с оперативной памятью работать вроде побыстрее чем с записью на диск...

а зачем системе записывать на диск временные файлы? Запись ведётся тогда, и только тогда, когда она действительно необходима, или в том случае, если система бездействует.

Некоторые программы, например atop, гадят в /tmp непрерывно.

по твоему atop постоянно ждёт, пока окончится запись? и все ждут? или оно каждый раз sync'ает? У тебя наверное tmp на флешке, которую ты постоянно выдёргиваешь?

как там обстоят дела с выигрышем от использования tmpfs ?

можно ВСЁ засунуть в память, как это и сделано во многих LiveCD. Вот например мандрива 2009я грузилась на 512и мб памяти с лайва больше часа, ИЧСХ работала _медленнее_. Что вполне объяснимо - в памяти была ВСЯ система, и места для дискового кеша и приложений тупо не было. Если добавить ещё 1024Мб, то всё грузилось нормально, да и работало тоже. Хотя свободной памяти (кеша) было значительно меньше. Однако, на десяток окошек хватало. За то секьюрно и удобно - HDD может вообще отсутствовать.

[InterChaynik]

Ну, drBatty, на сей момент, однако, вы наверное единственный, кто проголосовал "нет", (а хотя не, кто то ещё один так же проголосовал) если конечно вы вообще голосовали.

[NickLion]

Я третий "нет" проголосовал (имея в виду /tmp). Смысла не вижу. Если руки дойдут проверить скорость компиляции, и окажется, что tmpfs даёт прирост, то может и перейду.

[nill]

Использую tmpfs на eeepc 701. На основной машине не вижу смысла использовать по уже указанным выше причинам.

[drBatty]

Ну, drBatty, на сей момент, однако, вы наверное единственный, кто проголосовал "нет", (а хотя не, кто то ещё один так же проголосовал) если конечно вы вообще голосовали.

дык я НЕ МОГУ дать однозначного ответа. Перечитайте мой пост внимательно. Вот резюме:
1. Я не считаю, что монтирование в память (для /tmp) следует использовать для повышения быстродействия.
2. Однако я считаю, что /tmp нужно монтировать в память для большей безопасности.
такого пункта в опросе нет. Если есть много памяти, и если безопасность важна, то использую. Иначе - не использую. Никакой выгоды по производительности я не наблюдаю (ну разве что можно загадить /tmp, и тогда всё вообще встанет колом, а RAM сама чистится на перезагрузках)

Если руки дойдут проверить скорость компиляции, и окажется, что tmpfs даёт прирост

вроде-бы даёт. На границе допустимой погрешности. С секундомером можно заметить.

[InterChaynik]

2. Однако я считаю, что /tmp нужно монтировать в память для большей безопасности.

А так ли уж велика эта пресловутая угроза безопасности чтоб из-за неё заморачиваться? Злобный вирус, как в Винде, после перезагрузки активизируется? троян червивый, паролики от ВКонтактика с Однодрочерами скомуниздит? хакер ушлый статистику использования компом заполучит?

Никакой выгоды по производительности я не наблюдаю (ну разве что можно загадить /tmp, и тогда всё вообще встанет колом, а RAM сама чистится на перезагрузках)

1) Эта РАМ сама, если и так сама по себе не велика, быстрей колом встанет: у меня /tmp 2 Гб, и если, следуя рекомендации относительно тмпфс, выделить под неё 25% от общей массы оперативки, а у меня это будет 500Мб, то сравните разницу - 2 Гб и 500Мб и подумайте, что быстрее переполнится при выполнении некоторых определённых приложений (флэш-ролики в кэше браузера (или теперь повсюду он в домашнем каталоге), копирование диска с сохранением временного образа догадайтесь где)?
2) /tmp тоже обязана самоочищаться с перезагрузкой (по крайней мере в Убунтоидных "семействах")

Если руки дойдут проверить скорость компиляции, и окажется, что tmpfs даёт прирост

вроде-бы даёт. На границе допустимой погрешности. С секундомером можно заметить.

И стоит ли за этим гнаться?

[drBatty]

А так ли уж велика эта пресловутая угроза безопасности чтоб из-за неё заморачиваться?

нет. Это лишь одна из мер. Она не является необходимой, ибо секьюрные программы не используют /tmp для хранения секьюрных данных. И тем не менее, секретная информация _может_ туда попасть. И попадает иногда. Например архиватор может и не знать, что он сжимает секретную инфу. Особенно опасно, если на /tmp много свободного места (например он общий с большим /home/), тогда удалённые файлы могут лежать на поверхности диска практически вечно.

Злобный вирус, как в Винде, после перезагрузки активизируется? троян червивый, паролики от ВКонтактика с Однодрочерами скомуниздит? хакер ушлый статистику использования компом заполучит?

если вас волнуют эти риски, не заморачивайтесь, юзайте бубунту.

1) Эта РАМ сама, если и так сама по себе не велика

Если RAM мало, то никакого смысла юзать память для /tmp/ нет, и с этим никто НЕ спорит. Не я, во всяком случае. Имеется ввиду случай, когда памяти МНОГО.

2) /tmp тоже обязана самоочищаться с перезагрузкой (по крайней мере в Убунтоидных "семействах")

что там в бубунте - не знаю, а насколько я знаю, по стандарту оно _может_ быть очищено/испорчено, но НЕ обязано.

И стоит ли за этим гнаться?

решать вам. Повторяю - я не гонюсь за этим.

[Bizdelnick]

вроде-бы даёт. На границе допустимой погрешности. С секундомером можно заметить.

Фигасе на границе. Безо всяких секундомеров могу сказать, что разница в разы. Но это с учётом распаковки тарбола в tmpfs.

[alv]

Безо всяких секундомеров могу сказать, что разница в разы. Но это с учётом распаковки тарбола в tmpfs.

Ох не верю...
В Линуксе компиляцией чего-то фундаментального в tmpfs не занимался - в дженедужные времена, то есть 10 лет назад, у меня столько памяти не было.
А вот во Фре и в DragonFly'е у меня mfs (BSD'шный аналог tmpfs) была всегда подмонтирована в /tmp и в /usr/obj. Так вот, на сборке ядра и мира это даёт стабильный рост быстродействия на 10% - не больше, но и не меньше. Не думаю, что ситуация в Линуксе существенно отличается.
Ну а много это или мало, 10% - каждый решает для себя. Если беспрерывно заниматься сборкой ядра и мира во Фре или эмерджить мир в Дженту - наверное, много. Правда, непонятно, куда девать сэкономленное время - на ещё пару пересборок?
С третьей стороны, tmpfs/mfs там, где она уместна, как минимум не повредит, а если повезёт, то и принесёт пользу.

Что же до нехватки памяти - то извиняйте, но если при сборке нового десктопа на это дело закладывать в смету 100 баксов - то нынче это не 4 ГБ, и даже не 8, а скорее все 16. Если не гнаться за супер-пупер-оверклопер модулями, которые уж точно в обчной жизни дадут прирост быстродействия в доли прОцента.

[liaonau]

Аргумент «за» кроме скорости. tmpfs, например, очень полезна при использовании SSD, скажем в нетбуке.

[eddy]

Использую с параметрами по умолчанию.

[McSim]

Хороший левелап в скорости я добился в CUPS + SAMBA, разместив спулеры самбы и капса в tmpfs и установив в сервер 2 гигабитные сетевушки, объеденив их в бондинг.
Имелся старый сервер на Xeon, который не поддерживает аппаратную виртуализацию, но имеет 8 Гб памяти. Вот я и использовал ее по максимуму.
Прирость в производительности колоссальный (особенно приотправке печатных форм из 1С или больших графических материалов).
Узким местом становится сетевой принтер )

[Davinel]

Браузерный кэш можно в tmpfs совать. Или вообще весь профайл, но тогда его нужно синхронизировать периодически.
Ну и /tmp там вполне неплохо смотрится. Некоторые программы его достаточно активно используют.
Хотя откровенно говоря в последнее время с современными ssd это как-то потеряло актуальность уже...

[serzh-z]

Браузерный кэш можно в tmpfs совать

Ээ, а смысл? У браузера и без того есть кеш в памяти, оффлайн-кеш должен сохраняться между перезапусками и перезагрузками.

а вообще использую tmpfs очень давно и с параметрами из арчвики (кроме размера, конечно):

Арчивики устарело в этом плане. core/filesystem уже давно создаёт /tmp в tmpfs по умолчанию.

[Davinel]

Ээ, а смысл? У браузера и без того есть кеш в памяти, оффлайн-кеш должен сохраняться между перезапусками и перезагрузками.

Ну как же, читать из оффлайн кэша быстрее будет. При первом открытии странички, которая есть в оффлайн кэше, она будет открываться так, как будто она уже есть в памяти(потому что она и есть в памяти).
Ну и кэш синхронизировать можно же.
И да, не то чтобы в этом было много смысла т.к. разница в скорости разовая и не такая уж большая.

[ishitori]

Ээ, а смысл? У браузера и без того есть кеш в памяти, оффлайн-кеш должен сохраняться между перезапусками и перезагрузками.

Ну как же, читать из оффлайн кэша быстрее будет. При первом открытии странички, которая есть в оффлайн кэше, она будет открываться так, как будто она уже есть в памяти(потому что она и есть в памяти).
Ну и кэш синхронизировать можно же.
И да, не то чтобы в этом было много смысла т.к. разница в скорости разовая и не такая уж большая.

в арчике для этой цели есть profile-sync-daemon.

[daedalus]

Нет, не использую. Без него все прекрасно работает.

Код: Выделить всё

[daedalus@icarus ~]$ sudo free
             total       used       free     shared    buffers     cached
Mem:       16777216    1374384     15402832          0      76392     564696
-/+ buffers/cache:     733296    1331780
Swap:      35600201          0    35600201

[daedalus@icarus ~]$ sudo dmesg | grep cpu
[    4.939728] powernow-k8: Found 1 AMD Phenom(tm) II X4 B50 Processor (4 cpu cores) (version 2.20.00)

[daedalus@icarus ~]$ uname -a
Linux icarus 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 13:04:04 UTC 2012 x86_64 GNU/Linux