Надежность FAT Опции

[Darti]

Всегда использовал FAT от чена, еще во времена avr, да и сейчас на stm32. Ответственных задач не было, поэтому пристального внимания не уделял, да вроде все работало. Часто видел темы на форуме, мол либа кривая, не работает то или это, но как то лично с проблемами не сталкивался. Сейчас попался заказчик, который стал в позу, мол юзать либу не православно, при этом в винде карта памяти должна обнаруживаться как обычный съемный диск, без дополнительного софта, т.е. фат эмулировать нужно.

В качестве аргументов против: энергопотребление с либой выше, чем посекторное. Но следующий аргумент как то меня поверг в шок. Мол 100 лет назад он проводил тесты, которые показали, что если писать в один и тот же сектор, то на ~60 раз сектор "портится" и контроллер карты памяти начинает переносить данные, все это проявляется резким снижением скорости записи. Для меня этот пункт странный, но пока мне возразить нечем. В качестве предложения, заполнять карту равномерно, стирать только когда целиком заполнится.

Вроде бы и не проблема можно писать посекторно, но когда почитал по верхам про то как устроен FAT32, понял что это будет проблемой. Дело в том, что у меня файлы могут прилетать какие угодно, абсолютно любого размера. Корневой каталог в fat32 не фиксированный, нужно будет вычислять его, чтобы не записать в системные файлы, все фукции - создание/удаление директорий, запись/чтение и создание/удаление файлов мне нужны. Если я правильно понимаю, то по сути то что я напишу будет той же либой чена.

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

Вопросы: Я не предстваляю как можно будет сэкономить энергию, если буду делать тоже самое, что и библиотека, или даже не так - что можно делать иначе?. На чем основаны доводы о кривости этой библиотеки? Точнее даже ее ненадежности.

[_3m]

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

Про энергопотребление бред.

Но следующий аргумент как то меня поверг в шок. Мол 100 лет назад он проводил тесты, которые показали, что если писать в один и тот же сектор, то на ~60 раз сектор "портится" и контроллер карты памяти начинает переносить данные, все это проявляется резким снижением скорости записи. Для меня этот пункт странный, но пока мне возразить нечем. В качестве предложения, заполнять карту равномерно, стирать только когда целиком заполнится.

Информация заказчика верная. При перезаписи в один и тот же сектор после NNN перезаписей однократно в десятки раз возрастает время записи. Предположительно в этот момент контроллер карты обнаруживает несовпадение записанной информации из-за износа флэш и выполняет автоматическую замену сектора на резервный. Если продолжать перезапись того же сектора частота явления увеличивается вплоть до нереалных тормозов (в итоге "убитая" карта виснет при попытке записи). Перед заменой замечен рост времени чтения сектора. В точности данный эффект прогнозировать невозможно так как нет информаии об алгоритме работы контроллера карты. Проверял лично специальными тестами на "убой" сектора и карты. Я проводил тесты давно тогда еще была только slc флэш. Современные карты все на mlc флэш для них NNN превратятся в NN раз.

[AlexandrY]

Про энергопотребление бред.

Информация заказчика верная. При перезаписи в один и тот же сектор после NNN перезаписей однократно в десятки раз возрастает время записи. Предположительно в этот момент контроллер карты обнаруживает несовпадение записанной информации из-за износа флэш и выполняет автоматическую замену сектора на резервный. Если продолжать перезапись того же сектора частота явления увеличивается вплоть до нереалных тормозов (в итоге "убитая" карта виснет при попытке записи). Перед заменой замечен рост времени чтения сектора. В точности данный эффект прогнозировать невозможно так как нет информаии об алгоритме работы контроллера карты. Проверял лично специальными тестами на "убой" сектора и карты. Я проводил тесты давно тогда еще была только slc флэш. Современные карты все на mlc флэш для них NNN превратятся в NN раз.

Так запоминать надо было в цифрах что такое "увеличивается вплоть до нереальных тормозов" с графиками и гистограммами, а так просто сотрясение воздуха и очередной миф.

А пока рекомендация такая: поблочным чтением идентифицировать на карте размер стираемого сектора (allocation unit, AU).
Определить зону с алгоритмом блочного перераспределения памяти. Следить чтобы FAT оказался точно в этой зоне.
Также проконтролировать чтобы границы кластеров совпадали с границами AU.
А лучше взять файловую от Micrium, там есть специальное форматирование для SD карт.

[_3m]

Так запоминать надо было в цифрах что такое "увеличивается вплоть до нереальных тормозов" с графиками и гистограммами, а так просто сотрясение воздуха и очередной миф.

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

[mantech]

Нереальные тормоза это пытаемся записать - получаем зависание карты, при этом чтение работает.

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