Форум разработчиков электроники ELECTRONIX.ru > FatFs на STM32

sonycman

Jul 5 2010, 09:55

Всем доброго времени суток.

На девайсе под управлением STM32 есть процедура, которая создаёт сортированный по алфавиту список файлов FAT32 диска на флеш карточке.
Используется FatFs версии 0.08.
Количество файлов в списке может быть максимум 500.

На днях обратил внимание, что львиная доля времени (около 90%), затрачиваемого на сортировку, потребляется функцией файловой системы f_open().
Поковырявшись в её дебрях, обнаружил, что в свою очередь это вызвано подфункцией move_window(), которая подгружает по одному сектору из, вероятно, каталога фат.

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

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

Главный вопрос здесь - хватит ли для этого 10-20 килобайт оперативки?
К сожалению, приходится довольствоваться только внутренним ОЗУ контроллера.

Наверное, для FAT32 с большим количеством файлов кеширование 20 килобайт (40 секторов) не будет эффективным?

aaarrr

Jul 5 2010, 10:04

Цитата(sonycman @ Jul 5 2010, 13:55)

Наверное, для FAT32 с большим количеством файлов кеширование 20 килобайт (40 секторов) не будет эффективным?

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

sonycman

Jul 5 2010, 10:35

Цитата(aaarrr @ Jul 5 2010, 14:04)

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

Хм, спасибо, тогда попробую, когда будет время.

move_window() запрашивает по одному сектору, как тут организуешь мультисекторное чтение?
Если только запросы будут идти последовательно по порядку.

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

aaarrr

Jul 5 2010, 10:43

Цитата(sonycman @ Jul 5 2010, 14:35)

move_window() запрашивает по одному сектору, как тут организуешь мультисекторное чтение?

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

sonycman

Jul 5 2010, 10:52

Цитата(aaarrr @ Jul 5 2010, 14:43)

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

Конечно интересно, опишите пожалуйста

Я пока глубоко не копал в структуру FAT на диске, поэтому слабо понимаю механику работы файловой системы.

Тут ведь ещё есть нюанс с записью - надо ли будет перед выполнением записи на диск/в фат сбрасывать кеш?

aaarrr

Jul 5 2010, 12:12

Цитата(sonycman @ Jul 5 2010, 14:52)

Конечно интересно, опишите пожалуйста

Хорошо.

Используются две структуры:

Код

struct SD_CACHE_ENTRY
{
    struct SD_CACHE_ENTRY    *next;
    unsigned int            sec;
    unsigned char            *data;
};

struct SD_WRITE_BUFFER_ENTRY
{
    unsigned int            sec;
    unsigned char            *data;
};

Первая описывает строку кэша, из этих записей формируется односвязный список. Вторая - для буфера записи, сложены в виде массива. Отдельно вводим переменную, указывающую текущее заполнение буфера записи - sd_wbuff_level.
Данные отделены от списка для более эффективной работы кэша самого процессора, для STM32 можно буферы внести в структуру.
При инициализации диска формируется список из SD_CACHE_ENTRY, поля sec заполняются значением SD_CACHE_INVALID_SEC (0xffffffff); переменную sd_wbuff_level устанавливаем в 0.
Число секторов в строке у меня выбрано равным 8.

Чтение:
1. Последовательно проходим по списку, если запрашиваемый сектор находится внутри имеющейся в кэш строки:
1.1. Копируем данные из кэш
1.2. Переставляем строку в начало списка (это нужно для увеличения производительности - редко использующиеся строки будут постепенно падать в конец списка)
2. Если данные в кэш отсутствуют, то:
2.1. Сбрасываем на диск буфер записи (некоторое упрощение, чтобы не искать данные в буфере)
2.2. Читаем с карты строку, заполняя при этом последнюю из записей, по которым ходили в п.1
2.3. Переставляем заполненную строку в начало списка

Запись:
1. Проходим по списку. Если нужная строка найдена, заменяем в ней данные и запоминаем адрес
2. Проходим по буферу записи до уровня sd_wbuff_level, добавляем запись и увеличиваем sd_wbuff_level, если целевой сектор отсутствует
3. При заполнении структуры буфера записи заменяем адрес в SD_WRITE_BUFFER_ENTRY на адрес в кэше, если в п.1 строка была найдена (исключаем лишнее копирование)

Очистка буфера записи:
1. Сортируем записи в буфере по возрастанию номеров блоков
2. Пишем данные с использованием мультиблочной записи

Вот как-то так.

P.S. У меня, правда, файловая система написана в расчете на кэшируемый диск, поэтому не стесняется что-то прочитать или записать, когда надо. Если над этой системой будет надстроена еще одна, то производительность несколько снизится.

sonycman

Jul 5 2010, 13:36

Спасибо!
Что-то вроде этого задумывал и я, только в условиях нехватки памяти кешировать нужно исключительно сектора каталогов фат (или как правильно называется область со структурами имён файлов?).

Вероятно, move_window() читает/пишет только такие сектора, поэтому попробую привязать кеш именно к ней...

sonycman

Jul 5 2010, 18:49

Хм, вот все же странно как то у Чена сделан подход к кешированию.
То есть кешировать абсолютно весь диск - нет проблем, делается это просто через функции ReadSectors() и WriteSectors().
Но это не сильно умно в условиях ограниченного количества оперативки.

Логичнее было бы закешировать только корневой каталог и FAT (при интенсивной работе с большим кол-вом файлов).

Но как это сделать, не модифицируя исходники Чена?
Почему он не предусмотрел такой возможности?

AHTOXA

Jul 5 2010, 19:26

Цитата(sonycman @ Jul 5 2010, 19:36)

Вероятно, move_window() читает/пишет только такие сектора, поэтому попробую привязать кеш именно к ней...

Нет, move_window() универсальная, вызывается во всех случаях.

Цитата(sonycman @ Jul 6 2010, 00:49)

Логичнее было бы закешировать только корневой каталог и FAT (при интенсивной работе с большим кол-вом файлов).

А может и нет

Логичнее сделать кеширование как написал aaarrr, и тогда в кеше автоматически будут храниться наиболее востребованные данные. Чаще идёт обращение к FAT - значит в кеше FAT. К данным (многократный парсинг одного файла) - в кеше данные. И не надо будет гадать ничего

sonycman

Jul 5 2010, 19:43

Цитата(AHTOXA @ Jul 5 2010, 23:26)

Нет, move_window() универсальная, вызывается во всех случаях.

А во всех - это в каких?
Я пока глубоко не вникал, но показалось, что эта функция с чтением/записью единственного сектора годится только для работы с каталогом.

Цитата

А может и нет

Логичнее сделать кеширование как написал aaarrr, и тогда в кеше автоматически будут храниться наиболее востребованные данные. Чаще идёт обращение к FAT - значит в кеше FAT. К данным (многократный парсинг одного файла) - в кеше данные. И не надо будет гадать ничего

Это смотря какие условия.
К примеру - открыли мы файл (при этом кеш заполнился секторами корневого каталога), затем считали большой кусок этого файла.
В кеше будет содержимое считанного файла, которое и без него читается быстро.
Затем открываем другой файл - так как в кеше уже нет секторов каталога - снова идёт обращение к диску.

Зачем мне это надо?

Мне бы просто ускорить работу с каталогом

aaarrr

Jul 5 2010, 20:21

Цитата(sonycman @ Jul 5 2010, 23:43)

Мне бы просто ускорить работу с каталогом

Увы, в условиях дефицита оперативки, придется так или иначе выкручиваться - добавлять в функцию чтения флаг запрета кэширования, например. Или встроить в FatFS отдельный кэш для каталогов и FAT. Просто прикрутить что-то снаружи не выйдет.
Хотя даже с ограниченным объемом памяти приведенный мной вариант может несколько облегчить жизнь за счет наличия своего рода упреждающего чтения.

AHTOXA

Jul 5 2010, 20:56

Цитата(sonycman @ Jul 6 2010, 01:43)

А во всех - это в каких?

Ну вообще во всех. Эта функция грузит сектор в единственный буфер объекта-файловой системы. Нужен сектор FAT - грузит его. Читаем данные - грузит их (и FAT конечно выгружен)

Цитата

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

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

sonycman

Jul 5 2010, 21:09

Цитата(aaarrr @ Jul 6 2010, 00:21)

Увы, в условиях дефицита оперативки, придется так или иначе выкручиваться - добавлять в функцию чтения флаг запрета кэширования, например. Или встроить в FatFS отдельный кэш для каталогов и FAT. Просто прикрутить что-то снаружи не выйдет.
Хотя даже с ограниченным объемом памяти приведенный мной вариант может несколько облегчить жизнь за счет наличия своего рода упреждающего чтения.

Оптимальный способ для меня - использовать флаг разрешения кеширования.
Тогда в исходники FatFs достаточно встроить пару строк (к примеру, в функцию f_open() или в move_window()), остальным займётся драйвер.

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

Цитата(AHTOXA @ Jul 6 2010, 00:56)

Ну вообще во всех. Эта функция грузит сектор в единственный буфер объекта-файловой системы. Нужен сектор FAT - грузит его. Читаем данные - грузит их (и FAT конечно выгружен)

А как же мультисекторные чтение/запись?

Нет, конечно-же, не пугайте так

Эта функция используется только в конфигурации _FS_TINY.
В остальных случаях идёт прямое обращение к disk_read() - к драйверу.

Привыкли, наверное, к AVR?

Цитата

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

Да, именно это мне и требуется.

Хотя, даже в случае наличия 20 килобайт памяти их для этого не хватает

Нужны "метры"!

aaarrr

Jul 5 2010, 21:12

Цитата(sonycman @ Jul 6 2010, 00:59)

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

Если используется именно FAT32 (или не корневой каталог FAT16), то смысл будет иметь любой кэш объемом более одного кластера - так по крайней мере активный сектор FAT'а будет всегда "на плаву". Словом, некоторый выигрыш получите практически в любом случае.
Конечно, чем больше объем - тем лучше. Можно сделать "как у больших", отдав всю не выделенную приложениям память под нужды дискового кэша. Правда, в случае STM32 без внешней ОЗУ это уже излишества.

sonycman

Jul 5 2010, 21:35

Цитата(aaarrr @ Jul 6 2010, 01:12)

Конечно, чем больше объем - тем лучше. Можно сделать "как у больших", отдав всю не выделенную приложениям память под нужды дискового кэша. Правда, в случае STM32 без внешней ОЗУ это уже излишества.

Вот именно.
Мне просто стало интересно, почему основное время процедура сортировки теряет не на собственно сортировке, а на банальном открытии файла

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

ЗЫ: Правильно ли я рассуждаю: к примеру, выделяем на кеш 40 секторов.
Вызываем f_open() - она начинает двигаться по корневому каталогу в поисках целевого файла, последовательно считывая сектора.
Скажем, находит его после считывания пятидесяти секторов, то есть в кеше находятся сектора 10 - 50.

Вызываем f_open() снова - другой файл - чтение корневого каталога повторяется опять с первого сектора... которого в кеше нет.
Соответственно, снова последовательно считываются все сектора заново, так как первый сектор замещает 10, второй - 11 и т.д.

В этой ситуации пользы от кеша - ровно ноль.

Но это теория. Надо проверить на практике.

aaarrr

Jul 5 2010, 21:51

Цитата(sonycman @ Jul 6 2010, 01:35)

В этой ситуации пользы от кеша - ровно ноль.

Нет, это не совсем так. Во-первых, читаем не по одному сектору, что уже дает преимущество в скорости (причем иногда в разы). Во-вторых, вы упускаете чтение собственно FAT. Если же речь идет о чтении корневого каталога FAT16, то его длина обычно составляет 16кбайт, что позволяет спокойно разместить его даже в памяти STM32.

sonycman

Jul 5 2010, 22:01

Цитата(aaarrr @ Jul 6 2010, 01:51)

Нет, это не совсем так. Во-первых, читаем не по одному сектору, что уже дает преимущество в скорости (причем иногда в разы). Во-вторых, вы упускаете чтение собственно FAT. Если же речь идет о чтении корневого каталога FAT16, то его длина обычно составляет 16кбайт, что позволяет спокойно разместить его даже в памяти STM32.

Речь о FAT32.

А для чего читать FAT, разве добраться до записи с информацией о файле (с именем и первым сектором) нельзя просто последовательно читая каталог?

Если, кроме каталога, читаются ещё и другие сектора - тогда это только увеличивает требования к размеру кеша...

aaarrr

Jul 5 2010, 22:15

Цитата(sonycman @ Jul 6 2010, 02:01)

А для чего читать FAT, разве добраться до записи с информацией о файле (с именем и первым сектором) нельзя просто последовательно читая каталог?

А как последовательно читать каталог, не читая при этом FAT? Каталог - это тот же файл, за исключением случая корневого каталога FAT12/16.

Цитата(sonycman @ Jul 6 2010, 02:01)

Если, кроме каталога, читаются ещё и другие сектора - тогда это только увеличивает требования к размеру кеша...

FAT нужно будет читать при переходе на каждый следующий кластер файла, то есть данные FAT не будут выведены из кэша, если только его размер превышает размер одного кластера диска. Таким образом кэш размером 20кбайт вполне может быть полезен.

sonycman

Jul 5 2010, 23:44

Получил результаты своего отладочного логгера, который сохранил историю запросов на чтение диска при работе функции f_open().
Цифры - LBA сектора в шестнадцатеричном виде:

CODE

Кластер на карточке равен 32 килобайтам.

Как видно, чтобы открыть файл, считывается два с лишним кластера каталогов (!!!) (а между ними проскакивает сектор FAT?).

И так практически для всех 57 файлов папки, а если точнее - методом односекторного чтения считывается 131 сектор для первого файла, и уже 143 сектора для последнего.

Хм, действительно, если читать сразу по 8 секторов за раз, то можно несколько выиграть.

ЗЫ: завтра посмотрю, какая картина будет при сортировке 500 файлов.
Аж страшно становится

ЗЗЫ: до чего убогая файловая система, господи.
Чтобы добраться до грошового файлика весом в сотню байт, требуется перерыть килобайты мусора в виде каталогов...

AHTOXA

Jul 6 2010, 09:11

Цитата(sonycman @ Jul 6 2010, 03:09)

А как же мультисекторные чтение/запись?

Нет, конечно-же, не пугайте так

Эта функция используется только в конфигурации _FS_TINY.
В остальных случаях идёт прямое обращение к disk_read() - к драйверу.

Да, действительно. Видимо я ковырял очень старую версию FatFs, где ещё не было мультисекторного чтения/записи. Или просто что-то перепутал

Цитата

Привыкли, наверное, к AVR?

Вы меня наверное с кем-то путаете?

sonycman

Jul 6 2010, 10:24

Цитата(AHTOXA @ Jul 6 2010, 13:11)

Вы меня наверное с кем-то путаете?

Показалось просто.
Извините

Прогнал сортировщик на файлах в другой папке, общим количеством в 500.
Первый файл - 129 секторов каталога, похоже на предыдущий скан.
Зато вот последний:

CODE

это вообще жесть - 256 секторов, четыре полных кластера!

Попробую сделать простой кеш в виде считывания при любом запросе сразу 8 секторов.
Отводить 20 килобайт не вижу смысла - огромное количество запрашиваемых секторов в них разместить никак не получится.

Отведу память чисто под эти 8 секторов, и всё.
Посмотрим, какие будут результаты...

defunct

Jul 12 2010, 20:13

Цитата(sonycman @ Jul 6 2010, 13:24)

это вообще жесть - 256 секторов, четыре полных кластера!

А что мешает менять порядок просмотра каталога? Пусть закешированы у вас с 10 по 40-й сектора, так посмотрите вначале в них, а потом читайте с 0 по 9 и все остальные выше 40-го...

aaarrr

Jul 12 2010, 21:41

Цитата(defunct @ Jul 13 2010, 00:13)

А что мешает менять порядок просмотра каталога? Пусть закешированы у вас с 10 по 40-й сектора, так посмотрите вначале в них, а потом читайте с 0 по 9 и все остальные выше 40-го...

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

sonycman

Jul 12 2010, 21:47

Цитата(aaarrr @ Jul 13 2010, 01:41)

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

Не стоит это того.
Если нужен нормальный кеш - надо ставить много памяти.

Простым чтением по запросу MoveWindow() вместо одного сектора - сразу восьми, я получил выигрыш в скорости в 20%.
Не бог весть что, но тоже результат, с учётом всего лишь 4 килобайт отведённой под такой кеш памяти

aaarrr

Jul 12 2010, 22:52

Цитата(sonycman @ Jul 13 2010, 01:47)

Не стоит это того.
Если нужен нормальный кеш - надо ставить много памяти.

Это верно. Совсем недавно пришлось в одном проекте выделить под кэш 4 мегабайта, так как каталог может содержать 100 тысяч файлов с именами вида:
XX000000.XXX
XX000001.XXX
До кучи было добавлено битовое поле на 100 кбит, чтобы быстро выяснять наличие файла с произвольным номером.
Грубо, зато просто и эффективно.

Цитата(sonycman @ Jul 13 2010, 01:47)

Простым чтением по запросу MoveWindow() вместо одного сектора - сразу восьми, я получил выигрыш в скорости в 20%.
Не бог весть что, но тоже результат, с учётом всего лишь 4 килобайт отведённой под такой кеш памяти

А не собирали статистику, сколько из этих восьми идет впрок?

sonycman

Jul 13 2010, 00:19

Цитата(aaarrr @ Jul 13 2010, 02:52)

А не собирали статистику, сколько из этих восьми идет впрок?

Я выше в этой теме приводил списки запрашиваемых секторов каталога.
Если судить по ним, только редкие обращения к фат (один сектор из 64) идут в оверхед.

Пробовал читать по 16 секторов - уже эффективность немного хуже, чем по 8.

Ivan Kuznetzov

Aug 22 2010, 20:20

извиняюсь за оффтоп, sonycman, как у Вас объявлена структура FATFS fs; ? как глобальная? или в процедуре main()? у меня возникла интересная проблемка: когда эта структура объявлена глобально, запись в файл глючит, а именно, при записи в файл первый элемент байтового массива искажается процедурой f_write. (байтовый массив объвлен глобально).

sonycman

Aug 23 2010, 01:41

Цитата(Ivan Kuznetzov @ Aug 23 2010, 00:20)

извиняюсь за оффтоп, sonycman, как у Вас объявлена структура FATFS fs; ? как глобальная? или в процедуре main()? у меня возникла интересная проблемка: когда эта структура объявлена глобально, запись в файл глючит, а именно, при записи в файл первый элемент байтового массива искажается процедурой f_write. (байтовый массив объвлен глобально).

Именно глобально.
Наверное, у Вас какая то накладочка выходит с массивом или со стеком, f_write() тут не при чём, имхо.

Ivan Kuznetzov

Aug 25 2010, 17:56

Цитата(sonycman @ Aug 23 2010, 07:41)

Именно глобально.
Наверное, у Вас какая то накладочка выходит с массивом или со стеком, f_write() тут не при чём, имхо.

массив из 512 байт тоже объявлен глобально.
Если объявляю FATFS fs глобально, а массив data[512] запихиваю в функцию - начинает работать нормально, тоесть меняю местами. если всё делаю глобально - опять косяк, после f_write содержимое первого байта массива меняетя. Именно после того, как мы записываем массив на карту командой f_write (смотрю дебаггером), первый байт становится красненьким ...

файловый объект FIL file; у меня объявлен глобально, это правильно?

aaarrr

Aug 25 2010, 18:14

Посмотрите в map-файле, что стоит перед data[], от этого можно оттолкнуться при поиске виновных. Ну, или если уж дебаггер под рукой - так и поставьте ему точку останова по событию записи в первый элемент портящегося массива.