[Darti 0]

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

 

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

 

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

 

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

 

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

[mantech 36]

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

 

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

 

Уж сколь лет работает куча контроллеров в разных условиях, пока претензий нет :laughing:

 

Я заглядывал в исходники fat fs и ничего лишнего или слишком неумелого не увидел.

 

Вот и я об этом же. В подавляющем большинстве "глюков либы" виноват оказывался тот, кто ее портировал на свое железо.

Либе уже фиг знает сколько лет, "вылизали" ее вдоль и поперек

[aaarrr 68]

Мол 100 лет назад он проводил тесты, которые показали, что если писать в один и тот же сектор, то на ~60 раз сектор "портится" и контроллер карты памяти начинает переносить данные, все это проявляется резким снижением скорости записи.

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

[mantech 36]

что если писать в один и тот же сектор, то на ~60 раз сектор "портится"

 

Это вообще бред полный! Даже на самой дерьмовой TLC флеши и то до 2000 раз можно перезаписывать сектор...

[Johnny81 0]

Ну если заказчик оплатит вам написание и отладку собственного FAT32, то почему бы и нет :)

[AlexandrY 3]

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

 

Да тут есть куча нюансов.

Основной их которых отсутствие точной информации о внутренних алгоритмах работы контроллеров SD карт.

 

Смотрите вот это исследование - https://lwn.net/Articles/428584/

Из исследования кстати следует, что FAT32 это лучшая файловая система для SD карт, но беда именно FatFS может быть в неоптимальных форматировании, записи и кэшировании.

Что в свою очередь приведет к большим интервалам времени (и следовательно энергии) на процесс называемый исследователями карт как "garbage collection"

 

Кстати другой не очевидный вывод в том, что "вылизанные" вдоль и поперек старые FS не могут считаться надёжными на новых носителях.

[controller_m30 1]

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

Могу привести пример Windiws XP, как она работает с картами и обычными флешками на уровне физических секторов.

 

Если к компу на котором стоит XP подключить флешку или картридер с SD картой, и больше ничего не предпринимать - ни открывать файлы, ни удалять их, ни даже не шевелить мышкой - что будет происходить с картой:

1. Винда как положено считает MBR, BS, FAT1, FAT2, и корневой каталог.

2. С целью кэширования считывается тело первого файла, заголовок которого есть в корневом каталоге.

3. Сектор корневого каталога, в котором находится заголовок только что кэшированного файла - переписывается, с изменённым в заголовке полем "дата последнего открытия" (файл на самом деле никто не открывал).

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

 

Если в корневом каталоге 100 файлов, то винда 100 раз перепишет сектора корневого каталога только при первом подключении флешки (или SD карты через картридер) к компу. Если флешку выдернуть и через секунду подключить снова, то и винда снова прокэширует все 100 файлов, и снова 100 раз перепишет инфу в секторах корневого каталога.

 

В один 512 байтный сектор помещается 16 заголовков по 32 байта каждый. Уже 4 подключений картридера или флешки к компу достаточно, чтоб выбрать ресурс в 60 перезаписей сектора (если таковой имеется).

Так что, даже если информация насчёт переноса секторов действительная, то на неё не стоит обращать внимание, т.к. в таком случае все флешки и все SD карты после 4 подключений к Windows ХР - уже давным-давно работают в режиме повышенного потребления, и с перенесёнными секторами корневого каталога :laughing:

Изменено 13 декабря, 2015 пользователем controller_m30

[AlexandrY 3]

все флешки и все SD карты после 4 подключений к Windows ХР - уже давным-давно работают в режиме повышенного потребления, и с перенесёнными секторами корневого каталога :laughing:

 

Да у вас просто вирус поселился в Windows XP.

И давайте уже хотя бы про Windows 7, а то XP теперь днем с огнем не найти.

 

Но в любом случае ваша байка бредовая.

И легко проверяется.

Поставьте Bus Hound и легко увидите что на самом деле читается и пишется в Mass Storage при фтыкании флешки.

[controller_m30 1]

Но в любом случае ваша байка бредовая.

И легко проверяется.

Поставьте Bus Hound и легко увидите что на самом деле читается и пишется в Mass Storage при фтыкании флешки.

Именно Bus Hound-ом это и обнаружено.

Делал USB-регистратор температуры на контроллере, который программно имитирует Mass Storage отформатированную под FAT16, и выдающий данные в виде стандартных файлов *.TXT, *.BIN.

Свойства всех файлов выставлены как read_only, но т.к. само устройство в SCSI-дескрипторах указано с возможностью записи, то винда в заголовках файлов меняет дату последнего открытия на текущую. Обращаю внимание: не дату создания файла, и не дату модификации, а дату последнего открытия файла.

 

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

Bus Hound-ом просматривал обмен компа с стандартными флешками (3 штуки разных фирм), и с картридерами SD карт (тоже 3 разных видов). И на том компе где велась разработка, и на компах целевого предприятия (мало ли чего) - этот нюанс с кэшированием и изменением поля "дата последнего открытия" был одинаковым :laughing:

Да у вас просто вирус поселился в Windows XP.

И давайте уже хотя бы про Windows 7, а то XP теперь днем с огнем не найти.

Проверено и на 7-ке, и на XP. На нескольких разных компьютерах с разной производительностью и комплектацией. Но разрабатывалось под XP, т.к. на целевом предприятии использовали её.

Это не вирус, а процесс кэширования содержимого флешки для быстрого доступа. И меняется только одно поле "дата последнего открытия". Больше ничего.

 

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

Опять же, антивирусники были разные (НОД32, Касперский, Аваст, ещё что-то), но этот процесс везде был одинаковый. И кроме того при открытии файлов с помощью клика мышкой - Bus Hound однозначно показывал что с устройства они не читаются, обращений не было. Т.е. файлы помещались в кэш Windows.

Без антивирусников я не пробовал - может в этом случае действительно не будет ни кэширования, ни модификации заголовков. Может быть, но кто захочет это проверить? :rolleyes:

Изменено 13 декабря, 2015 пользователем controller_m30

[romas2010 1]

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

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

 

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

 

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

 

[AlexandrY 3]

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

 

Знаете, разберитесь там со своей кухней.

Прямо сейчас смотрю в Bus Hound. Никакой левой записи и считывания не наблюдаю.

Антивирус с включенной проверкой съемных носителей стоит.

[controller_m30 1]

Знаете, разберитесь там со своей кухней.

У меня есть опыт, когда Виндовс успешно протестировала обычные флешки и SD карты сотнями перезаписей в день одного и того же сектора корневого каталога - и ни SD карты, ни флешки не вышли из строя в процессе всего времени разработки (чуть меньше года).

Автору интересен опыт тестирования секторов флеш. Я его и привожу. И хоть вирус проводил это тестирование, хоть антивирусники, хоть я что-то там кривыми руками напортачил - само тестирование секторов на многократную перезапись прошло успешно. Что ж ещё надо?

Я и делюсь с человеком практическим опытом такого тестирования. Он именно об этом спрашивал, насколько я понял.

 

Если очень важно, давайте обменяемся сейвами Bus-Hound, и выясним в каких случаях заголовки файлов корневого каталога меняются, а в каких нет. Но автору темы это наверное не важно. Предлагаю в личке продолжить, а то боюсь, мой главный ответ на вопрос автора может затеряться в прениях на эту побочную тему :rolleyes:

Изменено 13 декабря, 2015 пользователем controller_m30

[_3m 4]

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

В качестве аргументов против: энергопотребление с либой выше, чем посекторное.

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

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

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

[AlexandrY 3]

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

 

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

 

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

 

А пока рекомендация такая: поблочным чтением идентифицировать на карте размер стираемого сектора (allocation unit, AU).

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

Также проконтролировать чтобы границы кластеров совпадали с границами AU.

А лучше взять файловую от Micrium, там есть специальное форматирование для SD карт.

[_3m 4]

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

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

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