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

Почему бы не держать все эти tmp и свопы на том HDD?

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

Я создаю всегда в /tmp. Тем более, после того как /tmp в памяти а хомяк нет.

CrX

Я тоже создаю в /tmp, естественно, если он временный.

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

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

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

Это как с ~/.ssh, который отказываются перенести в XDG (и тут редкий случай, когда правильно делают).

Да, разрабы openbsd правильно кладут на этот xdg.

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

согласен.

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

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

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

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

Свап-файл это костыль. Незачем менеджеру памяти зависеть от особенностей файловых систем. Раздел это просто: устройство такое-то, сектора с такого по такой (да, и никаких LVM, они тоже всякую муть добавляют).

Выше уже написали что такое файл согласно POSIX стандарту. Не вижу смысла спорить. Там довольно четко и правильно написано)

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

Эм, ну, собственно, да. Подвеску изобрели для того, чтоб кочки можно было таранить. Хочешь страдать объезжаниями - бери авто без неё, оно наверно дешевле. Не хочешь тратить ценный ресурс ссд - сложи его в сейф а на компе используй hdd.

В оригинальных юниксах /usr/home а не /home например - и часто на том же разделе что и /usr.

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

Нет, в иерархию они не отображаются. Удаление файла из директории действительно удаляет все его связи с этой директорией и его больше в ней нет, если только его заново там не создадут. А lsof показывает закешированные где-то (но уже неверные) пути.

что над ним накрутили всякие красношапки и прочие Поттеринги... Ну да, теперь мы имеем /usr/sbin/ и даже /usr/local/sbin/

Это всё никак с шапкой и Поттерингом не связано, если что.

Юникс — интуитивно понятная операционная система. Пользователь помучается-помучается да и поймёт интуитивно, что надобно прочесть документацию.

Арч в том числе. Это печально, конечно. Оно удаляло мне файлы а я даже не замечал.

Да? Возможно. Но мне известно только два ПО которые используют /etc/opt/<package>.

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

что есть «всякой сторонней ереси»?

в fhs есть термин «add-on software», при первом столкновении он не понятен, а выяснять, признаюсь, я не стал.

вот что это?

• ПО которое не является критической частью ОС но устанавливается установщиком ОС?

• ПО которое не устанавливается установщиком ОС, но идет в комплекте с системой, на CD 2?

• ПО от того же вендора, но не в копмлекте с системой а приобретаемое отдельно?

• любое third-party ПО, в том числе пакетированное?

• любое непакетированное ПО в том числе от вендора?

Из того, что у меня установлено из сторонних rpm пакетов, судя по /etc/opt/, только один пакет посчитал себя «add-on software».

Честно говоря, не вижу большой разницы между программой (C, shell-script) и пользователем работающим в интерактивной сессии. Почему из shell-скрипта можно создавать временные файлы в /tmp а из интерактивной сессии нет?

С другой стороны, если трактовать стандарт строго и файл существует лишь до конца работы программы то туда даже из shell-скрипта писать нельзя. :)
Согласен, вопрос спорный.

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

Какого? Что какой-то скрипт в цикле выделяет память? Что в этом такого странного, что они не поверят? Текущая память – один из самых распространённых багов в софте.

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

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

Твой интеллект меня пугает, чел.

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

Зачем?

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

себя надо экономить а не железо

Имя - не атрибут иноды, а односторонняя ссылка на неё.

BSDшники, которых мы заслужили…

Имя файла - это никакая не «ссылка», а цепочка байт, наряду с байтами прав доступа и таймстампами, которая хранится в файле каталога. А индексируется она в файловой системе по уникальному номеру - inode.

Имя по иноде узнать можно только полным перебором всей структуры.

Умница. Теперь погугли в янедксе, почему в bsd sort есть опция -f, а в GNU sort - -U. Без ответа на этот вопрос, дальнейшего диалога не будет.

… Открытый файл не получится удалить…

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

… А закрытый файл уже мусор.

Это очень спорно.

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

Вообще, их делают обычно в /run

Тогда о чём вообще речь в /var/tmp?

Прикол именно в том, что с такими заходами разница практически теряется.

Ты явно на приколе, дядь. Речь идёт не об экономии ради экономии, а о разумной экономии.

Я чота так удивился, что ажно залогинился, дабы ответить. 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.

Ты просто плохо знаешь историю UNIX и поэтому путаешь то как было с тем как оно сейчас.

Вот почитай рассказ одного из отцов основателей: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp…) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).

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

Да ладно. Важные для общей производительности данные вообще не там живут, а сидят в оперативной памяти. Своп и временные файлы априори не для этого.

Моя позиция по этому поводу уже высказана в том сообщении. Я крайне не люблю dirty pages. И считаю, что дефолтное поведение ядра неправильно, как минимум для десктопа.

С ним особенно весело, когда например копируешь что-то на медленную флешку, и файлы с точки зрения юзерспейса «копируются» почти мгновенно. Непрошаренный пользователь на этом моменте может просто дернуть флешку, ведь программа-то репортовала успешное завершение копирования. А на деле при попытке ее отмонтирования ты еще пол часа будешь ждать завершения записи без какой-либо видимой индикации процесса.

И к сожалению никакого четкого решения проблемы нет. Программы в юзерспейсе максимум могут дергать fsync, но гарантий нет, большинство софта это не делает. Тот же обычный cp это не делает. rsync делает только с явным указанием флага --fsync (хоть и на множестве мелких файлов механизм жутко неоптимален). С другой стороны так же ничто не запрещает программам произвольно дергать fsync на всякий мусор.

Получается что ты либо сидишь с большим объемом dirty pages, но страдаешь проблемой выше плюс рискуешь потерять важные данные на внезапном отключении/краше системы. Либо сводишь их на минимум, но на диск начинает писаться вообще все и сразу.

Так как, насколько я знаю, просто нет механизма разделения страниц на «важные» (что нужно записать сразу) и «неважные» (запись которых можно отложить). Поэтому получаются пляски с выносом ненужного в tmpfs.

Спорный согласен) имхо конечно, но кидать в темпы и работать там, затея не очень. А теперь вот очевидно, что не очень) Хотя работать в темпах дольше 7 дней, явно еще то извращение и никто в здравом уме не будет.

Ага, вот только тот же systemd срёт туда

Что ж поделать, такова его природа ;-) А все «разумисты» давно перешли на труЪ-дистрибутивы из вот этого списка:

• простой поиск по Distrowatch с опцией «Init software: Not systemd»

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

Нигде не пишут. В силу того, нигде не документировано это. Так исторически сложилось… и как кто хочет эту историческую слаженность интерпретирует)

Но в ранних Unix системах папка usr была папкой для пользовательских файлов и программ.

А сейчас используется для общих программ и файлов.

В итоге, кто как хочет, так и считает))

Умница. Теперь погугли в янедксе, почему в bsd sort есть опция -f, а в GNU sort - -U. Без ответа на этот вопрос, дальнейшего диалога не будет.

Яничегонепонял. В моем sort нет -U. А чем -f особенная? Просто регистронезависимая сортировка. При чем тут файлы?

Вместо того чтоб спорить и позориться, лучше бы изучил вопрос.

В директориях хранятся ссылки на иноды. Права доступа и таймстампы в директориях не хранятся - они хранятся в инодах. То есть права доступа это свойство инод, а вот имя файла - это имя ссылки на иноду.

уникальному номеру - inode.

Инода - это не индекс, а описание файла. Имя в это описание не входит. Индекс - это inode number.

GNU sort - -U

Не знаю причём тут программа для сортировки текстов, но ты опять то ли ошибся то ли наврал

$ sort -U
sort: неверный ключ — «U»
$ sort --version
sort (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <https://gnu.org/licenses/gpl.html>.
Это свободное ПО: вы можете изменять и распространять его.
Нет НИКАКИХ ГАРАНТИЙ в пределах действующего законодательства.

Авторы программы — Mike Haertel и Paul Eggert.

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

Сейчас да. Изначально нет. Изначально в usr хранились пользовательские программы и файлы для общего пользования. Но это давняя история. Сейчас это уже Unix System Resource

имя файла - это имя ссылки на иноду.

Либо я не понял тебя, либо ты не прав.

Название файла хранится в файле директории.

Примерно так это выглядит

Имя файла Номер инода Тип записи

file1.txt 1234 Обычный файл

Не похоже на ссылку, а вот на связку да.

Ты неправильно помнишь историю. да я перепутал. сейчас вот ради интереса почитал.

When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp…) and wrote files to those new directories because their original disk was out of space.

Интересно. То есть уже на той первой машине в /usr были системные файлы в дополнение к user директориям.

When they got a third disk, they mounted it on /home and relocated all the user directories to there

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

Это не возражение тебе, а просто наблюдение: мне кажется, нельзя сказать что /usr - это изначально пользовательская директория. То есть она возможно была в чьем-то там воображении, якобы до установки второго диска, в некую одну машину. Это были произвольные названия и случайное расположение файлов еще на этапе разработки, то есть до того, как unix увидел свет.

Ну вот, «file1.txt» это ссылка на иноду 1234. «Тип записи» не во всех файловых системах хранится, он там для удобства что б в иноды не лазить постоянно, об этом в man readdir написано (d_type).

Сам же файл - это инода, в ней указаны и права доступа, и таймстампы, и список блоков где он хранится, и всё остальное. На файл (иноду) может указывать как несколько имён-ссылок из разных мест (хардлинки) так и ни одного (удалённый но не закрытый файл, fsck такие называет unref и складывает в lost+found).

Это не «этапы разработки», это эксплуатация системы с доработкой по ходу возникновения новых потребностей. В разные времена было разное расположение файлов.

Это типа борьба говноадминов с говнокодерами (или наоборот)?

Единственные правильные кодеры - кодеры systemd. Теперь только им дозволено что-то безопасно создавать в /tmp и /var/tmp.

/tmp - файлы, которые хранятся от перезагрузки до перезагрузки. Именно это и подразумевает «data stored in /tmp may be deleted in a site-specific manner» или другие критические ситуации, типа переполнения памяти. /var/tmp - файлы как бы временные, но сохраняются после перезагрузки. /run, /var/run - файлы сервиса, которые никому кроме systemd и геморрою админов не интересны.

«Временные файлы» - на самом деле нихера не временные, а как правило - разделяемые. В смысле кем-то созданные, но используемые из под разных пользователей. Типа сокетов. Прикол в том, что кроме создателя их никто не может удалить.

Охрененного счастья админам принёс systemd, когда перестали работать по крайней мере apache и postgresql по локальным сокетам. А это ж, сцуко, суперразработчики решили, что вот с этого момента /tmp для сервиса должен быть изолированным, причём по умолчанию. ДЛЯ СЕРВИСА билиат! С которым по сокету могут общаться… да все. Не, понятно, что надо прочесть хренову портянку документации (пресловутые «портянки» bash нервно курят в стороне) по systemd сервисам, создать новый, поменять один параметр. И… А вот на х^я ли это нужно?

моем sort нет -U

Не sort, а ls. Можно было догадаться из контекста.

Вместо того чтоб спорить и позориться, лучше бы изучил вопрос.
Инода - это не индекс, а описание файла. Имя в это описание не входит. Индекс - это inode number.

DMR:

«Index» is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the the i-number is an index in this array, the i-node is the selected element of the array. (The «i-» notation was used in the 1st edition manual; its hyphen became gradually dropped).

inode - это просто целое положительное число, дурилка ты картонная.

Хотя ладно, признаю. За каким-то рожном, и структуру узла файловой системы стали называть именем переменной - индекса. Всё таки этот ваш юникс - натуральная помойка.

Ну вот, «file1.txt» это ссылка на иноду 1234.

Это никакая не «ссылка». Файл директории содержит табличку как тебе показал noc101, где каждому имени файла сопоставлено целое число - индекс файла в табличке файлов.

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

Ну вот, «file1.txt» это ссылка на иноду 1234.

Я тебя понял. Тут надо сначала выяснить, что для тебя является ссылкой.

В моем классическом понимании, «ссылка» является отдельной сущностью.

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

А слово node в index node тебе не намекает, что это всегда была эта самая node?

Зато связано с аналоичными любителями делать всё то же самое, только странно и нелогично.

Конечно же намекает. Я ровно так и думал:

int f(struct node *nodes,  size_t size)
{
    ...
    int i;
    ...
    for(int inode = 0; inode < size; inode++)
    {
        ...

Где inode, очевидно int, который индекс к node.

Но видишь, ли оказывается кто-то когда-то настолько обкернелхакелся, что в мануале вместо простого человеческого «file system node» написал «i-node» в значении «the i-node is the selected element of the array», и пошло поехало.

Особенно забавно, что я даже когда-то всё это помнил, но эти знания оказались настолько важными и востребованными, что уехали сначала в zswap, потом в swap на nvme, потом в file на ssd, потом в tar.gz на HDD, потом на болванку CD-ROM’а, диск - в коробку, коробка - на дачу, на даче коробка в сарай в самый дальний задний угол. И только срач на лоре пробудил в бессознательном древнее зло.

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

Что какой-то скрипт в цикле выделяет память?

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

Твой интеллект меня пугает, чел.

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

Ты знаешь, почему канализационные трубы такие толстые? Не потому что там нескончаемые потоки, а чтобы переливов не случалось.

...всё таки нам может понадобиться некий избыток свободной памяти! Или всё таки нет? Ну ведь у нас же есть оом-киллер, в случае чего просто пришибём что нибудь, ну а что тут такого?

Зачем?

Потому что твоему могучему интелекту должно быть известно, что самый говённый ссд один хрен превосходит твой рейд как по линейным скоростям, так и по иопсам. И вероятно ты даже осилишь прочитать что такое ftl, как он работает и зачем ему мог бы пригодиться резерв свободных блоков.

Да тут вообще то обсуждвается вопрос «какую из двух железок нагрузить сильнее для достижения лучших результатов».

В случае ссд/tmpfs крайне сложный вопрос что есть разумная экономия.

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

Где inode, очевидно int, который индекс к node.

Я то в ФС сварщик ненастоящий, но всегда думал, воспринимал inode именно как запись в таблице. Именно запись (node) а не ее индекс. Вот открыл Таненбаума — там он тоже записи в таблице называет inode.

Полагаю, задумка там была такая. Есть список, каталог, реестр (англ. index) файлов. Вот запись в этом каталоге и есть index node, что значит «запись (node) в каталоге (index)». А не смещение/адрес/индекс в этом самом каталоге.