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

своп и файл подкачки озу не нужны не при каком количестве ОЗУ

Даже если оперативки слишком мало? 2Gb? 1Gb?

на 256 mb использую linux без свопа и подкачки и искренне не понимаю его предназначения

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

Давно пора.

очистке /tmp и /var/tmp по таймеру по умолчанию

Нахер не надо - обязательно отключу.

Зависит от юзкейса.

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

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

Более того, пойди они другим путём, иерархия директорий UNIX не была бы на столько раздутой, а примерно такой:

/
/dev
/bin
/sbin
/lib
/tmp
/etc
/usr  (домашние директории пользователей)

Было бы только то, что выше и со временем можно было бы отказаться и от /sbin. Например в Xenix /sbin уже не было https://www.youtube.com/watch?v=YUxaLP6bI00 (7:22) Или можно посмотреть на сборки некоторых программ, распространяемые в тарболах. Там примерно та же структура директорий в миниатюре. Согласись, что так было бы лучше.

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

Если нужно «работать» с файлами на флешке, то скопируй их на компьютер и работай. Когда закончишь, скопируй обратно. Заодно страхуешься от случайного факапа единственной копии файла во время редактирования.

Я спутался, коричневый на ноль. Земли там вобще в коробке не было, здание 1970-х годов, тогда земля и нейтраль у электриков были синонимами. Синий в светильниках на корпус светильника, а в коробке болтается.

Квартирная проводка — это отдельная тема, там каждый приходящих мастров знает, что там может быть что угодно, как исходно, при строительстве, так и потом переделано хозяином/проходящим мастером. Квартира — это аналог китайского совсем noname БП, где 3,3В могут быть фиолетовым проводом. А тут здание административное, работал штатный электрик, который трудоустроен на должность электрика, не думаю, что он вобще в курсе про цвета в компьютерном питании.

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

1) внезапно исчезающие временные файлы у программ, что приведет к падению программ или неправильной их работе

2) надо патчить вообще буквально все от прититивных консольных программ до серверов и веб приложух

3) помещать гигабайты временных файл в оперативу тоже такое себе как минимум потому, что большинство компьютеров в мире это все же 4-8 гигов озу. просто напоминаю, что /tmp используют архиваторы или тот же мц, или нгинкс кеш хранит или еще чего. размер волюма с тмпфс катастрофически ограничен даже просто для открытия среднего по размеру архива с дампом в архиваторе или мц.

4) кто-то предложит своп чтоб хранить там файлы из тмпфс, но своп на большинстве современных серверов просто отсутствует по причине

5) периодическая очистка и тмпфс там не потому, что это супер правильно, а потому, что tmpfiles.d не умеет запустить очистку разово при старте ОС и они приделали такой костыль тмпфс с периодическим падением софта на сервере или десктопе.

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

посылаю лучи поноса в тех, кто это придумал и тех, кто это применяет в дистрах.

Сейчас выяснил, что это не работает должным образом. Грязные страницы все равно продолжают использоваться для устройства. write_cache отвечает только за какой-то промежуточный кэш. Короче правило по факту бесполезное получается.

а зачем решать архитектурные проблемы системд

Теперь и файлы в /tmp это уже архитектурные проблемы systemd? А часовню тоже он, да?

tmpfiles.d не умеет запустить очистку разово при старте ОС

А мужики-то и не знали.

   Type Modifiers
       If the exclamation mark ("!") is used, this line is only safe to
       execute during boot, and can break a running system. Lines without the
       exclamation mark are presumed to be safe to execute at any time, e.g.
       on package upgrades.  systemd-tmpfiles will take lines with an
       exclamation mark only into consideration, if the --boot option is
       given.

Я не пойму, ты контраргументы приводишь (не похоже), или вообще не понял что я написал?

Повторю: «один большой диск из нескольких» - это никакой не прорыв, это НЕ надёжно и почти всегда медленнее по сравнению с ручным раскладыванием файлов по нескольких дискам на разных точках монтирования.

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

Можно развернуть мысль? Что-то в толк не возьму, за счёт чего это должно быть медленнее.

Нет. Инода это отдельная сущность, которая может существовать без файла директории.

Файл директории это тоже отдельная сущность, которая может существовать без иноды.

А вот то что ты называешь ссылкой, это часть строки в файле директории.

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

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

Если же два диска независимых то у каждого половина от нагрузки, которую проще в итоге обработать.

Или вот другой пример: положи на два диска два больших файла и читай их с помощью dd в null - они будут читаться почти на максимальной скорости (если не фрагментированы). Положи их на один raid0 из тех же двух дисков - и они начнут постоянно ездить головками от одного файла к другому и всё станет медленнее.

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

Инода не может существовать без таблицы инод. Ссылка на иноду не может существовать без таблицы ссылок на иноды (таблица ссылок на иноды это директория). В чём разница то? И то и то элемент в своей таблице.

У тебя шифт не работает чтоли?

Я не пойму, ты контраргументы приводишь (не похоже), или вообще не понял что я написал?

Повторю: «один большой диск из нескольких» - это никакой не прорыв, это НЕ надёжно и почти всегда медленнее по сравнению с ручным раскладыванием файлов по нескольких дискам на разных точках монтирования.

Это не менее надёжно, чем раскидать файловую иерархию системы по точкам монтирования. Ну вот умер у тебя весь /usr и система встала, что ты будешь делать после замены второго диска? Либо начнёшь восстанавливать /usr из бэкапа, либо начнёшь переустанавливать всю систему. Если у тебя RAID0 или просто каждый последующий диск продолжает предыдущий список секторов, то в случае такого же выхода из строя второго диска ты опять же, либо восстановишь всё из бэкапа, либо полностью переустановишь. Современных требований надёжности, когда с одним умершим диском данные в RAID не теряются, тогда никто не ставил. А вот возможность расширять дисковое пространство и увеличивать скорость доступа к тогдашним медленным дискам была бы действительно прорывом.

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

Так чем больше дисков будут работать параллельно, тем быстрее будет запись и чтение. Давай рассмотрим другой RAID. У тебя 8 одинаковых дисков. Каждый байт данных разбивается на 8 бит, которые записываются на эти 8 дисков по отдельности. В результате параллельно читая по одному блоку данных с одного и того же места каждого диска ты получаешь восемь блоков данных за время чтения одного. То же самое и при записи. Если добавить девятый диск, на нём можно сохранять бит чётности, что увеличит надёжность и позволит продолжать работу после выхода из строя любого одного диска из девяти.

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

А ты пользовался RAID0 хоть раз?

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

тут я конечно прифигел)) Конечно нет. RAID0 будет быстрей всегда чем не рейд. Вообще RAID0 самый быстрый из рейдов. Его как раз чаще всего ради скорости и используют.

З.Ы. Знал бы ты как быстро работает RAID0 на SSD. 10ГБ/сек это нечто. Жаль такая скорость для меня излишняя))

это НЕ надёжно

Почему ты так решил? Надежность это свойство построенной системы.

RAID0 вполне может быть надежным, если удовлетворяет потребностям.

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

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

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

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

Откуда у тебя возьмётся езда головок в разные стороны, когда ни на одном диске в отдельности у тебя нет ни одного полного байта информации? Такой RAID 8 или 8+1 это как один большой диск с одним набором блинов и головок и с увеличенным в 8 раз размером блока, который читается/пишется за то же самое время, как и один обычный блок одного физического диска. Головки будут двигаться абсолютно синхронно. Просадки производительности, по сравнению с одним диском, не будет. Максимум что будет - деградация ускорения производительности до производительности одного диска на большом количестве маленьких файлов. То есть медленее одного диска никогда не будет.

Откуда у тебя возьмётся езда головок в разные стороны

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

Головки будут двигаться абсолютно синхронно.

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

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

С одним конечно не будет, я такое и не заявлял. Но зачем сравнивать с одним, когда у нас их 8? По сравнению с 8 независимыми - будет и большая.

Мы тут всем форумом уже почти 30 лет запускаем левую писанину и смотрим, как она творит что-то не то.

Если у меня какая то левая писанина творит настолько не то, то удаляется к чёртовой матери со всей моей скромной техникой печати. И последним таким монстром, который я встречал, была pinta лет 10-12 назад. И то у меня эту хрень своп на hdd + zram смог пережевать через боль и страдания - ту картинку я всё таки дорисовал. Вторю начинать не стал.

А зачем своп-то нужен?

Например чтобы выполнить опрацию на 12гб оперативки на машине с 8. Или выполнить 4 задачи по 1 гб оперативки на машине с 2 гб паралельно. Или чтобы когда твой емакс выжрет 40гб и попросит ещё, оом-киллер не похерил твоих данных (есть предположение что они обсчитываются больше часа, бежать за дополнительной плашкой памяти ещё дольше, а патчить этот говнокод ещё дольше чем бежать за плакой).

Ну или ещё можно креативно использовать его чтобы в 95% случаев твой диск работал со скоростью оперативки и на чтение и на запись, а в остальных 5% случаев отстал о нормы на 30-50%. Суммарную выгоду ты в теории дожен подсчитать самостоятельно.

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

Как и у одного единственного диска.

И это плохо. Они могли бы двигаться не синхронно, а каждая к своим данным и прочитать их в итоге быстрее, например 8 запросов (если повезёт и они окажутся к разным дискам) выполнять одновременно.

Откуда возьмётся такое везение, когда в классическом UNIX каждый диск - это отдельная точка монтирования? У нас, скорее всего, некоторые диски будут просто простаивать большую часть времени, в то время как другие будут работать с большими объёмами данных в одной из подветок дерева директорий, например в /usr.

А так они (если только речь не о последовательном чтении больших файлов) будут ехать сначала по первому запросу, потом по второму, потом по третьему, в итоге почти в 8 раз дольше, потому что езда головками при рандомном чтении занимает больше времени чем собственно чтение.

Ну вот если собирать диски в один RAID, в котором каждый последующий диск просто добавляет новые сектора (LBA тогда не было, но логически можно представить как будто они были), можно было бы уже в древнем UNIX 70-х годов параллелить такие запросы чтения/записи. Но, как я уже говорил, было выбрано наименее эффективное решение с множеством точек монтирование, то есть просто костыль.

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

С одним конечно не будет, я такое и не заявлял. Но зачем сравнивать с одним, когда у нас их 8? По сравнению с 8 независимыми - будет и большая.

Так мы ведь обсуждаем не универсально идеальное решение для всех случаев. Множество точек монтирования - это наиболее неэффективное решение. Хуже даже трудно представить. Оно лишь простое и сердитое, как и все костыли.

вместо правильного

Как раз первые варианты в итоге и становятся нормами языка и потом ещё закрепляются в словарях и списках исключений. Никто не хочет говорить 3 слова там, где 2 достаточно понятны.

Линейное чтение не превратится в хаотичное чтение-запись мелкими блоками.

Например чтобы выполнить опрацию на 12гб оперативки на машине с 8.

Это какое-то совсем уж экстремальное использование свопа, при котором вся система будет еле живой. Раньше в своп уходили данные, которые сейчас не нужны, но могут понадобиться позже и их обычная загрузка может быть дороже. То есть как своего рода кеш. Например страницы памяти ранее работавших процессов. Причём система делала это почти всегда, а не после окончания физической оперативки. Сейчас оперативной памяти на столько много (гигабайты или десятки если не сотни гигабайт вместо сотен килобайт или нескольких мегабайт в прошлом), что большую часть времени своп висит мёртвым грузом без какого либо использования. При этом в оперативку ещё и tmpfs умудряются запихнуть, а иногда и всю live систему целиком. Поэтому практика отказа от свопа вполне оправдана. Тем более на десктопе.

Однако... Роутеру и правда незачем да и негде.

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

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

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

<Из под стола>Ну да, конечно. То то у меня первые фризы начинают появляться при 150% использовании памяти, а попытка сделать стресс-тест даёт замедление с 6:37 до 7:33 или на ~21%, если почистить искуственно созданное ожидание. А если zswap/zram, тогда ещё меньше. Причём с выходом на 200-250% загрузки памяти.</Из под стола>

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

Ну так и запросы софта подросли! Мало того что эти браузеры обожрались до неприличия, так ещё современное высокоуровневое ПО предполагает, что половину памяти можно просто выбросить на диск и она так и не будет запрошена до завершения работы. Там какой нибудь jit-компилятор, нужный только чтобы запуститься (а по хорошему всё что он делает должно было произойти 1 раз, при сборке из сорцев) или парсер xml-конфига, который может быть сложнее полезного функционала программы.

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

При этом в оперативку ещё и tmpfs умудряются запихнуть

Вот у меня там кеш иконок и миниатюр. Это куда нужней в быстром доступе чем интерпретатор css-темы gtk, который отрабатывает только при запуске приложения а потом висит в памяти балластом.

Тем более на десктопе.

Как раз на десктопе круг задач максимально широк и непредсказуем. Сервер можно сконфигурировать под одну конкретную задачу и подогнать объём оперативки +/- 20%, а если случится какой то непредвиденный пик то это уже целое событие. А десктоп должен быть готов ко всему, от либреофис + музыка (и 512М хватит) до 64-128гб.

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

Всмысле везение? Раскидай файлы так чтоб выровнять нагрузку. Да, не везде такое возможно, но в нагруженных системах как раз обычно возможно. Для этого, возможно, придётся немного доработать логику работы приложения (чтобы оно клало новые файлы в правильные места), а возможно хватит пачки симлинков в структуре его директорий.

Множество точек монтирования - это наиболее неэффективное решение.

Нет, это решение наиболее эффективное среди тех где нет избыточности. Эффективнее него может быть миррор, но он стоит в N раз дороже (впрочем, ради надёжности хотя бы 2х миррор вполне можно иметь). Raid0 же это тупо способ увеличить размер тома не вдаваясь в детали работы приложения вообще нинасколько.

Но ведь тогда ещё и ФС больших тоже не было! Причём с ограничениями начисло файлов вообще и всякое прочее вроде максимальной глубины вложенности. Если почитать ТТХ миниксФС то там вообще не возникает желания объединять диски.

Ладно… Ты вижу не внимательный. Эту тему закроем, не принципиальный вопрос же)

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

А он про что? «Операция на 12гб» не одновременно же все данные запрашивает. Сейчас работает над пятым гигабайтом из 12, остальные могут быть в свапе. Да, прогу хорошо бы переписать чтоб она не грузила в память ненужное, но иногда проще переложить это на ОС.

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

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

Ну так сделай sync или ещё лучше правильное отмонтирование. А то можно файл записать, дёрнуть флешку и попасть на повреждённый журнал/индекс ФС, а проверка решит откатить последние записанные файлы от греха подальше. Ну, собственно как это в винде и происходит с их отключенным кешированием дял флешек. Заметь, чаще чем в линуксах! Там юзеры тупее потому что система не наказывает их за косяки.

скопируй их на компьютер и работай. Когда закончишь, скопируй обратно.

Юзерфрендли... Не, спасибо, я лучше научусь флешку правильно извлекать и всех знакомых научу. Это даже сложнее и дольше, чем после извлечения флешки снова подключить её и проверить.

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

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

Они могли бы двигаться не синхронно

Они в теории даже не могут двигаться синхронно. Диски в рейде работают асинхронно.

А так они (если только речь не о последовательном чтении больших файлов) будут ехать сначала по первому запросу, потом по второму, потом по третьему, в итоге почти в 8 раз дольше, потому что езда головками при рандомном чтении занимает больше времени чем собственно чтение.

Нет. Это не так работает. Как раз всё наоборот. Чем больше дисков, тем меньше задержка. 8 дисков, в 8 раз быстрей отдаст файл, так как одновременно отдаст 8 частей файла.

По сравнению с 8 независимыми - будет и большая.

Как ты это представляешь? )) Как ты один файл раскидаешь на 8 независимых дисков? Вручную?

Это какаято фантазия)

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

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

Зачем мне этим вручную заниматься и что делать, когда свойства моих файлов поменяются? Переустанавливать или переформатировать заново? RAID решаети эту задачу автоматически. Для большого количества маленьких файлов берём один вариант RAID, а для больших файлов другой. Наверное можно их даже объединить, создав некий гибрид. Кажется в некоторых файловых системах даже предусмотрена некоторая оптимизация для маленьких файлов. NTFS? Но я настойчиво прошу не забывать, что мы обсуждаем PDP-11 в далёкие 70-е, у которого каждый из жёстких дисков был размером с дискету из нашего детства, а ведь уже и дискет давно нет.

Нет, это решение наиболее эффективное среди тех где нет избыточности. Эффективнее него может быть миррор, но он стоит в N раз дороже (впрочем, ради надёжности хотя бы 2х миррор вполне можно иметь). Raid0 же это тупо способ увеличить размер тома не вдаваясь в детали работы приложения вообще нинасколько.

На запись миррор не эффективнее одного диска. Большая нагрузка на запись снижает выигрыш в скорости чтения. Основным неоспоримым преимуществом миррора является его большая, чем у одиночного диска, надёжность. Для PDP-11 Raid0 или нечто подобное было бы прорывом. Но я уже устал это повторять. Даже из рассказа Rob Landley видно, что они тупо решали проблему нехватки места на диске. Причём на столько тупо, что тупее некуда. Нет места в /bin? Не беда, у нас есть ещё и директория /usr/bin, которая так же находится в PATH и значит нет разницы куда запихивать очередной бинарник программы или очередную библиотеку в /usr/lib вместо /lib. Примитивно, дёшево, сердито и супер костыльно. Нужно быть совсем уж ретроградом или религиозным фанатиком, чтобы защищать это их тогдашнее решение.

Но ведь тогда ещё и ФС больших тоже не было!

Были, причём гораздо больше их трёх дисков по полтора мегабайта вмести взятые. Вот немного переформатированная цитата третьей страницы из https://adaebabbage.wordpress.com/wp-content/uploads/2011/04/comparison_of_file_systems.pdf

File system: V6FS
Maximum filename length: 14 bytes
Allowable characters in directory entries: Any byte except NUL and /
Maximum pathname length: No limit defined
Maximum file size: 16 MB
Maximum volume size: 2 TB (2 × 1024^4 bytes)

V6FS создали в 1972. Rob Landley описывает события после переезда с PDP-7 на PDP-11 «около 1971 года», как он сам сказал. То есть V6FS уже была как минимум в прототипе, если не в готовом виде. Ведь 1972 - это даже не год создания файловой системы, а год выпуска UNIX V6. Причём именно в UNIX V6 костыль с множественным монтированием, судя по всему, и появился в реальном продакшене. Ну и даже если предположить, что V6FS ещё не было, то что было? Было меньше двух терабайт (немыслимый размер, по тем времена), а на сколько меньше? Один терабайт? 256 мегабайт? У них там было три жёстких диска на три сраные дискеты из 90-х.

Зачем мне этим вручную заниматься и что делать, когда свойства моих файлов поменяются? Переустанавливать или переформатировать заново?

Причём тут переустанавливать переформатировать? У тебя условно есть разделы /mnt/data0 /mnt/data1 ... /mnt/data7, и уже дело приложения (+симлинков) класть на них файлы в нужном порядке.

RAID решаети эту задачу автоматически

Для рандомного доступа - решает плохо. 8 независимых дисков при правильном балансировании нагрузки на них дают восьмикратную скорость от одного диска. RAID0 из восьми дисков - двух-трёх-четырёхкратную, даже последнее вдвое хуже чем отдельные диски.

На запись миррор не эффективнее одного диска.

Речь везде была про чтение. На запись в большинстве случаев можно забить, её доля в общей работе дисков меньше 10%, а где-то около 1%. Да, есть какие-то специальные случаи, но для них можно специальные решения применять.

Ты всё время уводишь разговор в сторону. Перечитай выше о каких годах и о каких дисках идёт речь, а так же о том, какую именно проблему решали Ken Thompson и Dennis Ritchie костылём с множественным монтированием.

Ну так сделай sync или ещё лучше правильное отмонтирование.

Ну это естественно, другого пути без потенциального повреждения и нет. Даже при монтировании в sync режиме.

А то можно файл записать, дёрнуть флешку и попасть на повреждённый журнал/индекс ФС

Да, особенно с учетом, что на флешках как правило простецкая фс типа fat/exfat.

Юзерфрендли…

А писать sync в терминал после каждого сохранения файла это юзерфрендли?

Не, спасибо, я лучше научусь флешку правильно извлекать и всех знакомых научу.

Все хорошо, только проблема с получасовым ожиданием sync/unmount в случае копирования большого объема данных (и потенциальным зависанием всей системы на этот период из-за блока I/O) никуда не девалась. https://lwn.net/Articles/572911/

B «аварийное отмонтирование» может произойти не по вине пользователя, а допустим от потери питания. Но это и внутренних дисков тоже касается. Кстати в той же статье есть ссылка на сообщение, где сам Линус говорит, что текущие умолчания dirty_ratio не были расчитаны на современные машины с большими объемами памяти.

Это конечно полезно, но слишком накладно.

Иметь бэкапы кажется накладным ровно до того момента, как они понадобятся.

Кстати забавно, что в этом сообщении от 2013 года написано:

Today, /tmp is always in RAM

Когда Дебиан только в 2024 раздуплился.

Её увожу не я, а уже увёл тот кто начал рейды обсуждать. Я пишу, разумеется, с современных позиций, потому что кто-то начал их обвинять что «вот мы сейчас из-за них сидим с костылями». Если речь про то время, то всё проще: для раскладывания файлов по дисками не надо было дорабатывать вообще ничего, и ни одной проблемы им это не добавило - значит решение хорошее. А вот «изобретение» рейда это затраты как на собственно путь к идее, так и на написание и отладку кода её реализации. Однозначно отказать.

Все хорошо, только проблема с получасовым ожиданием sync/unmount в случае копирования большого объема данных (и потенциальным зависанием всей системы на этот период из-за блока I/O) никуда не девалась.

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

Если для записи данных требуется условные 20 минут, то ты в любом случае будешь их ждать вне зависимости от того будет ли использоваться буферизация или нет.

Да, только вот при обычном копировании видно индикацию прогресса и оно не вешает систему.

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

С грязными страницами - нифига. Нельзя ничего делать, пока sync полностью не завершится. Нельзя отменить, нельзя диск отмонтировать. Как соответственно и выключить/ребутнуть пк тоже.

оно не вешает систему

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