> Вы вообще не понимаете, как это работает. Кэширование на запись в опертивке
> не даёт ничего хорошего для не IDE дисков.Я прекрасно понимаю что оно дает мне "моментальное" завершение операции (RAM цуко быстрый) а потом оно там где-то в фоне, ядром, но программа уже считает миссию выполненной и отваливает в туман, кроме каких-то специальных случаев. Это делает интерфейс человек-машина неблокирующим. Хоть и ценой требования слива кешей до размонтирования.
> Физическое устройство не становится магически быстрее, сколько в память не пиши.
Зато вместо того чтобы пялиться на заблокированную в операции записи программу она отваливает в туман и можно заняться чем-то еще, а кернел в фоне завершит операцию. И хотя железо быстрее не станет, во первых - программы быстрее "отпускает". Во вторых, часть операций может быть оптимизирована.
Пример: если в RAM улетел файл и его страницы, а потом им попользовались и он уже был стерт, но еще не до конца физически записан - тадам - можно вообще не записывать вон те страницы которые не успели дописаться. И вот тут это уже конкретная оптимизация по времени по сравнению с честной сериализацией операций "сперца целиком записать, потом стереть (например временный файл)". Актуально для всяких темпфайлов и подобной байды, которые могут всю свою короткую жизнь провести в буфере и вообще не успеть записаться.
> При этом имеет кучу минусов: потенциальная потеря данных при сбое электропитания
> или kernel panic,
Если у вас слетит питание в середине операции записи - вы всяко поимеете определенные проблемы с этого. И потеря данных не хучший вариант если файло откатится в старый консистентный вид допустим. Намного хуже если будет полу-перезаписаный файл на inplace файлухе. ЭТО вообще потом читаться и пониматься софтом не обязано.
А так есть тулса sync и соотв системные вызовы, типа fsync где это важно было.
> откладывает запись под нагрузкой до достижения dirty_background_ratio/dirty_background_bytes
> из-за механики последних, лаги при вызове fsync, лаги при дефиците свободной
> оперативки.
Величина лагов определяется соотношением того что висит в буфере и скоростью накопителя.
> Торвальдс (он придумал эту систему) использует 48мб/16мб на своём железе (оно у
> него кстати быстрое).
Это какого года сведения, на минуточку? У него сейчас EPYC и быстрые ссдшники как железо вероятно и вон то на таком сетапе - вообще ни о чем.
> И это хороший выбор, правда я сам после тестов и бенчмарков пришёл к 64мб/32мб
> для dirty_bytes и dirty_background_bytes соответственно.
Эта серия бенчмарков включала себя допустим создание темпфайлов и их стирание - заценить как оно на разных файлухах? Чтобы еще и вон тот механизм оптимизации с отбрасыванием недописанных страниц потестить? :)
> Ещё Торвальдс называет безумием всё, что больше 200мб/100мб на любой системе.
Опять же - в каком году? Что такое 100 мегов для скоростных SSD на сверхбыстрых интерфейсах? Хоть тот же NVMe - сто мегов не заметит даже.
> И его можно понять: причины по которым нам ещё нужны грязные
> странички - исторические, этот буфер активно используется драйверами стораджа (точно знаю,
> что btrfs очень активно использует).
Btrfs в общем случае тоже использует ту механику страничного кеша. По поводу чего прекрасно живет даже на роутере с 64 метрами оперативы - в отличие от ZFS :). И btrfs уж точно не "драйвер стоража".
