[Ruslan1 17]

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

 

 

Вопрос №1

как можно посчитать степень износа, если предположить что :

размер стираемого блока-128К

размер используемого диска- 16GB, то есть 125К блоков

время жизни блока - 1000 стираний

 

Тогда в худшем случае (на каждое обновление переносится целый блок):

количество обновлений = 125К блоков * 1000 стираний = 125M = 125e6

 

при количестве обновлений 1 в секунду: получаем время жизни карточки 125e6 секунд, это 1446 дней.

 

Это правильная оценка?

-------------------------------------------

 

Вопрос: №2

Что именно я должен считать обновлением, чтобы определить насколько сильно я изнашиваю эту карту?

 

Ведь нельзя считать таким обновлением просто добавление информации на то место сектора/страницы/блока, которое до этого было 0xFF ?

 

Я считаю, что обновление- это изменение, которое требует стирания блока. Я прав?

(Хороший пример такого обновления- это запись в FAT при изменении файла)

-------------------------------------------

 

Вопрос №3:

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

Как этого можно избежать? Почистить неиспользуемые сектора в FF? Дать команду стирания чего-нибудь там?

Есть какой-то способ помочь карточке, иначе ведь совсем катастрофа с ресурсом?

 

У меня, кстати, получается именно эта проблема: я писал по 40 секторов в секунду. Если предположить что контроллер карточки каждый раз занимался переносом блоков, то получаю ресурс 36 дней, что очень похоже на мой случай (у меня вышло немного больше, но может и ресурс блока немного больше чем 1К стираний).

-------------------------------------------

 

Вопрос №4:

Кэширование и запись на карточку большими кусками, скажем, 128К, поможет?

Upd: поиск помог найти вот это, буду копать туда:

Alex11, Jul 14 2014, 22:27

Мы довольно много экспериментировали с SD в разных режимах. Во-первых, там есть команда мультисекторной записи. При этом небольшая пауза возникает только после записи многих секторов (но не факт, что после всех, запрошенных в команде). Кроме того, особенно при работе с не свежеформатированной карточкой, у нее возникают паузы до 0.5 сек на внутренние нужды - стирание блоков и переписывание частично заполненных. Реально помогает только запись блоками по 64 - 128 кБ в зависимости от карты.

[jcxz 243]

(Хороший пример такого обновления- это запись в FAT при изменении файла)

Не факт.

Почему Вы думаете что переназначение по износу делается на уровне блоков стирания, а не на уровне страниц?

Имхо: вполне возможно что карта имеет массив логических страниц, переназначаемых на физические страницы. Когда вы даёте команду "запись в страницу" и контроллер определяет что "поверх" запись выполнить нельзя, то он будет метить физ.страницу, связанную с данной логической как "грязную". И назначать для данной физ.страницы пустую (и неназначенную) страницу внутри какого либо блока. И стираться блок будет только когда всего его страницы "грязные". Естественно тогда необходима или периодическая или по необходимости "сборка мусора", когда блоки содержащие мало физ.страниц связанных с лог.страницами, и много "грязных" страниц и ни одной пустой: все связанные страницы будут перемещены в свободные страницы другого блока, а данный блок будет стёрт.

Тогда при записи FAT пишутся и изнашиваются только занимаемые ей страницы.

 

А как контроллер Флеш поймет, что данные в хвосте блока это мусор, а не данные, которые нужно переносить? Видимо, никак.

Какой "хвост блока"? Блок весь разбит на страницы, чтение/запись на карту выполняется страницами, а значит для карты всё что внутри страниц - полезные данные. И размер блока ведь кратен странице, так что "хвоста" быть не может.

 

Почистить неиспользуемые сектора в FF?

Откуда Вы знаете какое начальное состояние ячеек флешь? Может там FF, а может 00.

[Ruslan1 17]

Почему Вы думаете что переназначение по износу делается на уровне блоков стирания, а не на уровне страниц?

Это только предположение. Просто если оно верно, то мои теоретические расчеты похожи на мою реальность (40 записей секторов в секунду убили флеш за пару месяцев.

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

 

Я с Вами полностью согласен, используемые алгоритмы сложнее (очень неплохо несколько вариантов описаны в упомянутой мною статье). Я просто хочу хоть как-то прикинуть, на сколько чего я должен выйти по записям, если мне нужно, например, 3 года жизни этой карточки.

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

 

Кстати, наконец-то проверил карточки на скорость. Получил скорость записи около 31 МБ/c и чтения 73 МБ/с, вроде бы неплохо (нужно софтинку менять, у этой экран под малые скорости заточен):

[controller_m30 1]

Вопрос №1

как можно посчитать степень износа, если предположить что :

размер стираемого блока-128К

размер используемого диска- 16GB, то есть 125К блоков

время жизни блока - 1000 стираний

 

Тогда в худшем случае (на каждое обновление переносится целый блок):

количество обновлений = 125К блоков * 1000 стираний = 125M = 125e6

 

при количестве обновлений 1 в секунду: получаем время жизни карточки 125e6 секунд, это 1446 дней.

Полностью проверить это допущение займёт всё те же 1446 дней - а это долго.

 

Можно сделать тест на износ только одного блока 128К, но при разных условиях. Понадобится две карты.

Тест 1.

Однократно заполнить все сектора карты данными, чтобы отнять у встроенного контроллера ресурс для перестановки блоков. И "протереть дырку" в каком-либо блоке 128К. Подсчитать количество перезаписей до отказа карты.

Тест по идее получится коротким - около 1000 перезаписей.

 

Тест 2.

Сделать то же самое, но с новой, неформатированной картой, где у контроллера имеется огромный ресурс для перестановок. И попробовать "протереть дырку" теперь.

Предположительно, "дырка протрётся" либо после 125К перезаписей, либо после 125К х 1000. Это будет зависеть от "понимания" контроллером карты что такое резервный блок: тот который просто не писался ни разу (тогда ресурс 125К), или тот который не писался ни разу пользователем (тогда ресурс 125К х 1000).

Возможен ещё вариант - просто 1000 записей. Будет означать, что контроллер не умеет переставлять блоки.

 

В зависимости от результатов можно будет предложить разные варианты использования карты. Например, если будет результат 125Кх1000, то достаточно будет отформатировать карту 16Гб, как будто она 8Гб, а оставшиеся нетронутыми блоки отдать контроллеру для перестановок. В этом случае не придётся вообще ничего менять в ПО.

[aaarrr 69]

Однократно заполнить все сектора карты данными, чтобы отнять у встроенного контроллера ресурс для перестановки блоков.

Думаете, можно отнять? Сложно предположить, что такая ситуация не предусмотрена логикой работы

контроллера. Полный физический объем носителя пользователю недоступен.

 

ИМХО, можно, конечно, провести исследовательскую работу, как в приведенной выше статье,

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

[jcxz 243]

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

Вот именно!

А может у ТС какой-то косяк в алгоритме записи? О котором он не подозревает.

Например: в процессе записи 15-минутного файла многократно открывается/закрывается файл? Или ещё как-то делается обновление записи директории о файле? И вместо одной модификации FAT получается много. Или файл пишется порциями, некратными размеру кластера, со сбросом буферов на диск между порциями?

[aaarrr 69]

...вместо одной модификации FAT получается много

Кстати, первым делом стоит сократить число копий FAT до одной, если их по старинке две.

[controller_m30 1]

Думаете, можно отнять? Сложно предположить, что такая ситуация не предусмотрена логикой работы

контроллера. Полный физический объем носителя пользователю недоступен.

Предложенный Тест_1 как раз и нужен для выяснения этого обстоятельства.

Например в статье Wear Leveling от "Micron" пишут, что выравнивание может быть статическим или динамическим. В первом случае равномерно изнашиваются все блоки, во втором только часть.

Тест_1 может показать 1000 записей (для динамического выравнивания), или 125К х 1000 (для статического).

Тест_2 покажет 125К х 1000 для стат. и динам. выравнивания, или 125К для динам. в случае дорогой подделки, или просто 1000 для недорогой.

Сравнив результаты двух тестов мы и определим, какой вид выравнивания применяется, и что делать.

 

Всё ИМХО, ничего не навязываю, с интересом слежу за обсуждением :rolleyes:

Изменено 31 мая, 2018 пользователем controller_m30

[Ruslan1 17]

А может у ТС какой-то косяк в алгоритме записи? О котором он не подозревает.

Например: в процессе записи 15-минутного файла многократно открывается/закрывается файл? Или ещё как-то делается обновление записи директории о файле? И вместо одной модификации FAT получается много. Или файл пишется порциями, некратными размеру кластера, со сбросом буферов на диск между порциями?

Я говорил про 40 записей в секунду- это я завел счетчик записанного функцией disk_write(), так что я точно уверен что в DMA попадает очередь именно на это количество секторов.

 

Про то что мой косяк- только на это и надежда, свои косяки можно исправить :)

Действительно косяки конечно есть, например самый грубый: практически всегда в SD-карточку из моего кода идет команда записать данные только длиной в один сектор. Хотя внутри все сделано универсально, с использованием CMD25.

 

В-общем, на выходные попробую подготовить несколько тестов в параллель на нескольких приборах, посмотрю кто дырку протрет быстрее.

 

Кстати, первым делом стоит сократить число копий FAT до одной, если их по старинке две.

Да, спасибо за напоминание, у меня их две, по дефолту. Не спасало, млин, ни разу :)

Это хороший и простой метод уменьшить число записей, да и ускорение неплохое.

 

ИМХО, можно, конечно, провести исследовательскую работу, как в приведенной выше статье,

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

Я только попробую потестировать насколько быстро убьется карточка если я буду на нее писать:

1) короткими блоками, по 1 сектору (близко к тому что сейчас имею)

2) блоками по 16 килобайт (удобный для меня вариант)

3) блоками по 128 килобайт (максимально возможный, еще приемлемый вариант)

 

Буду писать как можно быстрее. Если увижу разницу между результатами- это значит есть за что бороться.

 

Карточка будет предварительно полностью забитая данными. С пустой только что отформатированной карточкой любопытно, но непрактично: какой бы результат не был, он мне мало поможет.

 

А "оптимизация работы собственного ПО для снижения нагрузки" уже идет. Хвала Святому Гиту, несколько бранчей позволяют обойтись без каши в коде :)

[jcxz 243]

Действительно косяки конечно есть, например самый грубый: практически всегда в SD-карточку из моего кода идет команда записать данные только длиной в один сектор. Хотя внутри все сделано универсально, с использованием CMD25.

У меня ещё вот какая версия возникла:

Вот мы говорим, что карта имеет wear leveling. Ok - имеет. А как он реализован? Очевидно, что должна быть некая таблица переназначения логических секторов на физические. Когда карта работает (питание подано) эта таблица может находиться (и модифицироваться) в ОЗУ. Но она также должна сохраняться/восстанавливаться при выкл/вкл питания. А в какой памяти её хранить тогда? По размеру она небольшая (таблица), можно в карту включить что-то типа FRAM.

А если она внутри пишется не во FRAM, а во флешь (для экономии)? Тогда можно наверное зарезервировать под это дело много секторов обычной флешь (кольцевой буфер секторов) и, при переназначении очередного сектора, дописывать некую запись. А при восстановлении питания, строить таблицу в ОЗУ на основании этих записей о модификации.

А может быть вся таблица по сигналу "сбой питания" быстро скидывается в какой-то один блок флешь. Но тогда если например карта будет работать так: записали 1 сектор, включили/выключили питание, записали следующий сектор, опять включили/выключили питание, и т.д. И так этот блок флешь быстро протрётся.

Я думаю, что у разных производителей карт, алгоритм работы системы wear leveling может быть построен по-разному и иметь разные преимущества и недостатки для разных режимов работы.

И тогда на одной карте такой режим: запись сектора и вкл./выкл. питания - получится ресурс карты такой же как и без выключений питания, а на другой - ресурс будет значительно меньше.

Поэтому и есть отличия, что дохнут только определённые карты.

[controller_m30 1]

С пустой только что отформатированной карточкой любопытно, но непрактично: какой бы результат не был, он мне мало поможет.

Я только уточню, что карточка должна быть не отформатирована, а стёрта командой Erase (хоть на заводе, хоть своими силами).

 

Идея двух тестов основана на следующем. Есть разница между статическим и динамическим выравниванием. При статическом идёт равномерный износ всех блоков, и это круто - но он применяется в дорогих приложениях, типа SSD-накопителей (при том что ресурс записи у них обычный: 2000-3000 циклов на блок).

А при динамическом - происходит износ только тех блоков, где нет данных (где после Erase ещё не было Write_Data).

 

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

 

А если она внутри пишется не во FRAM, а во флешь (для экономии)?

Может быть. Например в английской Вики (статья про WEAR LEVELING) пишут, что чаще всего, у контроллера карты есть своя флешь, с ресурсом перезаписи 100.000+.

Изменено 1 июня, 2018 пользователем controller_m30