FatFs на STM32 - кеширование FAT32?, чтобы ускорить f_open() Опции

[sonycman]

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

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

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

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

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

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

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

[AHTOXA]

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

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

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

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

[sonycman]

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

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

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

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

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

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

[aaarrr]

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

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

[sonycman]

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

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

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

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

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

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

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

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

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

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

[aaarrr]

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

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

[sonycman]

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

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

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

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

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

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

[aaarrr]

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

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

[sonycman]

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

Речь о FAT32.

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

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

[aaarrr]

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

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

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

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