Исходное сообщение
"Обновление Debian 12.1" Отправлено leap42, 25-Июл-23 07:43
> Я прекрасно понимаю что оно дает ну давайте проверим > И хотя железо быстрее не станет, во первых - программы быстрее "отпускает". Нет, всё с точностью наоборот. Если кто-то просит 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 уж точно не "драйвер стоража". Разве что для тех, кто не писал драйвера для ФС