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

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

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

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

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

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

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

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

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

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

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

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

SATA SSD

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

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

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

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

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

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

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

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

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

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

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

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

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

согласен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что dirty pages это плохо скорее для сервера и встраиваемой техники, а вот на десктопе лучше наконец то приучить пользователей не дёргать флешки.

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

На самом деле это одна из тех вещей, которые в винде сделаны правильно. Кэширование записи по-умолчанию отключено для внешних накопителей. И можно вручную контролировать для нужных дисков в известном окошке.

Линукс тоже прекрасно отличает внешние диски, и наверное подобное можно для себя провернуть скажем через udev rules, но я нигде не видел подобного из коробки.

Пытаться отучить пользователей дергать флешки довольно бесполезная затея

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

в зависимости от того как спаяна у нас кнопка 0/1 на блоке питания 🥸 мб мне ещё wi-fi и монитор на ночь не выдёргивать из розетки?)

отучить выключать компьютер выдёргиванием вилки из розетки.

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

Error 1011

Что с тобой не так?

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

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

При этом против реализации аналога опции монтирования flush для всех ФС ничего не имею. Однако это имеет и негативное влияние на скорость работы с накопителем, и если буферизация записи на небольшую флешку и правда особой выгоды не несёт, то какой-нибудь переносной SSD, непосредственно с которого пользователи могут работать весь день, замедлять принудительно синхронным вводом/выводом как-то не очень.

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

В любом случае, если кому-то нужно такое правило для udev, то вот:

ACTION=="add", SUBSYSTEM=="block", ATTR{removable}=="1", ATTR{queue/write_cache}="write through"

Только внимательно. Если например в биосе для дисков включен SATA Hotplug, то внутренние диски будут трактоваться как removable, и соответственно правило к ним применится тоже.

Это вообще не относится к обсуждаемому вопросу.

Ну, как не относится…

Раньше компьютеры просто не умели отключать питание программно через ACPI,

А люди^W пользователи всё равно жали на кнопку «питание».

а потом научились.

Почему научились-то?

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

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

Все же хочется видеть настоящий прогресс копирования во время копирования.

Но это всё таки гарантирует тормоза в работе! Буквально откатимся во времена ХР и Висты, а CoW-ФС вообще будут тупить почище 12309 если действие юзера упадёт на сборку мусора.

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

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

З.Ы. Кстати, можно пойти компромисным путём. У файлменеджеров есть окошко операции копирования и вот конкретно для этого окошка можно после копирования сделать sync и чтобы оно не закрывалось пока он не выполнится. А весь другой софт пусть не тормозит.

wifi надо выдернуть раз и навсегда, а зачем трогать монитор я не знаю. Я свой отключаю только если его надо куда-то переставить куда провод не дотягивается (редко). Подсветку матрицы он сам отключает если нет видеосигнала, а видеосигнал гасится компом через полчаса неактивности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К сожалению это не так. Из той же статьи:

If a process is allowed to dirty a large amount of memory, the kernel will find itself committed to writing a chunk of data that might take minutes to transfer to persistent storage. All that data clogs up the I/O queues, possibly delaying other operations. And, as soon as somebody calls sync(), things stop until that entire queue is written.

Короче если какой-то процесс умудряется создавать грязные страницы быстрее, чем они успевают записываться на диск (любой), то очередь I/O забивается и тормозит (вплоть до зависания) всю систему. Так как пул страниц и очередь общие на всех.

Так как пул страниц и очередь общие на всех

Уже давно есть blk-mq и соотв. планировщики ввода-вывода вроде умолчального ныне mq-deadline.

Кстати да, статья старая и похоже написана до появления multiqueue в ядре.

На современных многоядерных системах ситуация должна быть значительно лучше.

На современных многоядерных системах ситуация должна быть значительно лучше.

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

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

sync и так делается по таймеру каждые 120с, так что не каждый раз а только после завершения крупной и важной работы. Можно кстати на панель кнопочку повесить. Рядом с монитором дисковой активности и апплетом извлечения дисков. Ну это если ты по каким то причинам не доверяешь уведомлению «можно извлекать» файлменеджера.

B «аварийное отмонтирование» может произойти не по вине пользователя, а допустим от потери питания.

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

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

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

Я беру ноут, ставлю на него новый ссд, ставлю туда винду для игрушек, начинаю придумывать бэкапы и для этого создаю лайв-флешку. Флешка старая, 8Гб 2010-х годов, на ней просто тупо Девуан в консольном режиме с nm, самбой и десятком утилит. Бэкапы - тупое сжатие диска через zbackup на шару.

Всё это требует написания скриптов и проверки совместимости zbackup'ов, самосборного arm7l одной из первых версий и х86_64 актуального из репы. И вот задача: я беру одно из своих хранилищь (В-дерево из кучи мелких и средних файликов, гига 2-3) чтобы перепаковать пару тестовых файлов из старого в новое и потом обратно и затем извлечь и сравнить контрольные суммы. Копирую с шары, скорость эзернета 10-12 М/сек, скорость физической записи 2,2 М/сек. За счёт кеширования я заканиваю серию тестов ещё до того, как исходное дерево физически скопируется на лайв-флешку.

С тем же успехом это могла быть папка на 1000 фото и видео, которую я гонял бы через редактор или сортировал бы в Дигикаме. И мне было бы глубоко паралельно, это древний юсб2.0 или современный юсб3.2 с флешем, приближенным к ссд.

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

бекапы не делают только те кто ничего не терял