Еще раз вас прошу не засорять ветку. Если есть что сказать приводите цифры, графики , типы и названия карт.
Например так:


Тут надо обратить внимание, что карта поддерживает режим static Wear Leveling.
Это может приводить к спорадическому перемещению данных из одних AU в другие даже когда идет линейная запись, чтобы статические данные не залеживались в малоизношенных AU.

А вот ссылка на специальный анализатор карт : https://github.com/bradfa/flashbench

Уж поверьте мне, работаю именно с сд-картами несколько лет, на 8 разных контроллерах и платформах, с картами до 2гб и 8-16гиг, типов 10 тестировал на чтение и запись, НО чтоб такое... Ни разу не было! Что-то у вас там не того с программой или интерфейсом МК.

Это можно узнать по каким-то полям в статусных регистрах карты или только косвенно по поведению/бенчмаркам?
В открытом даташите упоминяния этих слов нет...

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

Physical Layer Simplified Specification !?
На 32 Гб картах даже упомянутый анализатор уже ничего не понимает.

Так скажите где описано.

В даташите на саму карту

Прочитал исходное сообщение и не понял - откуда отвечающие поняли, что речь шла именно о SD-картах??? Телепаты здесь всё-таки есть и не в отпуске? :-)
А вообще, по теме: раз автор уже пытается писать свой аналог FatFS (и видно уже вовсю пишет, раз больше не появлялся), то может лучше написать LowLewel-прослойку между FatFS и физикой, которая обеспечит кеширование и распределение износа по всем секторам флешь-носителя (каким-бы он не был физически) при помощи дополнительной ОЗУ и например FRAM-памяти (для хранения таблицы переадресации блоков флешь). Эта прослойка будет работать уже на уровне 512-байтных секторов и написать её проще, чем разбираться со всеми механизмами FAT16/32, а может и других ФС.

Ну хорошо, допустим, но сколько у вас этой ФРАМ?, килобайт, два, макс. 10... И много-ли толку от этого будет, тут нужна кэш как минимум на несколько блоков фат, а это уже только ОЗУ, соотв. гемор с питанием на случай его внезапного пропадания и т.п.
Уж если нужно так увеличить кол-во перезаписей, то придется разориться на SLC флеш, ибо гарантируют >100000 перезаписей одного блока.

А если это CF или даже MS, то что-то принципиально меняется? Вряд ли речь идет о xD-Picture или SmartMedia

А у нас на дворе что - 90-ее до сих пор??
Мы в своих устройствах уже много лет используем FRAM на 32кБ, сейчас уже используем и на 256кБ (обратите внимание на большую 'Б').
А есть микросхемы FRAM и большей ёмкости, да и не говорил ТС ничего про бюджет и размер устройства, может он сможет и неск. микросхем впаять?
И во FRAM я предлагал хранить таблицу переадресаций блоков FLASH, которая будет обновляться при каждой новой записи в любое
место FLASH. Кеш я не предлагал туда писать, но если есть необходимость - и это можно.
К тому-же ничего не мешает обойтись без FRAM. Если целевая FLASH, используемая автором (о физической природе коей мы ничего не знаем), имеет достаточную (и известную заранее скорость записи), то эту таблицу переадресации и кеш можно хранить в ОЗУ и, имея хорошо работающий монитор питания, скидывать по его сигналу в эту же самую FLASH. Тогда время жизни накопителя будет зависеть ещё от кол-ва выключений питания устройства (выключений питания после сеанса работы в котором были записи в ФС).
Конечно - если этот FLASH-носитель у ТС съёмный и предполагается возможность вытаскивания его и втыкания в чужую систему, то тут будут проблемы.

PS: Да, прочитал ещё раз исходное сообщение - похоже ТСу именно это и нужно (возможность работы в винде без доп. костылей). Тогда своя таблица перемещений отпадает...
Ну или пересматривать ТЗ....

В первом же сообщении ТС именно это и написано:

Уже заметил....
Возможно тут имеет место быть плохая работа с заказчиком. Есть такой тип заказчиков, выставляющих неадекватно высокие требования и чтобы было только так как они хотят.

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