> Это понятно, что умеют. Только на ПК такое не прокатит.

По простому да: USB readers непрозрачный bridge, не являющийся MMC HCI, послать команды в карту не получится.

Зато одноплатники с линем - запросто. Любая десятибаксовая байда на allwinner, малина или что там - mmc host до кучи. Чуть не дешевле ридера, бонусом еще эвон сколько мозгов, проц, линух... а если ЭТИМ захочется косплеить mass storage, взять железку с USB-OTG да вгрузить в лине g_mass_storage. Будет весьма стебный "картридер" - с линухом на борту.

> Андроид для SD тоже не использует (может, но там FAT-only).

Вероятно в FAT никто не сподвигся его запатчить на тему TRIM деаллоцированых регионов.

> Для mmc наверное может использовать, но у меня вот лежит старый андроид-телефон и там
> discard ни у одного раздела нет...

А у меня - нормальные одноплатники, с нормальным линухом (Debian) и MMC HCI. Там все это прекрасно работает. Т.е. я зацепил btrfs с trim - и, вот, работает. Их недавний async discard был очень в тему, ибо у sd/mmc trim не особо быстрый как команда бывает.

Технически большая часть карт и eMMC реагируют на TRIM как и SSDшники, т.е. затирая нолями регион. В регистрах дескриптора карты (их в лине с MMC HCI можно посмотреть) даже обычно прописано нечто что видимо является по смыслу "eraseblock".

> В итоге они конечно умеют, но похоже никому ненужно.

Отучаемся говорить за всех (с).

> был высажен в 0. MMC сначалу вроде бы была Read-Only, но
> когда dd на чтение вернула error, блоки были перезаписаны, книжка вернулась
> к жизни. И на всякий случай была перешита из полного образа.

Это видимо некий взбрык контроллера. А так у SD/eMMC есть специфичные фичи, можно затребовать ReadOnly явно. При том это односторонняя операция, карта должна запомнить это. Это не снимается, карта будет навечно readonly по спекам. Наверное сервисными операциями с контроллером можно это сшибить попробовать - но это вендорспецифично и без гарантий. По спекам вот так.

>> Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки
> ИМХО, это побочный эффект.

Это
1) Разгон скорости записи, не надо ждать завершение тормозного Erase т.к. его асинхронно в фоне заранее сделали.
2) Намного больше маневрового места для GC/WearLeveling и оптимальнее их работа.

> Правильно. Без TRIM не получится контролировать износ страниц flash.

И запись - особенно если писать много - тормознее. Если pre-erase не сделан, значит, вы подождете выполнения ERASE при записи. Слив скорость записи на этом. Есть разница во времени
"data xfer -> ERASE -> program" VS "data xfer -> program". На одну (тормозную!) операцию меньше при записи.

> В случае TLC и более поздних - это прям критичная операция. И если износ
> страниц становится для контроллера приоритетом, то куда и что контроллер пишет...
> вообще непонятно.

Да оно во всех в общем то - весьма желательно. По ресурсу и скорости.

> Я на конкретном способе/алгоритме не настаиваю, но очевидно, что какой-то способ увеличения
> ресурса есть.

FTL делает что-то типа copy-on-write, у него есть логические адреса, а есть физические, и есть таблицы которые описывают соответствие. FAT сейчас может быть в этом физическом блоке флеша, а при следующей записи - в совсем другом. И так далее.

А одна из причин по которым дергать питание на ходу чревато это апдейт вот этой таблицы. Если она слетит (это то что и называют транслятором) - результат "не очень", все блоки перетасованы и рекавери этого "по простому" уже не вариант. Некоторые датареки умеют в перестройку транслятора, но они know how не любят делиться, они этим зарабатывают.

> ещё года 2-3 проработала. Недавно опять свалилась в RO, пока непонятно
> чем всё закончится. Но думается мне, что увеличение резервной области позволило
> бы перешивать флешку пореже...

Это вполне вероятно. Потому что уход в readonly - типовая реакция на окончание резервов для ремапа.

И вот еще что, если вы делаете полный ERASE с стиранием bad block markers, вы несколько нарываетесь ибо сыпучие блоки могут таки стереться нормально, но надолго их не хватит, они осыпятся - и довольно быстро отминусуют собой резерв. Это стоит понимать. В ряде случаев вообше ERASE может за 2-3 попытки прокатить. Но если это так - ячейки блока уже "не в форме" и так можно нарваться на потерю данных. В случае RAW NAND эта механика более видна, но это и делает нанд очень гиморным :)