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

Потому что рукожопов много.

На самом деле разработчиков, которые «не согласны» довольно мало. И в основном они даже не то чтобы не согласны, а просто используют /tmp по историческим причинам. Это как с ~/.ssh, который отказываются перенести в XDG (и тут редкий случай, когда правильно делают).

нормально уходит в своп

а не логичней ли сразу на диск тогда, без tmpfs?

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

cc AS

То и подразумевается. При компиляции софта, файлы сборки находятся в tmpfs вместо диска.

Нет, монтирование /tmp на SSD ускоряет работу /tmp и это главный эффект.

Каким образом? RAM ведь быстрее.

Если беспокоишься за ресурс то лучше вообще отключи его от компа и сложи в сейф.

Зачем же так кардинально? В хорошем компьютере обычно два диска - SSD и HDD. Почему бы не держать все эти tmp и свопы на том HDD? Тем более, что иначе, в такой конфигурации, HDD простаивает большую часть времени ибо на нём просто архивные данные и прочая личная лобуда, а система на SSD.

И зачем на машине с 64 гигами делать своп в 64 гига? Чтобы что там хранить? А если оперативы будет 256?

Если я не ошибаюсь, такой своп нужен для сохранения дампа памяти во время кернел паники. То есть по большому счёту это требование для разработчиков и энтузиастов, а не для конечных пользователей, в особенности на домашнем железе. Тут ещё упомянули гибернацию. Но обычно она нужна лишь на ноуте, где слишком больших дисков не бывает. В таком случае наверное лусше не раздел для свопа, а файл.

В традиционном смысле понятия файл.

О какой традиции идёт речь?

производительность системы

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

Износ диска снижается на порядки.

а зачнем вообще снижать износ диска? тем более делать это переносом в tmpfs?

это только если человек занимается херней и снижает износ диска из каких-то абстрактных соображений, как самоцель.

1 тб диска стоит 10 тыс руб.

1 тб озу планками по 32 будет стоить 300 тыс. руб

Перезагрузка чистит весь мусор автоматически

файлы с диска, я напомню, тоже можно удалять. автоматически

bin и sbin вроде бы появились потому что когда-то существовала одна конкретная машина где закончился жесткий диск, к ней подключили второй, на этапе загрузки был доступен только первый.

Ты неправильно помнишь историю. /bin и /sbin для динамически и статически слинкованых программ. История со вторым диском - это история про создание /usr/bin и /usr/sbin и вообще /usr - это изначально пользовательская директория, а не как сейчас глупый /home.

Иногда бывает, что тебе нужно создать файл. Именно временно - на время работы программы. Можно, конечно, заморочиться удалением всех созданных файлов после, а можно создавать их в специальной директории для временных файлов в текущей ОС. Вот я выбираю второе и именно для этого используют директории /tmp, C:\TempFiles и так далее.

Я чота так удивился, что ажно залогинился, дабы ответить. usr - это не сокращение от user, как Вы подумали, а «Unix System Resource». И хранится там не то, что Вы подумали, а вот это самое:

Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications. Should be shareable and read-only.

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

в ней скорость работы на nvme ssd та же что и на tmpfs

Диск диску рознь. У меня все обычные SATA SSD например.

то есть tmpfs их не ускоряет вообще

Зависит от задачи разумеется. На десктопе например банальное расположения кэшей в оперативе делает интерфейс системы и приложения более отзывчивыми.

Иногда даже очень сильно https://bugs.kde.org/show_bug.cgi?id=487043

а зачнем вообще снижать износ диска? тем более делать это переносом в tmpfs?

А зачем нет? Когда куча свободной оперативы все равно стоит без дела. Не то чтобы это в ущерб чего-то делается.

снижает износ диска из каких-то абстрактных соображений

Вопрос из того же разряда как «зачем экономить ресурс подвески автомобиля, объезжая кочки». Не хотите экономить - не экономьте, ваше право.

файлы с диска, я напомню, тоже можно удалять. автоматически

Можно. Но очистка в данном случае приятный бонус, а не основная цель.

Это вообще, на столько пи^H^Hкапец, что я даже не знаю как это культурно озвучить. Вот я часто делаю в /tmp временный каталог, монтирую туда по sshfs что-то, чтобы поработать пару минут. И что, оно мне удалит втихаря файлы из моей sshfs-шары а я даже не замечу?
Нет, такой хоккей нам точно не нужен.

usr - это не сокращение от user, как Вы подумали, а «Unix System Resource».

Это где такое пишут?

огородили всех пользователей забором

Слишком громко сказано. В дебиане в принципе всегда, в отличие от Слаки или того же Арча, были какие-то свои умолчания. Теперь он поставляется с systemd, и решили включить его «фичи». Включено оно по умолчанию или выключено — на самом деле маловажный вопрос. Ну сделает тот, кому не нужно, sudo systemctl disable чо-то-там.timer, было бы выключено, кому надо делали бы sudo systemctl enable чо-то-там.timer. Изменение с гулькин нос, которое большинство пользователей вообще не заметит, а кому надо, просто одной командой отключат, а обсуждений, будто они с glibc на musl переходят или пакетный менеджер на джаве переписывают.

Много где. «Народная этимология» она такая. Хотя в принципе нормальная расшифровка, хоть и задним числом.

Вспомнил, как такое называется, бэкроним, во!

И что, оно мне удалит втихаря файлы из моей sshfs-шары а я даже не замечу?

Нет, конечно. Оно явно одной ФС ограничено. И даже временный каталог не удалит, если к нему был доступ в последние 10 дней. Оно atime же смотрит.

Вот тут, например. Расшифровки нет, но про shareable и readonly написано вполне чётко.

Впрочем, про unix system resource , действительно, навскидку найти не удалось.

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

Уважаемые знатоки философического юниксоведения, можно ли считать файлом сущность, которая не отображается на файловую иерархию?

Так она отражается. Просто ты не верно понимаешь «файловую иерархию» в Unix. «Файл» в Unix == inode. Соответственно, «файловая иерарахия» - иерархия инод. А имя - это всего лишь атрибут иноды, как таймстампы или права доступа.

Мимо автор «Критики метафизики трансцендентничного идеализма в парадигме дискурса философии Unix с позиций диалектики позитивизма».

Включено оно по умолчанию или выключено — на самом деле маловажный вопрос.

Вопрос критической важности: об этом нужно знать; это нужно не забыть отключить. ОС начинает слишком много решать за пользователя — как долго ему хранить свои файлы.

большинство пользователей вообще не заметит

Пока не потеряют безвозвратно свои файлы, как я описал выше.

Вопрос критической важности: об этом нужно знать; это нужно не забыть отключить

Кому это нужно не забыть отключить, причём так, что критически важно? Тем 0.01% от юзеров дебиана, т.е. двум-трём пользователям (а скорее ровно 0) на Земле, которые почему-то хранят важные данные в /tmp долгосрочно?

ОС начинает слишком много решать за пользователя

Ну ОС сама в данном случае не решает. Решают в Дебиан. Ну так они и раньше довольно много решали за пользователя. За ванилькой — это было к слаке.

Пока не потеряют безвозвратно свои файлы, как я описал выше.

Никто не хранит важные данные в /tmp — он не для этого, даже по названию. А уж важные данные, которые ещё и важны спустя 10 дней после последнего обращения к ним, так подавно.

Удаленные файлы продолжают существовать и отображаться в иерархию. Просто ядро их прячет от дальнейшего доступа.
Команда типа lsof / | grep '(deleted)' в помощь.

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

Мне кажется, все таки, оно от user. Типа есть система а есть уже то, что пользователь над ней надстроил — пользовательские файлы и программы. И вот эти usr уже к системе (UNIX) отношения как бы не имеют.

Согласен. После цитаты POSIX выше я понял, что неверно трактовал понятие файл.

я понял, что неверно трактовал понятие файл.

На самом деле ты нормально трактовал понятие «файл». Как и noc101 выше.

Просто ваше человеческое понятие «файл» лишь частично пересекается с извращённым юниксовым. Юникс по многим пунктам «контр-интуитивен» в своём поведении для нормальных людей.

Кому это нужно не забыть отключить, причём так, что критически важно? Тем 0.01% от юзеров дебиана, т.е. двум-трём пользователям (а скорее ровно 0) на Земле, которые почему-то хранят важные данные в /tmp долгосрочно?

Обожаю подобного рода аргументы. А как на счёт обосновать подобное изменение? А то получается так, что вот нам захотелось и мы сделали, а зачем сделали - не мкажем. Живите с этим.

Кому это нужно не забыть отключить, причём так, что критически важно? Тем 0.01% от юзеров дебиана, т.е. двум-трём пользователям (а скорее ровно 0) на Земле, которые почему-то хранят важные данные в /tmp долгосрочно?

Долгосрочно? А если я создал файл, усыпил комп и уехал в отпуск на неделю. Приехал и продолжил работу. Это уже долгосрочно или еще нет?

Никто не хранит важные данные в /tmp — он не для этого, даже по названию.

Он для временных файлов. Представь, что ты работаешь над анализом логов. Нужно грепнуть логи из /var/log, потом над результатами нужно поэкспериментировать по разному. Соответственно, нужон временный файл. Ты его создаешь в хомяке? Я создаю всегда в /tmp. Тем более, после того как /tmp в памяти а хомяк нет.

Обожаю подобного рода аргументы. А как на счёт обосновать подобное изменение?

Это к дебианщикам. Ну и к Поттерингу наверное тоже. Я не стою на позиции, что это изменение нужное. Я стою на позиции «нечего делать из мухи слона». Раньше надо было кипешиться, когда systemd внедряли целиком — вот там были серьёзные изменения. Это фигня какая-то мелкая.

Долгосрочно? А если я создал файл, усыпил комп и уехал в отпуск на неделю. Приехал и продолжил работу. Это уже долгосрочно или еще нет?

Ну, по сабжу — ещё нет, потому что неделя = 7 дней, а 7<10.

Он для временных файлов. Представь, что ты работаешь над анализом логов. Нужно грепнуть логи из /var/log, потом над результатами нужно поэкспериментировать по разному. Соответственно, нужон временный файл. Ты его создаешь в хомяке? Я создаю всегда в /tmp. Тем более, после того как /tmp в памяти а хомяк нет.

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

для чего нужна директория /tmp по смыслу.

Тоже не всегда было понятно это дрочево.

Для pid\sock файлов есть вполне себе православный /run. Промежуточные большие файлы каждая программа сама в состоянии решить где хранить и когда удалять, вот например zip\gzip. Для временных мелких файлов есть shm, для мусора есть null.

Я представляю вой госбездельников (да и не только), когда их очередные «Электронные кабинеты работника бла-бла-бла» будут вылетать как минимум с авторизации, потому что на серванте кому-то вздумается прибить /tmp/session_abcd1234etc по таймеру, ахахаха. А то и чо похуже делать.

а не логичней ли сразу на диск тогда, без tmpfs?

А зачем мелочёвкой hdd нагружать? Обычно там мало. Ну и если ssd, то особенно незачем.

Так, погоди! У тебя что, Арч что ли?

Просто я в таком случае даже не знаю, как бы тебе так намекнуть… Ты, это… cat /usr/lib/tmpfiles.d/tmp.conf сделай что ли…

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

Если бы только в /tmp лежали гигабайты. Но там обычно меньше сотни мегабайт. Да и если бы гигабайты. Сам не мерил, но где-то слышал, что даже tmpfs+swap всё равно быстрее, чем та же ext4. В общем для компиляции рекомендуют.

/opt как раз нормально, для всякой сторонней ереси. А вот от /usr и /sbin давно хотели избавиться.

Если до этого события не открыл, данные недоступны, и в каком месте это говорит, что файл неудалён.

Не, если машина с 64гб оперативки имеет риск пика памяти до 150%, то и своп должен быть соответствующий. Не для десяти же вкладок браузера там 64гб ставили. Безотносительно скорости, своп это в первую очередь способ впихнуть невпихуемое и уже потом всё остальное.

Я стою на позиции «нечего делать из мухи слона».

Тогда к чему это

Кому это нужно не забыть отключить, причём так, что критически важно? Тем 0.01% от юзеров дебиана, т.е. двум-трём пользователям (а скорее ровно 0) на Земле, которые почему-то хранят важные данные в /tmp долгосрочно?

было? Понимаешь, у пользователя есть настроенная система и она просто работает. Теперь, благодаря необоснованным изменениям, его система потенциально сломана и он пишет об этом.

Это вот именно так и работает, что вводятся бесполезные изменения, которые что-то ломают у небольшого числа пользователей и касается это не только дистров, но и ядра в частности. И вроде получается, что у условных 99.9% пользователей всё работает, а проблемы остальных никого не волнуют.

Причём, знаешь, что огорчает больше всего? Что изменения не решают никаких проблем. Вот серьёзно. Я поиском по лору пробежал и не смог найти тему, чтоб кто-то жаловался на то, что в /tmp закончилось место. Из чего я делаю вывод, что даже если проблема и была, то она не имеет массового характера.

Это фигня какая-то мелкая.

Угу. Настолько мелкая, что пришлось вносить изменения в такие пакеты, как tmux и openssh. А всё ради чего(2)?

Это к дебианщикам. Ну и к Поттерингу наверное тоже.

Раньше надо было кипешиться, когда systemd внедряли целиком

Так с ними всё ясно стало именно на этапе пропихивания системд. И данная тема - ещё одна копейка в копилку.

P.S. Что будет следующим шагом? Сканирование памяти и вызов free() для памяти, которая была выделена, но долгое время не использовалась? Так что ли?

Вот если бы существовала некая ФС именно для временных файлов, сразу созданная для хранения файлов в оперативке (условное сверхагресивное кеширование) с возможностью настраиваемого ленивого сброса на диск только тогда, когда свободная оперативка начинает поджимать.... А так приходится всякие костыли колхозить.

Или можно bcache в такой режим настроить?

А, ну так правильно, у тебя free = 94g = 73.4%. Т.е. у тебя даже не нашлось дискового кеша на всю эту память, ты реально купил в 4 раза больше чем можешь занять.

И вот вообще паралельно сколько у тебя там хардов в рейдах понапихано, какой у тебя ссд с системой? Вот от него и бери 10%.

SATA SSD

ну да, разница будет

На десктопе например банальное расположения кэшей в оперативе делает интерфейс системы и приложения более отзывчивыми. Иногда даже очень сильно https://bugs.kde.org/show_bug.cgi?id=487043

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

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

при наличии современных быстрых дисков tmpfs становится менее нужен или вообще бесполезен, там где он сильно ускоряет, он оказывается не совсем применим из-за того, что наблюдается противоречие между целями программы делающей запись fsync и подкладыванием ей tmpfs. а программы, которые так не делают, они и так работают на ssd быстро.

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

Тогда к чему это было?

Да я вроде процитировал, на что отвечал, и по ссылке «ответ на комментарий» тоже всё верно переходится.

Причём, знаешь, что огорчает больше всего? Что изменения не решают никаких проблем. Вот серьёзно.

В целом согласен.

Угу. Настолько мелкая, что пришлось вносить изменения в такие пакеты, как tmux и openssh. А всё ради чего(2)?

В них было добавлено по одному файлу с одной строчкой. Причём я не понимаю, зачем. В арче, например, нет таких файлов, и всё работает. Может тут дело в том, что в дебиане старые tmux и openssh, а в апстриме уже давно нет проблемы, ради которой вносились изменения — не знаю.

Вот если бы существовала некая ФС именно для временных файлов, сразу созданная для хранения файлов в оперативке (условное сверхагресивное кеширование) с возможностью настраиваемого ленивого сброса на диск только тогда, когда свободная оперативка начинает поджимать…

Ты изобрёл tmpfs + swap.

На что же он тебе намекает?

Что ты с ним накосячил в особо извращенной форме, так что большинство пользователей даже не поверит в возможность такого косяка.

а почему существует /usr/sbin/ я даже знать не хочу. это fhs вводит какие-то совершенно бестолковые понятия

fhs штука очень старая и не константная. Её старые версии вполне себе простыые, понятные и логичные. А вот то что над ним накрутили всякие красношапки и прочие Поттеринги... Ну да, теперь мы имеем /usr/sbin/ и даже /usr/local/sbin/. Или имеем целых 2 специальных папки для монтирования накопителей, /mnt и /media, но накопители какого то хрена монтируются к чёрту на кулички.

И зачем на машине с 64 гигами делать своп в 64 гига?

редхат рекомендует если нужна гибернация свап полтора объема озу, поэтому я сделал свап 96. но гибернацию наладить не смог.

Не, я изобрёл tmpfs + swap одной сущностью, нечувствтельную к своп-трэшингу и не создающую лишней нагрузки на kswapd. И там ещё можно неплохо поиграться быстрым отбросом кеша для оптимизации снижения записи если памяти мало, и надо вот это убрать из оперативки а вот это достать.

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

наблюдается противоречие между целями программы делающей запись fsync и подкладыванием ей tmpfs

Ну мне лично наплевать на чьи-то там цели. Я делаю так, чтобы мне нравился конечный результат.

мы можем у субд выключить fsync и она будет работать со скоростью tmpfs. или мы можем разместить данные субд на tmpfs.

Да, это кстати интересный момент, который я забыл пояснить.

У меня философия такая: все что пишется на диск должно действительно оказаться там, а не висеть в памяти. Монтировать диски с флагом sync конечно жестковато, но количество грязных страниц (dirty_bytes) у меня ужато на минимум до условной сотни мегабайт, а dirty_background_ratio вообще = 0.

Плюс тома на btrfs монтируются с флагом flushoncommit, что повышает надежность, но тоже негативно сказывается на производительности записи.

Как ты можешь считать файлом random? Или Null

А я их и не считаю. Это устройства не имеющие границ и объёма, да и некого атомарно фиксированного содержимого у них тоже нет.

Или памятью?

Если натянуть сову а глобус, то дамп памяти хранящийся на планке памяти как раз имеет признаки файла. Только вот никто с ней не работает как с файлом.

Или устройством физическим?

А почему нет? Вот как раз /dev/sdb прекрасно (ну ладно, не прекрасно а довольно медленно) открывается в nano, не то что в хексэдиторе.

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

1. потому что tmpfs лишняя сущность. ядро и так кеширует данные с диска в памяти согласно каким-то своим правилам. этот механизм уже есть

2. чтобы при перезагрузке (независимо от причины) продолжить работу с временными файлами

3. потому что паттерн использования такой. я например /tmp/ вообще редко очищаю. там много хлама и делать cd и ls мало толку, я просто помню нужную поддиректорию. иногда удаляю всё целиком

# du -sh /tmp/
29G	/tmp/