Цитата(WitFed @ Sep 23 2014, 11:20)
А как MTP может хранить данные без ФС ? Всё равно MS-овцы должны цепочки секторов прослеживать на низком уровне, стирания у файлов бывают, фрагментация... Это они навернули дополнительные слои сверху, а снизу наверняка обычная FAT с парой копий главной таблицы кластеров и ограниченным корневым каталогом.
Если запись типа "чёрного ящика", линейно-непрерывная, то можно придумать "линейную" ФС -- циклический буфер на всей флэши, более новые файлы затирают самые старые, текущая позиция ищется на старте по дате самого "молодого", допись нового начинается с неё и т.д. FAT-а (узкого места) нет в классическом понимании, всё равномерно размазано, проблемы в одном месте/времени никак не испортят данные в другом.
Я бы лично "абстрактные" требования отказоустойчивости реализовал дублированием на нижайшем уровне -- последовательным или параллельным размещением тех же данных на разных чипах флэши. У них же есть chip select, можно включить 2-3 штуки сразу и подавать по общей шине данные -- во все выбранные чипы и запишутся ! Потом вычитать быстро по очереди, сравнить (или контроллер сам проверит "качество" при записи и выставит бит проблемы), принять какое-то решение (если ошибка хоть где-то, пометить этот адрес сектора как сбойный на следующие разы)... Лишь бы верхнему уровню, которому хочется читать-писать, была видна "плоская" карта памяти девайса, тогда сверху проблем не будет.
А что за сбои чудятся, каков характер, на практике они бывали, или просто перестраховка ? ОС обычно заточена на возврат кода ошибки, может пометить у себя место неудачной записи в FAT и больше его не использовать.
Можно же на обычной FAT/NTFS открыть 2-3 файла "верхним уровнем" и в них писать по очереди одно и то же с периодическими CRC-вставками блоков, при чтении сравнивая непобитость и беря аналогичный кусок из более целого файла, если в первом проблемы ? У старых винчестеров в секторе на 512 байт было дополнительное поле CRC разного размера, сейчас у флэшей с этим проблемы
FAT-ов можно завести больше, чем обычные 1 или 2, только для SPI-флэшей операция изменения "большого" сектора при "вписи" нового файла, для которого нужно поменять пару 00 на его № кластера, достаточно тяжкая и неэффективно портящая секторы в FAT-области постоянными форматированиями выше среднего.
Современные флэши с гигантскими единицами записи как будто специально придумывали, чтобы затруднить работу с древними ФС
Можно даже "под FATы" поставить специальную флэшь с произвольным доступом на чтение-запись (правда, я про такие не слышал, кроме гипотетической MRAM), а для данных оставить "крупно-секторные"...
Или в FAT-области хранить её инверсию -- тогда "постформатные" FF станут выдаваться наружу, как 00, будут считаться свободным пространством, ОС при записи файлов будет писать туда числа, которые окажется легко "вписать" в FF без перетирания сектора. Но при стирании файлов уже потребуется форматирование
По-любому, FAT требует особого внимания, хорошо её хранить в ОЗУ (видимо, так сейчас и делается), а при появлении признаков пропадания питания успевать сбрасывать в энергонезависимое место. Я нашим конструкторам так и говорил -- можете в конденсаторе где-то накопить напряжения на 1 с работы с флэшью и подать в проц прерывание, если внешняя цепь точно сдохла ?..
> А как MTP может хранить данные без ФС
Надо читать стандарт, конечно, но я на сколько понял, MTP определяет только протокол обмена, но не способ хранения данных. Тем он мне и приглянулся сначала.
> А что за сбои чудятся, каков характер, на практике они бывали, или просто перестраховка
- А у вас несчастные случаи были на стройке?
- Нет.
- Будут.
Из этой области ))
Температура + перегрузки + цена потери данных велика. Поэтому отказоустойчивость было первое требование.
> ОС обычно заточена на возврат кода ошибки, может пометить у себя место неудачной записи в FAT и больше его не использовать.
Ну, если предположить, что в винде отключено кеширование ФС, то, возможно, на это можно положиться.
А вообще, винда в устройство не пишет. Устройство пишет само в себя. А винда потом только считывает. Для этого и эмулируется fat32.
> Или в FAT-области хранить её инверсию -- тогда "постформатные" FF станут выдаваться наружу, как 00, будут считаться свободным пространством
Да, я тоже думал об этом. Вполне можно так сделать. И хранить таблицу FAT во внутренней флеши. Уж если она гикнется... То, можно быть уверенным, гикнулось всё
Изначально была сделана линейная запись. И сейчас работает именно она. Хотя это будет переделываться.
Когда ещё не шла речь о режиме mass storage и FAT-е, мне приходила в голову идея сделать такой алгоритм...
Исходя из того, что необходимый размер данных неизвестен, но он меньше 1 гб, то:
1. Сначала пишется всё параллельно во все 32 флеши.
Когда доходим до конца, то
2. Стираем половину флешей и продолжаем параллельную запись в них
И так по заполнению делим адресное пространство на 2 постоянно.
Представляется это оптимальным алгоритмом в данном случае, но, увы, железо так сделать на позволяет: чипселектами управляет декодер, а по мощности операцию одновременного стирания нескольких флешей устройство не тянет.
Так что будем думать менее красивые способы