Debian переходит к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру

tmpfs хороша лишь когда памяти дохрена и она никем серьёзно не используется. То есть на серверах, например на серверах CI/CD. А на персональном компьютере оперативную память лучше беречь для программ и никакие tmpfs в ней не держать.

tmpfs хороша лишь когда памяти дохрена и она никем серьёзно не используется.

$ cat .rpmmacros | grep tmppath
%_tmppath       %homedir/tmp-build

tmpfs  5,0G 39M 5,0G  1% /home/user/tmp-build
tmpfs  5,0G  0  5,0G  0% /home/user/RPM/BUILD

Беречь свободную оперативную память это контрпродуктивное действие во всех возможных сценариях.

И разумеется рамдиски применяются в ситуации, когда много свободной памяти. А у меня на ПК это почти всегда. И например собрать ядро целиком в /tmp вообще не проблема.

Большое преимущество tmpfs в том, что она динамически меняет размер, в отличие от классических рамдисков, которые откусывают память на постоянку. Если мне нужно освободить память, я просто удаляю файлы. И дефолтное ограничение в 50% от объема памяти гарантирует, что критического переполнения никогда не случится.

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

переход Debian к использованию tmpfs в /tmp

Активно использую tmpfs уже лет двадцать,и именно что в Дебиане. Причем не только для /tmp но и для /home/user/.cache Удобно что .cache сам чистится при каждом выключении компа.

Tmp в tmpfs? Еще больше памяти тратить?

старше 10 и 30 дней соответственно

Идея вычистить всё это по аптайму системы очень классная

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

$ ls -l /tmp/.X11-unix/
srwxrwxrwx 1 root root 0 Jun 10 17:15 X0
srwxrwxrwx 1 root root 0 Jun 10 17:14 X1

Тсс.. Это часть плана по переводу на wayland

Беречь свободную оперативную память это контрпродуктивное действие во всех возможных сценариях.

Почему же контрпродуктивное? Когда физической памяти не хватает начинается активное использование свопа, что сильно тормозит всё вокруг. Тормозящая память - это всегда хуже тормозящего I/O.

И дефолтное ограничение в 50%

Ну нихрена себе, до 50% оперативки на всякий мусор отводить.

И например собрать ядро целиком в /tmp вообще не проблема.

А зачем его там собирать? По любому горлышко будет не в дисковых операциях.

Конечно. Мало того что буфер самого диска забьётся, так ещё trim когда то нужно делать. А вполне возможно что ещё и какую нибудь сборку мусора производить. Там показатели падают весьма существенно.

О, там точно будет милион багов на тысячу программ! Думаю уже сейчас каждый сможет за минуту придумать десяток вариантов.

Вот tar распаковал, а mc прочитал и отобразил. Или gcc собрал и положил, а другой gcc прочитал и начал собирать свой кусок. Или ffmpegthumbnaler сделал миниатюру, а dolphin показал её в папке.

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

И что теперь, не использовать возможность для ускорения когда память не забилась до отказа?

сильно тормозит всё вокруг

Если всё сделать првильно, то сёрфинг до 200% занятой оперативки будет идти с 20% замедлением. Если неправильно, ну может быть до 50% медленней. Примерно того же эффекта, только на постоянной основее, можно достичь включив защиту от спектра и мельтдауна на интелах 7-10 поколений.

А зачем его там собирать? По любому горлышко будет не в дисковых операциях.

Гентушники знают что это ускоряет сборку от 10% и выше. Если диск медленный то в разы. В комбинации с zram/zswap разумеется.

Когда физической памяти не хватает начинается активное использование свопа

У меня как раз нет свопа. Иначе смысл теряется да.

до 50% оперативки на всякий мусор отводить.

Правильно, как раз чтобы этот мусор на диск не писать.

А зачем его там собирать?

Смотрите пункт выше. Я например могу по 10 раз подряд ядро пересобирать для тестирования разных конфигов и патчей. Как и другой софт тоже. Зачем мне этот мусор на диске? Да и сотни гигабайт ресурса SSD вникуда.

А я могу запустить несколько экземпляров IntelliJ, а ешё docker, K8s плюс браузер со 100500 открытыми вкладками и до хрена чего ещё. А у меня тут 50% памяти отъела tmpfs и зачем-то ещё и zswap который нихрена не swap. Ну и нахрена?

Гентушники знают что это ускоряет сборку от 10% и выше. Если диск медленный то в разы. В комбинации с zram/zswap разумеется.

Откуда там «в разы» может взяться? Кроме того, я не гентушник, мне работать надо, а не заниматься возвратно-поступательной перекомпиляцией. И для работы памяти много не бывает. И ещё, какой смысл в zswap? Если я правильно понял, эта штука держит swap в оперативке, а в swap попадают данные из оперативки. Какой-то порочный круг.

update: да, прочитал сейчас, что все эти zram/zswap - сжимают данные. Неужели скорость сжатия/расжатия выше скорости работы с современным диском?

Ну и нахрена?

Так я за себя говорю. Мне например непонятно зачем «браузер со 100500 открытыми вкладками». Никогда не держу открытыми более нескольких вкладок.

мне работать надо

Пожалуйста. Но у всех разная работа и увлечения.

Неужели скорость сжатия/расжатия выше скорости работы с современным диском?

Естественно. LZ4, типично используемый для zram, на современном проце даст ~1 ГБ/c на сжатие и ~5 ГБ/c на разжатие, умножить на количество потоков. И время отклика в оперативу все еще сильно ниже по сравнению с любым диском.

я не гентушник, мне работать надо, а не заниматься возвратно-поступательной перекомпиляцией.

Ну, кто то этот код не только возвратно-поступательно пересобирает, но и пишет.

А ускорение там за счёт умножения на почти ноль io временных файлов сборки и ещё ненужная логика ФС выкинута. Именно сборка это идеальный пример, когда 95% времени ты получаешь плюшки от неожидания процессами диска и недёргания логики ФС, а на сборке финальных образов, когда ld даёт прик потребления оперативки, своп компенсирует недостаток памяти с некоторыми потерями. Суммарный выигрыш достигается даже на системах, где финальная стадия полезет в своп уже без tmpfs и zram/zswap.

Неужели скорость сжатия/расжатия выше скорости работы с современным диском?

Ну да, разумеется и намного. Процессоры то тоже современные, а не cortex-a53, выдающий от сотни метров до гига в секунду на одно ядро. Не, можно и медленный алгоритм если надо...

Поправка: видел у LZ4 скорости по 10-15 и вороде до 50 Гб/с.

Ну, кто то этот код не только возвратно-поступательно пересобирает, но и пишет.

Ага. И еще есть такая штука как поиск проблемного коммита путем бисекции.

Поправка: видел у LZ4 скорости по 10-15 и вороде до 50 Гб/с.

Это уже явно многопоток, либо путаница гигабайт и гигабит. Я специально привел референс в 1 поток. На количество доступных потоков каждый умножит самостоятельно.

Вот например что выдает мой актуальный 7000 райзен:

$ lz4 -b /usr/lib/libLLVM-17.so
 1#libLLVM-17.so     : 135302328 ->  66214130 (2.043),1013.9 MB/s ,5747.4 MB/s 

Хотя я сам сейчас даже zram не использую, памяти хватает и так.

А на персональном компьютере оперативную память лучше беречь для программ и никакие tmpfs в ней не держать.

а программы не используют hdd/ssd-диск для работы и ни как не могут поставить раком систему? (из-за этих самых обращений к hdd/ssd-диску?)
мне-бы вашу уверенность что «tmpfs для рабочей станции не нужен»! :о)
тут уже указали самое прямое предназначение
- сборка/компиляция/разработка софта (да и вообще - разработка)
- кеши
- и, собственно, непосредственно использование:

export TMP=/dev/shm/$USER

ХАХАХАХАХ, shim ускоряет систему, может ещё GCC оптимизация тема с «ускорением» работы системы лютая?) все «кеши», «оптимизации», «буфера», «свистоперделки» от еродивого, что уж там говорить о кешах и безопасности работы с ОЗУ, если по средствам папки /proc в linux можно спокойно запустить ядро и все порождаемые им процессы

продолжайте оттачивать свое мастерство, юродствуйте дальше, у вас это хорошо получается! :о)

тред не читай @ сразу отвечай

так падажжи, у меня на дебиане везде /tmp в tmpfs. Делает это юнит системды tmp.mount, который точно есть по крайней мере в oldstable и емнип появился вообще в незапамятные времена. Насколько помню, инсталлятор спрашивает, включать его или нет. Т.е. весь срач на 12 страниц из-за изменившегося дефолта?

Сейчас в арче посмотрел на таймеры очистки:

/tmp 10d
/var/tmp 30d 

До этой новости даже и не знал что они само очищаемые )

Половина срача было про автоматическое удаление файлов в /tmp