> Откуда ты знаешь?

Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. Ну вот такое у меня хобби есть. Это как раз примерно то самое что в SSD нынче суют.

> Без TRIM контроллер не запускает механизм очистки,

Спасибо, Кэп.

> а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС
> и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди
> обнуления/записи контроллеру не нужно.

Ты такой умный что пипец. Правда при всем этом ты не знаешь что то что именно сделает контроллер по поводу TRIM - вообще не специфицировано. То-есть, это всего лишь хинт контроллеру что мы не юзаем данные блоки и их можно разгрести. Когда именно и как контроллер это изволит разгрести и что он сделает по этому поводу - вообще его дело. Он может например подождать минимальной нагрузки на накопитель в фоне разрулить.

> Запись ФС будет происходить без задержек кроме той,
> что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру
> блока SSD).

Опух? Erase block флеша как правило нынче 512Кб и поди еще попробуй угадать границы оного, да еще с блоками переменного размера которыми ты тут так понтуешься. И кстати erase - это весьма длительная операция. Если программирование страницы может быть довольно быстрой процедурой (и то не всегда), то erase блока запросто растягиватеся на многие миллисекунды. Максимальное время обычно указано в даташите на микросхемы флеша.

>> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать
>> операции записи, и запись медленнее происходит.
> Вывод из посылки, которая не верна.

Вполне себе верна. Чем больше пространства для маневра - тем реже приходится судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. Собственно грубый прототип того что получается ты и так увидел на забитом под завязку томе. А тут похожая логика: размазывание записи - по сути вариант CoW получается. Ну и общие свойства стало быть похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его не видно в емкости накопителя которая написана на упаковке, а вот место в чипах памяти оно жрет. Производителю не нравится напаивать больше памяти при том что цифра на упаковке не увеличивается. Ведь хомячки покупают гигабайты :)

> Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется,

В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. Тогда стирания не будет, только программирование страниц. И чем больше места не занято - тем больше пространства для маневра: может получиться воткнуть желаемую запись куда-то в уже очищенные страницы. А если trim нет то постепенно все придет к схеме когда "проблема решается по мере возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а что нет. По поводу чего и скорость записи просядет, и возможности оптимизации размещения записей у контроллера будут откушены по полной программе.

Хинт: если бы все было так как ты говоришь, никто не стал бы геморроиться с реализацией команды TRIM от которой и так нет эффекта. По-моему, это даже детсадовцу понятно? :)

> но из-за малого размера блока ФС, содержимое блока SSD каждый
> раз помещается в кэш SSD, делается запись в заранее обнуленные страницы,
> но так же И делается "усиление записи" для всех остальных страниц
> блока SSD, не участвующие в хранении данных записываемого блока ФС.

Еще раз: что такое "усиление записи"? Нельзя ли выражаться общепризнанными терминами? Ну там read, erase, page programming, ... ?

> Контроллер SSD записывает данные на флэш только поблочно,

В общем случае - постранично. У флеша 2 вида блоков.

> способствует большему износу ячеек памяти, чем если бы блок ФС совпадал
> с размером блока SSD.

Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - часто будет тереться ДВА блока там где хватило бы одного. Ну а с блоками переменного размера ты еще и никогда не сможешь выровнять ФС так чтобы ее блоки совпали с блоками флеша. Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. В случае с TRIM это не такая уж проблема, т.к. erase не будет и будет только программирование страниц по количеству записываемого. А вот без него логика контроллера свалится в черти-какой штопор. Грубый прикидон мне подсказывает что экстенты + trim будут работать не в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы и по объему желаемой записи и ... все :). Юзание TRIM порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий вообще каждый раз.

> Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных
> ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек.

Ресурс ячеек прежде всего уменьшается от ERASE'а блоков на каждый пук. А если пространства для маневрирования и удовлетворения текущего запроса нет - поневоле придется дергаться и тереть блоки на каждый пук. Правда просто?

> TRIM тут никаким боком не поможет, кроме как увеличит скорость записи.

Он даст больше пространства для маневра: может получиться оформить операцию записи как только программирование страниц. Без стирания вообще. Откуда и рост скорости. И меньшая деструктивность процесса в среднем. Грубо говоря, повышается КПД логики SSDшного контроллера.

> Ресурс флэш тратиться на освежение, которого можно избежать в принципе —
> сделать размер блока ФС равным размеру блока SSD.

Ну да, ну да, и угадать размещение блока ФС чтобы не попало на границы блоков флеша, когда будет на ровном месте тереться 2 блока вместо 1 просто потому что блок ФС угораздило же лежать в обоих. А блоки переменного размера окончательно испортят компот, сделав это начинание невозможным. Не говоря о том что тратить блок 512Кб на файлик в 1Кб размером будет достаточно обидно.

> Контроллер SSD по команде ФС записывает данные на флэш только поблочно,

Минимальной единицой записи в флеш является страница. Есть более крупные блоки - группы страниц, стирание в 0 происходит только большими группами. Ты о каких из блоков?

> при этом имеются в виду не блоки ФС (хотя и они тоже
> в этом процессе участвуют), а более объёмная по отношению к ФС
> величина — блок SSD, имеющий размер 512 килобайт.

Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с 512-Кб блоками так чтобы они совпали с секторами флеша - ты, натурально, выиграешь по скорости записи. Практически - флаг тебе в руки это сделать в ZFS с ее блоками переменного размера и смотри не удавись от жабы когда файл 1 Кб начнет жрать 512Кб блок, если это вдруг получится.

> Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть
> очищенные страницы в блоке, то их не нужно предварительно обнулять (это
> сделал GC после команды TRIM), скорость записи на них высока. Однако
> в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются.
> Но они тоже будут перезаписаны (освежены),

Проблема в том что ты вроде бы начинаешь вкуривать что такое read-modify-write, но совершенно забыл про wear leveling. Который в общем случае постарается сделать запись в другое место флеша чтобы размазать запись. И вот тут возможны варианты. В случае когда юзается TRIM - есть свобода маневра и можно просто оформить это как программирование страниц. А вот если trim нет - с чистыми блоками небогато. И вот тут придется разгребать хлам по полной. Попав на дополнительные процедуры read-modify-write и erase "просто потому что это надо хоть куда-то записать, черт возьми". А когда нет того что хотелось - придется лепить из того что есть и распихивать ну хоть как-то. Как оптимально - всем понятно. Поэтому собственно и сделали trim ;)

> так как контроллер SSD записывает данные на флэш только целым блоком
> из оперативного кэша. Это называется "усилением записи".

А я думал что это называется read-modify-write.

> Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как
> не тайна за семью печатями.

С одной стороны, прикольно что до изена стало доползать как выравнивать фс на блоки флеша. С другой - я бы посмотрел как ты ZFS на блок флеша выровняешь :D.

> GC работает с отдельными страницами.

Логично - он расчищает блоки чтобы можно было их erase'нуть без потери данных, перегруппируя страницы в другие блоки, сдвигая их так что они без "прорех" из неактуальных данных. Вот только у этой логики отбирается вся свобода маневра когда trim нет. По поводу чего оно натужно дергается в попытках выкроить свободные блоки "ну хоть как нибудь" а не разрулить запрос "как оптимальнее". Trim это основательно лечит.

> весь блок SSD — мы говорим для условия, когда размеры блоков
> ФС и SSD совпадают.

Кроме размера должны еще и границы блоков совпасть. А вот это уже не самое простое требование. А с блоками переменного размера - ну ты понял, да? :)

> для модификации его блоков. В случае с совпадением размеров блоков операция
> очистки производится для всего блока SSD сразу, данные записываются большими порциями
> — нет оверхеда на подчистку отдельных страниц.

Если забить на часть бреда, вот этот кусок даже в принципе верен. Вот только это весьма идеализированный случай. И маловероятно что ты нечто такое на ZFS вообще сможешь изобразить.

> Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных.
> ;) Выяснится, что GC может и не успевает за подчистками.

В клиническом случае может и не успеть. Вот только в этом случае SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс не больно огромный, порядка нескольких тысяч циклов всего. Так что (в идеальном случае) несколько тысяч записей объемом с накопитель и усе, он начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям.

>  Заодно и проверить ресурс флэшатины под обеими ФС. ;)

В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора менять SSD" :). А в менее суровых случаях имхо ФС с trim выиграют.

> Ты действительно веришь, что GC после своей работы с блоком разделяет блок
> на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки
> SSD и складирует их куда-то?

Естественно, на то и GC. Иначе он мог бы нарваться на тупые и смешные ситуации например когда в каждом блоке засрано по странице. Так что полную страницу записать уже нельзя. Вроде бы места дофига а записывать некуа. И чего?

> Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой
> перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)

Ну нифига себе у тебя технологии, если запись о трансляции блока занимает столько же сколько сам блок.