> Для флешек/SD это очень важно, для первых SSD тоже была важно.

Ну да. Лучше не проверять насколько фирмвара SSD с этим справится.

> Но думаю так - если флешка заявила сектор 512 байт, то самое
> главное в прошивке учтено: последовательная запись нескольких секторов приведёт к перезаписи
> одной страницы.

Тем не менее, если скажем 4K-блок ФС попал на пересечение страниц (в идеале тоже могут быть 4К, хотя у разных флех разное, это самый простой пример) - ради 1 блока придется ворочать 2 страницы. А в фабричном формате - одну. Откуда и фэйл с скоростью random write.

> Тогда ресурс снизится ну раза в 2 (вместо одного
> блока будет перезаписано 2; fat-таблица в любом случае с примерно одинаковой
> интесивностью перезапиывается, а размер кластера в FAT большой.

На самом деле что угодно может быть - очень зависит от логики фирмвари. Производителей и версий оной легион, и их поведение совпадать не обязано.

> ИМХО, для многих современных SSD-контроллеров ВСЕ (!!!) данные проходит через remap

В флеш вообще нельзя произвести запись без remap. У флеша есть "erase" и "program" - там вообще нет такого понятия как перезапись. При том erase - огромным блоком, у современных 4 мега и более может быть. А program - постранично, но после записи очистить можно только всем скопом - для eraseblock'а. Это связано с топологией кристалла, стирать сразу группой экономичнее по проводам и транзисторам, ячейка меньше площади занимает (по сравнению с произвольно адресуемым EEPROM где стирание и прогрммирование возможно для каждого байта отдельно). Поэтому совершенно любая штука вывешивающая якобы работу с якобы секторами делает нехилую трансляцию by design. А слет транслятора - довольно фатальный факап.

> (после записи часто переносится/"уплотняется", потом ещё стирание явно идёт и т.д.),

Любой флешовый девайс примерно так работает: у флеша eraseblocks немеряные, а страницы очистить можно только стиранием всего eraseblock. В продвинутых контроллерах несколько каналов и они любят интерливинг операций на эн каналов для скорости. Это дает старт понятию EraseGroup, когда операции ворочают для скорости сразу с несколькими чипами - параллельно на всех каналах. Erase довольно медленная операция, это разгоняет скорость в N раз. По той же причине trim важен - позволяет GC фирмвари почистить eraseblocks в фоне, не нарываясь на паршивую скорость операции ERASE при записи - оно сделано заранее.

Так что для более продвинутых SSD может иметь некий смысл попытаться выравнять партишн и /boot раздел на вот это вот. Угадать разумеется сложно, но круглые юниты типа 256 мегов имеют шанс (физически это Eraseblock * channels). Это чтобы в случае внезапного слета питания по крайней мере без партишна не остаться.

Ах да, снимать питание без информирования накопителя нельзя ни в SSD, ни в флехах, ни даже в SD картах. Потому что они вот могут гонять фоновые операции. И слет питания в этот момент может вызвать конкретный факап. Хорошие контроллеры обычно это переживают, но - логгят факап, накручивая счетчик. И если что, это повод послать в гарантийке, видимо. А более поганые девайсы могут от необдуманного сдерга транслятор потерять и вот это - знатный облом.

> поэтому выравнивание по границам секторов уже бессмысленно, данные никогда не попадут
> на диск как тебе хотелось ;)

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

>> Когда контроллер будет RMW на копии фата гонять, питание слетит, это записаться не успеет
> На флеш (raw flash) есть очень надёжный механизм коммитов.

Там есть Erase и Program. Им самим по себе вообще все вон то неведомо. Остальное делается фирмварой и уровнем транстяции.

> Всегда можно побитово перезаписать 1->0, 1->1 и даже 0->0.

Не так! В совсем "классическом" виде: ERASE сбрасывает все биты (всех страниц) большого ERASEBLOCK в 1 (стертый флеш читается как 0xFF). PROGRAM позволяет сделать из 0xFF то что хочется, но только если это переход 1 -> 0 (0xFF можно превратить во что угодно). Обратно только стиранием всего ERASEBLOCK и всей оравы в несколько мегов. Гранулярность PROGRAM и возможность дозаписи страницы - варьируется. В NOR с интерфейсом шины можно даже отдельные байты или word'ы (в терминах шины) програмить, иногда даже несколько раз, если нужное значение достигается изменениями 1 -> 0. Некоторые вещи типа JFFS юзали такое "допрограммливание" для служебных целей и разгона эффективности.

В NAND шина иная - прямой байтовой адресации нет, поэтому же из него нельзя код напрямую запускать, так что работа юнитами с страницу как минимальный адресуемый юнит. И PROGRAM идет для страницы (обычно несколько кб, например, 2...8, плюс-минус). Можно ли (до)програмливать страницу несколько раз - от чипа зависит.

Современные MLC делают это чуть сложнее ибо в ячейке более 1 бита. Но идея остается, ERASE сносит большой блок в дефолтное состояние, PROGRAM шьет то что на самом деле хотели, но вот трюки с побитовой дозаписью в уже програмленый регион - там отваливаются, в силу нетривиальности обсчета для много битов на ячейку (появляется соображение как уровни заряда в биты мапятся и какие transition валидные) и многие чипы это не поддреживают.

ERASE FAIL: после ERASE не все биты блока "1". В этом случае будет ремап на блок из резерва.
PROGRAM FAIL: после PROGRAM не совпало с записываемым.

Иногда стертое состояние может быть инвертированым, и в вон тех переходах 1 и 0 стоит поменять местами. Скажем для TRIM специфицировано что очищеный сектор - "все нули". Это по минимуму делается тривиальной инверсией.

У современных емких флех еще много загонов на тему read disturbance, того факта что нельзя писать повторяющиеся паттерны в соседние ячейки из-за взаимовлияния и проч, так что фирмвара иногда делает "регенерацию" почти как DRAM, может требоваться рандомизация паттерна, чтобы BER не зашкалил, и проч.

> Нельзя только перезаписать 0->1, тут придётся сначала вычитать страницу,
> потом её стереть, и только потом на место единичек записать нужные данные ;)

На самом деле все чуть сложнее. См. выше. И стереть придется ERASEBLOCK в котором дочерта страниц. А страница - минимально адресуемый юнит - у NAND шина не может байты "напрямую", там адрес и данные по очереди.

> Это свойство как раз и используют при реализации ремапов и оно глючит ну ооочень редко.

Я видел минимум несколько разлетов транслятора в флехах и SD картах. SSD менее халтурно сделаны и ведут себя поприличнее.

> Если производитель в прошивке накосячил, или страничка для транзакций померла как раз
> во время ремапа.

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

> На практике, даже начинающие программисты для микроконтроллеров очень
> легко делают надёжный код, используя это свойство флеша. Глюканёт такой код
> только когда помрёт страница флеша.

Так, посмеяться... я умею програмить МК. И програмил простой "flash FS". Так что вы неплохо покапитанили :). Но у МК - NOR, он неубиваемый и адресуемый напрямую. NAND намного хлипче и адресуем в общем случае странично. В МК и вообще NOR иногда тоже бывает page для ускорения операции записи, всей группой байты PROGRAM'ить немного быстрее.

> Там иногда 1%, 3%, ну бывает 5% и 10% максимум (не у
> всех). А хотелось бы больше.

Ну я себе Debian на RAW NAND в немолодой девайсине загнал, там у UBI сколько не жалко, столько и выделяешь под резерв. Но у меня там SLC NAND был - но его 256 метров на все, впрочем, дебиан по моим лекалам занял процентов 50 вместе с 100 мегами списка пакетов (он неплохо жмется).

> При использовании TRIM (или при использовании FS с закольцовыванием как в f2fs/nil2fs)
> ресурс износа примерно выравнивается по всему диску.

Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки, и при записи не надо будет ждать (весьма неспешную) операцию ERASE. Это основательно разгоняет накопитель, да и GC получает больше маневрового резерва и может оптимальнее работать. Без TRIM он не знает что используется и считает всю площадь используемой, мучая некий небольшой маневровый резерв. Что субоптимально по скорости и числу операций.

> Конечно может отдельный сектор умереть и на такой случай ремап 3% - ну прям офигенно много.

Да вот мереть может сразу всем eraseblock-ом (если после ERASE не все биты стерлись, он меняется на резервный). А они здоровые, сильно много резервировать жаба удушит. И да, всего 1 нестершийся бит отправит нафиг всю 4 и более меговую тушку в аут.

> Но по факту страницы на флешках изношены неравномерно, т.к. на диске ФС
> FAT без TRIM и очень быстро укатываются конкретные "горячие" области диска

В UBI даже можно выбирать какая разница допустима. Тут правда стоит сказать что оно в лине только SLC "хорошо" умеет а для MLC его никогда как следует не доделывали так что "translation layer" из него довольно базовый.

> (например, FAT-таблица). Может что-то там и не выравнено по границам erase-block,
> но это уже не так важно (ну в пару раз уменьшится ресурс, см выше).

Основной повод выравнивать на Eraseblock - чтобы вместе с активно кантуемым регионом типа фат не отлетело бы в страну вечной охоты что-то супер критичное типа Partition. У FAT то две копии, и можно из второй починить. Но если у вас партишн попортится - то чего? Ага, у юзера круглые глаза - как это - нет ФС?!

> ещё огого), а у контроллера ремапы кончились! Они все ушли на резервирование
> "горячих областей" диска, а оставшаяся часть имеет ещё ого-го какой ресурс.

Ну оно как бы tradeoff и зависит от степени тупости фирмвари.

> Да, ремап работает! Если бы он не работал - флешки бы умирали
> за неделю ;) примерно как умирают флешки из китая (там видимо
> пара секторов всего для ремапа).

Как альтернатива у меня есть флеха которая просто сыпется по всей площади - не утруждаясь возвратом IO error. Она нормально читается, стирается и пишется. Но через пару недель на полочке заряд утекает настолько что FEC видимо не выдюживает, но io error оно не возвращает. Вместо этого может покормить ФС трухой. Btrfs с DUP (2 копии на 1 девайс) такой подарок стебно чинит, демонстрируя мощь теорвера крутанутого в свою польщу.

> Но тут проблема - на флешках FAT и без TRIM :( Поэтому
> "выровнять" ресурс записи по всей флешке нереально!

SD карты (и eMMC) кстати TRIM прекрасно умеют, почти все. Только надо контроллер MMC HCI для этого. Всякие одноплатники прекрасно это все могут - как и сервисные команды покидать. Равно как и МК (SD еще бонусом умеет работать по SPI, так что минимальный интерфейс позволяющий покидать "левые" команды - 4 провода по сути). У SD есть еще всякие весьма прикольные команды, типа превращения карты в ReadOnly, включая перманентный (это часть спеков SD).

> Сейчас уже есть SSD, у которых начало диска (первые пару гигабайт) имеют
> прям очень большой ресурс записи. А остальная часть - ну сколько
> там выдал TLC/QLC...

Могут поставить SLC + TLC/QLC но пойнт вот именно того все же не совсем очевиден. В SLC еще бывает модно хранить служебку + кеш (SLC быстрее пишется). А потом уже в фоне отливать с SLC на MLC. Т.е. запись быстро ухает в SLC, выдерживающий дофига перезаписи, а потом уже распределяется в хлипкий MLC с leveling и проч.

> Думаю, что у флешек подобный механизм используется очень давно как раз под
> FAT-таблицы. Но видимо не всегда помогает ;)

Это все очень фирмварозависимо. И в общем то обычный FTL норм с FAT должен справляться, для него это в общем то очередные записи. К тому же такое допущение все нагибает если юзер отреформатит в exFAT/NTFS/...