> Вы как-то не полностью его прочитали.Я его прочитал достаточно для того, чтобы понять что он ни в зуб ногой про erase blocks и erase groups. А 4Кб блоки - полдела. В лучшем случае у NAND страницы и правда 4Кб. Но вообще - бывают и другие размеры страниц. А реально удобный размер юнита аллокации - таки размером с erase group, но он большой. У одного из SSD это 16 мегабайтов аж.
И вопрос не только о перфомансе но и о числе циклов erase.
Если trim не делать, то:
1) При записи накопитель будет делать erase блоков таки прямо на ходу, а не заранее в фоне. А erase требует довольно прилично времени и скорость/латенси записи таки может просесть. Если erase не потребовался - program страницы в 4К и правда будет быстрым. Но с trim эта ситуация будет чаще. Потому что блок превентивно стерт ДО того как он потребовался.
2) У накопителя очень мало места для маневров и оптимизаций. Ну то-есть там есть на такие случаи маневровый запас. Но задействовать под маневровый запас еще и часть поверхности, явно указав через trim что вот эти регионы не используются и их можно безопасно подтереть если хочется - таки оптимальнее. В результате новые записи могут быть разложены более оптимально. А когда места для маневра мало - write amplification же. И чем меньше места для маневра, тем хуже все это будет в среднем по больнице. Когда оптимально раскидать запись невозможно - раскидывается "как получится". Если для записи пары десятков кило придется потереть и перелопатить кучу erase blocks - ну значит вот так. Фирмварь будет упираться до победного, т.к. это лучше чем совсем обломать операцию. Сделав намного больше erase флеша чем могло бы быть и убив уйму времени на GC, если не повезет.
> as long as you TRIM it on boot.
Пусть идет перемычки на ISA адаптерах выставлять с таким подходом, имхо.
