> страница 2kb. Разная у разных флех. У мелких бывает и 1 кб. У очень больших бывает 4. Или ты посмотрел даташт на конкретную флеху и возомнил что только так - вообще везде? Прут меня виндузятники своей непосредственностью. Дикарь с копьем который увидел микроволновку и судорожно пытается втиснуть в свою примитивную модель мира такую неведомую фигню как магнетрон.
> Запись идёт блоком из 64 страниц, а чтение действительно постранично.
У разных чипов флешек число страниц на erase block бывает разным. В мире нет какой-то универсальной константы, описывающей размер страницы или erase block как единственно верные константы мирового масштаба. В лучшем случае у флешек одного поколения они примерно одинаковы. Но это не гарантированно. Лично я в курсе и иных сочетаний. Вон у упомянутых арчеводов например где-то в вике упоминается страница в 4К, 128 страниц на блок. Т.е. 512 К на блок. Подумаешь, в 4 раза присвистнул и указал неоптимальный размер блока. Кстати запись постранично тоже возможна, но с одной большой оговоркой: записываемая страница должна быть чистой. А вот с этим засада. Из-за физических особенностей флеша, стирать его можно только большими блоками. Если в страницу уже что-то записано, ее нельзя стереть отдельно от остальных в этом erase block. Можно закатить erase для всего erase block целиком, тогда все страницы блока очистятся. Отсюда следует что erase для записи страницы требуется не всегда, но в хучшем случае действительно нужен.
Кстати да, питекантроп пытающийся осознать как работают наши магнетроны соверщенно забыл про то что у флеша erase - это отдельная логически осмысленная процедура, являющаяся отдельной сущностью. Trim имеет непосредственное отношение к оной процедуре. Erase это не чтение и не запись в их привычном понимании. Это приведение всех страниц erase-block'а в чистое состояние.
>> А в хучшем случае будет вообще стирание большого erase
>> block (группа страниц, обычно 64...512Кб) - read-erase-modify-write получится довольно
>> масштабный. Нормално так - 512кб вместо 512 байтов перепахать? :)
> Выкиньте свой jmicron в помойку.
Какой еще jmicron? Упомянутый спич является обобщением логики работы всей этой механики вообще. В том плане что по другому это как-то не особо то и сделаешь, даже самый хитрый контроллер будет реализовывать похожую логику и ничего не сможет поделать с тем фактом что флешу удобно работать целыми erase-block'ами или хотя-бы страницами. Выравнивание на erase-block лучше тем что ведет к избеганию ситуации когда контроллеру для всего блока надо будет сделать read-erase-modify-write, чтобы оформить частичную модификацию erase блока во что-то физически существующее.
> В современных накопителях давным давно cow с gc и что там творится в реальности
> знает только контроллер.
Это не отменяет того факта что ему тоже удобнее всего фигачить блоками размером с erase block с правильным выравниванием. Просто потому что даже самый умный контроллер ничего такого сделать с физической природой флеша не может. Он может заныкать от вас служебное действо когда запись менее чем удобная величина ведет к read-modify-(иногда erase)-write, но отменить его и сделать чудо он не может. Trim позволяет реже нарываться на нужду erase при записи, давая контроллеру хинт что если он хочет то может в фоне вон те блоки и почистить, т.к. они не нужны. А erase довольно тормозная операция.
> Любая запись там выглядит как read-modify-write, если пользовать trim есно.
Wrong. Самый удачный вариант ака достаточно большая запись и только в чистые страницы будет просто программированием этих страниц. Быстро и без проблем. Trim нужен как раз для того чтобы дать шанс контроллеру заранее подчистить неиспользуемые блоки и по возможности создать именно эту, самую удачную для записи ситуацию.
> Плюс всё это буферизируется и с отложеной записью, посему на несколько попыток записи
> будет все лишь один read с пачкой modify и одним write
Уважаемый дикарь в попытках осознания процесса работы магнетрона напрочь забывает о том что у флеша есть read, program и отдельная операция известная как erase. Program и erase - две логически дополняющие друг друга сущности, грубо говоря, тягающие биты ячеек в разные стороны (одна в одно состояние, вторая в другое). По разным правилам игры, вытекающим из физического устройства флеша. Program вгоняет биты страницы в те значения которые хочется получить. А вот обратно их вернуть можно только erase'ом всего здорового блока. Если интересно - см. в английской вике, тем вполне дельно разжевано откуда такая странная брейнфакерская логика берется - она вытекает из того как биты хранятся в ячейках флеша.
> в заранее чистый блок. А чтобы чистых блоков вообще не было
> - так это имхо нужно забить весь накопитель к чертям и
> банально писать поверху.
Достаточно чтобы gc вовремя не подсуетился. Тогда ему придется делать erase прямо на ходу и скорость записи просядет, что логично. Trim нужен чтобы этого максимально избегать, выдавая хинты контроллеру что он может уже стирать вон те блоки. Не дожидаясь того момента когда припрет, так что надо бы записать, а чистых страниц что-то нету, так что давайте судорожно расчищать прямо сейчас (а запись соответственно подождет до лучших времен).
> А так, любая передышка, и gc собирает мусор очищая блоки.
Вот только проблема в том что сам по себе gc как-то не очень то и знает - нужен вон тот кусок данных файловой системе, или уже можно его в расход. Вот trim как раз и позволяет gc приобрести это знание и действовать именно так, заранее расчищая блоки. Упреждая ситуацию когда приперло и надо чистить блоки прямо в процессе записи, тормознув запись.
