tmpfs на /var/tmp - нормально или нет?

если не ошибаюсь одно из назначений /var/tmp вроде как специально для файлов которые не должны терятся при перезагрузках

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

Я это тоже читал в том же FHS, но потом почитал документацию к ядру и увидел что там приводят в пример /var/tmp как точку монтирования для tmpfs:

Some people (including me) find it very convenient to mount it
50 e.g. on /tmp and /var/tmp and have a big swap partition. And now
51 loop mounts of tmpfs files do work, so mkinitrd shipped by most
52 distributions should succeed with a tmpfs /tmp.

Собственно, из-за того что в FHS написано одно, а в документации другое и возник вопрос.

можно монтировать

другое дело, что то приведет к глюкам и неудобствам

другое дело, что то приведет к глюкам и неудобствам

Каким например? Просто когда гуглил про это дело не нашел каких-то особых проблем, обычно «УМВР».

У кед там например хранится кэш тем плазмы. Если смонтировать /var/tmp в tmpfs то этот кэш будет создаваться каждый раз при загрузке, это не критично но увеличивает время запуска кед. Это единственная проблема с которой с толкнулся когда пытался такое сделать на своей системе.

Спасибо за ответ.

лишние тормоза для вторичной загрузки и рассчета

Просто когда гуглил про это дело не нашел каких-то особых проблем, обычно «УМВР».

дык оно и будет УМВР. /var/tmp/ это временные файлы, и есть смысл их удалять. Например для экономии места. Ессно надо помнить о том, что в следующий раз их надо опять считать и/или качать откуда-то. Если у тебя супербыстрый интернет, SSD и мощный CPU(и ещё МНОГО памяти), то да, это вполне хороший ход. Особенно если у тебя при всём при этом не хватило денег на несколько гигабайт дискового пространства.

несколько гигабайт дискового пространства.

brainfucker@FuckingComputer:/media/G/TMP$ sudo du -shx /var/tmp
[sudo] password for brainfucker: 
384M    /var/tmp

Какие гигабайты?

Какие гигабайты?

ты значение слов _временные_ файлы понимаешь? Если у тебя сейчас там 384М, то это ни о чём не говорит.

у меня вот

# du -shx /var/tmp/
911M	/var/tmp/

На машине с 24 гигами у меня оно в раме. На машине 8 гигами - не рискую, потому что и так частенько в своп падаю. :(

а если в тмпфс, а перед выключением сбрасывать куда-то, а потом опять читать в тмпфс?

грузится кеды будут чуть дольше, зато окошки распахиваться чуть быстрее

Загрузка у меня стала значительно дольше, до 2х раз. А окошки на вид работали также как и раньше.

А можно еще в /var/tmp/kdecache-username/ смонтировать отдельный раздел:) Но я не вижу никакого смысла в этом, хотя если у тебя ссд. У меня он например есть ссд и на нем стоит система, но поммимо него у меня есть обычный шдд куда и смонтирован /var

Загрузка у меня стала значительно дольше, до 2х раз. А окошки на вид работали также как и раньше.

то у тебя. Видать скорость распахивания упирается не в кеш, а во что-то другое, например в CPU/GPU.

Это очередной раз доказывает тот факт, что обычно «оптимизации» только всё портят.

Но я не вижу никакого смысла в этом, хотя если у тебя ссд.

у меня ssd, и /var смонтирован в отдельный раздел на SSD. И /var/tmp там же. Брат жив.

в FHS написано одно, а в документации другое и возник вопрос

Ядру пофигу (у него 100500 различных применений), а вот софту такое может и не понравится. От конфигурации зависит.

ты значение слов _временные_ файлы понимаешь?

Я то понимаю, в отличии от тебя. Временные не значит одноразовые. Это кеш, файлы там могут лежать сколько угодно не меняясь. Зачем их пересоздавать каждый день заново, если можно один раз создать и затем просто читать при необходимости? И уж тем более держать весь этот хлам, к которому система редко обращается, в памяти. В памяти уместно держать то, к чему система или ПО часто обращается. У тебя ума как у Зенитара...

Угу. tmpfs. А потом ты невзначай такой жмешь Enter нечаянно на n-гиговом архиве в Midnight Commander, и вся система уходит нахрен в ступор, потому что угадай с трех раз, куда mc разматывает архивы в своих целях.

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

зачем им занимать место, ели они уже не нужны? Ну к примеру ты смотришь ЛОР. Есть смысл отрендерить страничку, и записать в /var/tmp. Тогда после перезагрузки она откроется мгновенно. А если ты нажал «обновить»? Очевидно, старую версию можно выкинуть в /dev/null. А вот СКОЛЬКО весила старая версия? Ты знаешь? И я не знаю. То, что текущая весит 100К — ничего об этом не говорит.

(пример с браузером надуман, ибо IRL например ФФ хранит кеш в $HOME, а не в /var/tmp, но с другими программами так всё и есть)

И уж тем более держать весь этот хлам, к которому система редко обращается, в памяти. В памяти уместно держать то, к чему система или ПО часто обращается. У тебя ума как у Зенитара...

ты какой-то странный: файлы и так будут в памяти, ты разве кеширование отключил? Просто при перезагрузке файлы из памяти исчезнут, а вот в /var/tmp/ они останутся. Т.е. в примере с браузером, ты увидишь _мгновенно_ страничку, которая была до перезагрузки. Ибо её не нужно качать ещё раз и рендерить(процесс этот очень длительный, если на страничке есть контент из разных источников, как обычно и бывает).

потому что угадай с трех раз, куда mc разматывает архивы в своих целях.

зачем гадать? в мане написано, что в $MC_TMPDIR.

А что такого? Юзай tar -tvv для этого.

зачем им занимать место, ели они уже не нужны?

А с чего ты взял что они не нужны? Они не нужны какую-то часть времени, немаленькую. Через какой-то период они будут снова нужны. Совсем от них избавиться невозможно, они будут создаваться вновь и вновь. Таким образом, место они будут занимать постоянно. Таким образом, нужно решить где их держать. Если ПО к этим данным обращается очень часто, логично разместить в памяти. Если ПО к этим данным обращается нечасто, логично держать на диске. Таким образом, именно эти данные логично держать на диске, а не в памяти.

Ну к примеру ты смотришь ЛОР. Есть смысл отрендерить страничку, и записать в /var/tmp. Тогда после перезагрузки она откроется мгновенно. А если ты нажал «обновить»? Очевидно, старую версию можно выкинуть в /dev/null. А вот СКОЛЬКО весила старая версия? Ты знаешь? И я не знаю. То, что текущая весит 100К — ничего об этом не говорит.

Брез зенитара. Странички я держу в кеше на диске, но обращаюсь к ним только когда запрашивать их с сервера снова не имеет смысла или невозможно. Например нажал кнопку браузера «назад» или когда хочу получить страницу, которой на сервере уже нет (или сервер внезапно лежит). Для этого и существует кеш. Хранить его в ОЗУ глупо. Другое дело данные, с которыми ПО активно работает. Их логично держать в ОЗУ.

А с чего ты взял что они не нужны?

а зачем хранить отрендеренную страничку с ЛОРа месячной давности, без этого комментария? Ясное дело, что её надо удалить и заменить новой. Ну и вообще хранить ВСЕ странички просто глупо, у меня за неделю /var/ распухнет так, что всё вообще рухнет.

Через какой-то период они будут снова нужны. Совсем от них избавиться невозможно, они будут создаваться вновь и вновь.

будут. Если ты путь не поправишь (обычно во вменяемых программах есть такая возможность).

Таким образом, нужно решить где их держать. Если ПО к этим данным обращается очень часто, логично разместить в памяти. Если ПО к этим данным обращается нечасто, логично держать на диске. Таким образом, именно эти данные логично держать на диске, а не в памяти.

проблема в том, что решить эту задачу без libastral.so невозможно. Откуда программа знает, зайдёшь ты на ЛОР завтра, или ты пароль выложил, и теперь заходишь как аноним?

Впрочем, можно замутить статистику, куда ты ходишь и что ты делаешь. Тогда с большой вероятностью можно предсказать, что тебе надо, и что — не нужно.

А где хранить статистику, дядя? Толку от статистики, которая постоянно исчезает?

Брез зенитара. Странички я держу в кеше на диске, но обращаюсь к ним только когда запрашивать их с сервера снова не имеет смысла или невозможно. Например нажал кнопку браузера «назад» или когда хочу получить страницу, которой на сервере уже нет (или сервер внезапно лежит). Для этого и существует кеш. Хранить его в ОЗУ глупо. Другое дело данные, с которыми ПО активно работает. Их логично держать в ОЗУ.

facepalm.

даже не знаю, что тебе сказать…

«кеш браузера» и «дисковый кеш» — совершенно РАЗНЫЕ вещи. Последний работает ВСЕГДА, даже без браузера. И через него ты читаешь любые файлы. Т.е. файл сначала грузится в кеш, а потом уже тебе. А если ты его второй раз читаешь, то он из кеша читается, если он там есть. Именно по этой причине выносить всё в память глупо — оно и так УЖЕ там. Для временных файлов обычна ситуация, когда они вообще на диск НЕ пишутся. Т.е. они пишутся в кеш, и программа работает дальше, а запись на диск откладывается. Потом программа удаляет файл, ещё ДО того, как файл будет отправлен на HDD.

а зачем хранить отрендеренную страничку с ЛОРа месячной давности, без этого комментария? Ясное дело, что её надо удалить и заменить новой.

Ну так в кеше и хранится всегда последняя версия страницы, к которой пользователь обращался. Я что, утверждал обратное? Слушай, ты постоянно шлангуешь в диалоге. Какой смысл с тобой что-то обсуждать? Такое впечатление будто с ребёнком общаешься, а не с тридцативосьмилетним старпёром.

проблема в том, что решить эту задачу без libastral.so невозможно.

Эту задачу решают разработчики ПО. Им лучше знать, что хранить в памяти, а что нет, т.к. они прекрасно понимают какие данные и как часто приложение читает. К примеру, кеш темы иконок глупо держать в ОЗУ, достаточно чтобы он лежал на диске и читался или обновлялся при необходимости.

Откуда программа знает, зайдёшь ты на ЛОР завтра, или ты пароль выложил, и теперь заходишь как аноним?

А причём тут вообще ЛОР и web страницы? Браузеры всё делают логичным образом по умолчанию. В кеше сохраняется версия страницы, к которой обращались в последний раз. При повторном доступе к ней она обновляется. Из кеша браузер её читает в определённых случаях, например когда пользователь возвращается назад по истории, либо в автономном режиме (часто пользуюсь им для сохранения страницы, которую выпилили). Но тут всё зависит от настроек и соответствующих заголовков. Кеширование может быть запрещено владельцем сайта.

«кеш браузера» и «дисковый кеш» — совершенно РАЗНЫЕ вещи.

А я разве утверждаю что это одно и то же? Ты задолбал, что доказать то пытаешься? Или опять просто решил поболтать неважно о чём от скуки?

А где хранить статистику, дядя?

Статистика, мальчик, относится не к временным файлам, а к спулу (хранилищу меняющихся данных). Придумай другой пример.

Ну так в кеше и хранится всегда последняя версия страницы, к которой пользователь обращался. Я что, утверждал обратное? Слушай, ты постоянно шлангуешь в диалоге. Какой смысл с тобой что-то обсуждать? Такое впечатление будто с ребёнком общаешься, а не с тридцативосьмилетним старпёром.

ты вообще вдумываешься в то, что я пишу? «Шлангуешь» как раз ты.

Эту задачу решают разработчики ПО.

они по твоему боги что-ли? Ты можешь понять простую вещь, что разработчики ПО не в курсе, как у тебя настроено кеширование в твоей системе. И тем более не в курсе, что ты вывел в tmpfs каталог /var/tmp/. Т.е. если разработчику нужен временный файл, он его сделает в $TMP, а вот если он полез в /var/tmp/, то значит ему не просто временный нужен, а такой временный, который никто не сотрёт между запусками программы.

примеру, кеш темы иконок глупо держать в ОЗУ

хорош шланговать! Ядро мало волнует, что это кеш иконок, оно его ВСЁ РАВНО будет в кеше держать, как любой файл. (кроме некоторых исключений). Пусть это по твоему «глупо».

А где хранить статистику, дядя?

Статистика, мальчик, относится не к временным файлам, а к спулу (хранилищу меняющихся данных). Придумай другой пример.

ты так не ответил на мой вопрос. /var/spool/ не подходит для обычного пользователя.

ты вообще вдумываешься в то, что я пишу?

Нет конечно, потому что ты пишешь ахинею.

они по твоему боги что-ли?

В данном случае да, потому что они создатели.

разработчики ПО не в курсе

Про дефолт в курсе. А если пользователь что-то перенастроил по своему, то это уже их не касается, тут пользователь сам должен понимать что он делает и зачем.

Ядро мало волнует, что это кеш иконок

А причём тут ядро? Оно также кеширует данные в ОЗУ так, чтобы снизить I/O, то есть те данные, к которым ПО часто обращается.

оно его ВСЁ РАВНО будет в кеше держать

Только ту часть данных, к которым происходит частое обращение. Зачем мне принудительно совать в ОЗУ то что не надо?

Короче, в ОЗУ должны быть те данные, к которым происходит постоянное обращение в процессе работы. Те данные, которые могут быть использованы повторно, на создание которых тратятся какие либо ресурсы (время, вычислительные ресурсы и пр.), логично держать в кеше на диске. Если обращение к ним происходит нечасто, совать их в ОЗУ не имеет смыса. Это очевидно и логично, я не понимаю что ты мне хочешь доказать.

Отдельный случай пользователи SSD. Они для экономии ресурса диска часто предпочитают размещать некоторые динамические данные в ОЗУ. Но это уже их личное дело и размещение /tmp, /var/tmp и прочего в ОЗУ не может являться рекомендацией для всех.

Чего ты мне пытаешься втереть, я никак не могу понять, выражайся яснее. Болтаешь про какие-то страницы ЛОРа...

ты вообще вдумываешься в то, что я пишу?

Нет конечно, потому что ты пишешь ахинею.

ну и что удивительного в том, что ты ничего не понял?

В данном случае да, потому что они создатели.

нет.

А причём тут ядро?

при том, что не ты и не разрабы никак не могут повлиять на то, где будут лежать файлы. Т.е. твоя фраза «глупо держать в ОЗУ» не имеет никакого смысла. Кто тебя(разрабов) спрашивает?

Отдельный случай пользователи SSD. Они для экономии ресурса диска часто предпочитают размещать некоторые динамические данные в ОЗУ. Но это уже их личное дело и размещение /tmp, /var/tmp и прочего в ОЗУ не может являться рекомендацией для всех.

тут больше от размера RAM зависит, чем от SSD. «Ресурс» у SSD сейчас не хуже, чем у HDD. Во всяком случае, разными «оптимизациями» убить HDD намного проще и быстрее.

при том, что не ты и не разрабы никак не могут повлиять на то, где будут лежать файлы. Т.е. твоя фраза «глупо держать в ОЗУ» не имеет никакого смысла. Кто тебя(разрабов) спрашивает?

А и не надо. Ядру всё равно с какими данными работает пользователь, оно просто кеширует в ОЗУ любые данные, к которым происходит очень частое обращение. Так зачем мне совать в ОЗУ всё подряд, несмотря на то что оно используется относительно редко? В ОЗУ логично размещать те данные, к которым происходит очень частое обращение, те временные данные, время жизни которых короткое (pid файлы в /var/run, например), максимум до выключения компьютера, те данные, когда критично время доступа и т.д. Какой смысл совать в ОЗУ /var/tmp?.

Зато $HOME/.local/appname/spool подходит.

там не хранится ничего такого, что критично при работе.
если кде например, то будет перерегистрироваться кеш.