> Я прекрасно понимаю что оно даетну давайте проверим
> И хотя железо быстрее не станет, во первых - программы быстрее "отпускает".
Нет, всё с точностью наоборот. Если кто-то просит fsync или буфер наполнился, то все программы блокируются до полного(!) опустошения буфера. Отсюда и брался 12309: никакой софт не мог писать вообще и ждал. Что быстрее запишется 3-6-15GB (дефолт - зависит от размера памяти) или 100MB прежде чем другие программы смогут писать?
> часть операций может быть оптимизирована.
Нет, всё с точность наоборот. Современный сторадж (по сути любой не IDE) имеет контроллер и внутреннюю память. Внутри он сам реорганизует данные так, как надо, оптимизация на стороне ОС ничего не даёт т.к. контроллер о ней не знает и вообще плевать хотел и всё переделает. Более того, современный Linux с nvme ничего и не оптимизирует, он просто валит всё "как есть" "по трубе вниз".
> Актуально для всяких темпфайлов и подобной байды, которые могут всю свою короткую жизнь провести в буфере и вообще не успеть записаться.
Это неактуально вообще. Во-первых это супер-редкий сценарий в принципе. Во-вторых размер временных файлов несущественный (порядок мегабайтов почти всегда) для современных дисков, например nvme.
> Если у вас слетит питание в середине операции записи - вы всяко поимеете определенные проблемы с этого
Тут да, мысль верная, но до верного вывода вы не дошли. Потерять 3 гига или потерять 30 мегабайт это разного порядка проблемы.
> Это какого года сведения, на минуточку?
Последняя публичная дискуссия об этом была по-моему в 2017, через 5 лет после появления nvme. Я ещё раз повторю: ваши тезисы "больше буфер -> выше производительность" и "чем быстрее девайс, тем больше можно иметь буфер" в корне неверные. По сути с большим буфером становятся быстрее только синтетические бенчмарки и всё! Все реальные задачи тормозят. Есть несколько исследований на этот счёт. Помню одно непубличное от разрабов Postgres (но вы можете найти как они после всех тестов советуют УМЕНЬШАТЬ буферы, а для ДБ, сами понимаете, производительность диска решает всё), его ещё публично воспроизводили ребята из IBM, оно было в паблике, возможно найдёте.
> Опять же - в каком году? Что такое 100 мегов для скоростных SSD на сверхбыстрых интерфейсах? Хоть тот же NVMe - сто мегов не заметит даже.
Ещё раз, дело не в скорости диска. Дело в том, что с дефолтами первые 1.5 гига записи диск просто простаивает (background_ratio/background_bytes) ещё не достигнут. Т.е. ядро не пишет на диск в момент интенсивной записи софтом. По этой и другим причинам производительность падает.
> Btrfs в общем случае тоже использует ту механику страничного кеша. По поводу чего прекрасно живет даже на роутере с 64 метрами оперативы
Нет конечно. Вы, как я и говорил, понятия не имеете, как оно работает: https://github.com/pop-os/default-settings/issues/111
> И btrfs уж точно не "драйвер стоража".
Разве что для тех, кто не писал драйвера для ФС