И что из того? Эти самые большие блоки она будет стирать или нет?
ТСу важна не средняя скорость записи, а максимально возможные задержки. Именно от них зависит требуемая глубина буферизации, которая у него отсутствует почему-то.

Понятно, что стирать она будет, т.к. для записи это делать придется. А вот когда она это будет делать и сколько она будет после стирания перемещать данных и есть вопрос, определяющий задержки и среднюю скорость записи. Я имею в виду то, что для запись новых данных идёт в рамках открытого блока в новый ("стёртый" или "свободный") блок. При этом изменение места записи приводит к закрытию текущего блока и результирующему переносу неперезаписанных данных из оригинального блока в частично записанный новый. В идеале, если новый блок был полностью перезаписан, то переносить ничего не нужно, а достаточно закрыть блок, стереть его старую копию и работать дальше. При этом, теоретически, операцию стирания можно было бы запустить в параллель в остальными процессами.



Я думаю, что средняя скорость записи тоже важна. К тому же величина задержек, на мой взгляд, так же связана с организацией хранения данных на карте. По крайней мере об этом говорит мой практический опыт.

У SD-карт набор команд не теоретический, а практический. Не видел такой команды в SD-спецификации, которая позволяет запустить стирание некоего блока параллельно со стиранием/записью других.
(Если Вы таковую знаете - назовите её).
И вообще - где все эти операции перемещения/перераспределения/...? В SD-карте? Вы уверены? Где блоки разного размера и выравнивание износа? Вы не путаете с какими-то другими типами flash-памяти?
Из спецификации SD:

Вот и всё. Пишет - блоками, стирает - секторами. Сектор состоит из SECTOR_SIZE блоков. Эти значения заданы константами в CSD и для каждого там только одна константа.
Правда есть поле ERASE_BLK_EN - разрешение стирания блоков. Но это также относится ко всем блокам карты, а не к некоторым, расположенным в начале или конце. Т.е. - сектора и блоки по всему объёму SD-карты одинаковы по времени стирания/записи (при одинаковом износе конечно).
И в спецификации SD я не видел нигде упоминания про какие-то операции по выравниванию износа, выполняемые картой. Какие блоки сказали ей писать, она те и пишет, сама ничего не перемещая.
Вот возможность наличия RAM-буфера внутри SD-карты для буферизации потока записываемых данных спецификация не исключает. Да и протокол обмена с картой имхо не мешает сделать буферизацию потока записываемых блоков в карте стирая и записывая данные по мере их приёма и накапливания в буфере. Но спецификация и не обещает наличие буфера внутри.

PS: Да полезная вещь для ТС - возможно ему нужно выбирать карты с ERASE_BLK_EN=1 и стирать блоками. Блок меньше и его стирание должно быть быстрее.

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

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?
Вот статья 2003 года, отчасти подтверждающая мои слова про наличие механизмов выравнивания износа.

Да я допускаю что внутри там может быть более сложная организация. Я и писал что возможно там есть буферизация потока записываемых блоков (о чём косвенно свидетельствует алгоритм работы команды многоблочной записи).
Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.
Но только - зачем ему оно надо? Тратить ресурсы на более сложную разработку, тратить лишние вентили на весь этот механизм, может их лучше потратить на доп. ячейки флешь и сделать бОльшую ёмкость?
Ведь главная цель изготовителя - извлечение прибыли и уменьшение издержек. И если оно не требуется спецификацией, то может кто так и будет делать, то такие карты ТСу ещё найти надо.


И что? Число циклов перезаписи не говорит, что по достижении этого значения, блок сразу откажет. Это минимальное число стираний которое блок должен выдержать, а в реале может в разы больше выдержать.
Вот я сейчас разбираюсь с регенерацией SDRAM. Так вот провожу испытания - выключаю регенерацию и измеряю сколько данные продержатся без регенерации. По даташиту регенерацию надо выполнять не реже чем раз в 64мсек, т.е. хранение данных без регенерации более 64мсек не гарантировано.
А в реале (заполняю всю SDRAM 32МБ псевдослучайными значениями и через заданное время проверяю всю целиком) разрушение данных наблюдаю только после отключения регенерации на 3-4 сек и более.
Если на 1 сек отключить регенерацию, то данные 100%-но сохраняются.

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:
http://electronix.ru/forum/index.php?showt...32833&st=31
Краткий вывод - от задержек в десятки и даже сотни мс не избавиться, но при правильной организации структуры памяти можно радикально уменьшить их количество.

Чтобы минимизировать задержки при длительной записи на SD нужно при стирании файлов давать команды trim или erase на карту, в зависимости от того, что она поддерживает. В свежем linux при монтировании можно указать ключом (discard) необходимость использования этих команд. При этом существенно улучшается ситуация с длинными паузами, т.к. карточке не приходится переписывать внутри многократно данные, которые на самом деле уже не используются файловой системой. Это не отменяет необходимости использовать большие блоки для записи (лучше по 16 МБ).

Показалась интересной мысль про то что карта тратит время на стирание.
Стёр всю карту CMD32 CMD33 CMD38
Задержки не уменьшились

Припоминаю, где то ещё была опция автоматического стирания блока перед записью, или что-то вроде того. Подскажите, где это было ?

А время стирания не измерили, было ли оно вообще?


ACMD23. Мне не встречались карты, на которых эта команда давала бы реальное ускорение записи.

многократно тема поднималась тут. Сам сталкивался, имел задержки до 400мс. Буфер конечно решает, но размер впрямую зависит от потока.

Около 2с для карты 8Гб

Можно просто считать карту после стирания и проверить.


Ещё раз: Где в спецификации SD говорится, что карта что-то там внутри себя переписывает????
Дайте ссылку.

Дайте, пожалуйста, ссылку, какую спецификацию Вы имеете в виду. Дело в том, что ранее Вы приводили ссылки на текст Part 1 (Physical Layer Specification) и на мой взгляд совершенно очевидно, что внутренняя структура хранения данных карты лежит за пределами того, что описывается этой спецификацией. Поэтому я и хочу понять, в какой части спецификации SD, по Вашему мнению, задаются методы, алгоритмы и структуры внутренних данных карты.




Вот именно ради извлечения прибыли и стали усложняться механизмы обеспечения надёжности, в частности методы выравнивания износа ячеек памяти. Т.к. с удешевлением памяти неизбежно стала падать её надёжность, выражаемая в гарантированном числе циклов перезаписи.



Вы пробовали или только предполагаете работу блоков памяти после заданного числа циклов стирания?
Второй вопрос: поставьте себя на место производителя карт памяти или флешек - исходя из чего Вы будете назначать гарантийный срок?



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

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

FATFS написан неэффективно и чуть что лезет писать в FAT, причём пишет совсем понемногу. Поэтому для оптимизации доступа имеет смысл сделать промежуточный слой доступа к носителю (типа кэша), который будет накапливать эти модификации и потом редко записывать единым блоком. И, кстати, стоит обратить внимание на то, как FatFS сконфигурирован. Надеюсь у Вас _FS_TINY == 0 ?