[AlexandrY 2]

3 hours ago, jcxz said:

Скорость больше будет зависеть от объёма отданного под кеш места в ОЗУ МК.

В свое время тестировал  5-ть разных embedded FAT FS, все деградируют по скорости открытия в несколько  раз уже при 100 файлах.  Кэш не спасает. 

Кстати нашел у Segger-а данные по производительности записи на SPI NOR - 62.8 Kbyte/s  на ST STM32F103 72 MHz  с ST M25P64
У Micrium-а - 55 62.8 Kbyte/s на ST M25P64 72 MHz c ST M25P64
Включение опции журналирования уменьшает скорость записи еще в 3! раза. 
Похоже выбор для логов  SPI NOR - худшее что можно было придумать. 

[jcxz 184]

10 часов назад, AlexandrY сказал:

В свое время тестировал  5-ть разных embedded FAT FS, все деградируют по скорости открытия в несколько  раз уже при 100 файлах.  Кэш не спасает. 

Кстати нашел у Segger-а данные по производительности записи на SPI NOR - 62.8 Kbyte/s  на ST STM32F103 72 MHz  с ST M25P64
У Micrium-а - 55 62.8 Kbyte/s на ST M25P64 72 MHz c ST M25P64

Если уж говорить именно о скорости открытия файлов, то здесь важна не скорость записи, а скорее скорость чтения. И если не спасает кеш, то может спасает его размер?  

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

10 часов назад, AlexandrY сказал:

Похоже выбор для логов  SPI NOR - худшее что можно было придумать. 

Как я уже говорил: выбор любой ФС для логов - худшее решение, которое можно придумать. Только кольцо секторов. И никаких проблем с неравномерным износом, скоростью и т.п. Вообще не понимаю смысла обсуждения какой-то ФС для хранения логов.

[haker_fox 60]

18 minutes ago, jcxz said:

Как я уже говорил: выбор любой ФС для логов - худшее решение, которое можно придумать. Только кольцо секторов. И никаких проблем с неравномерным износом, скоростью и т.п. Вообще не понимаю смысла обсуждения какой-то ФС для хранения логов.

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

[SSerge 4]

7 минут назад, jcxz сказал:

Как я уже говорил: выбор любой ФС для логов - худшее решение, которое можно придумать. Только кольцо секторов. И никаких проблем с неравномерным износом, скоростью и т.п. Вообще не понимаю смысла обсуждения какой-то ФС для хранения логов.

Поддерживаю.

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

Так получается что файловая система есть когда она нужна, а когда не нужна она не мешает.

[jcxz 184]

9 минут назад, SSerge сказал:

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

Если ФС нужна для чего-то ещё кроме, то да - можно сделать так. А можно просто отрезать под раздел с ФС только часть объёма SD-карты, а на остальном объёме хранить другие структуры хранения (кольца логов, журналов и т.п.).

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

[AlexandrY 2]

1 hour ago, jcxz said:

Если уж говорить именно о скорости открытия файлов, то здесь важна не скорость записи, а скорее скорость чтения. И если не спасает кеш, то может спасает его размер?  

Как я уже говорил: выбор любой ФС для логов - худшее решение, которое можно придумать. Только кольцо секторов. И никаких проблем с неравномерным износом, скоростью и т.п. Вообще не понимаю смысла обсуждения какой-то ФС для хранения логов.

Эт вы рассказывайте Micrium-у, может они рассмотрят и одобрят ваш "алгоритм".  
Зачем вообще этот велосипед с циклическими буферами тут многократно пересказывать? 
В mbed штатно идут классы блочных дивайсов на любой вкус для тех кому реально не нужна файловая система.  

И кольцо не лучшая структура для быстрого поиска, куда быстрее работает дерево, а самые быстрые - это  FS на RAM-е
 

[jcxz 184]

3 минуты назад, AlexandrY сказал:

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

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

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

[AlexandrY 2]

1 hour ago, jcxz said:

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

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

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

Потом вы какие-то очень примитивные приложения себе представляете.
Мои логи скажем от GPS трекера содержали тысячи KML файлов. Дивайс поддерживал FTP сервер с доступом ко всем логам. 
А еще SNMP сервер, и майлы, и SMS. На все тоже велись логи. Не считая прикладных логов от оборудования.
С некоторой точки скорострельность файловой системы становится узким местом.  А вы мне про какое-то кольцо.
Идите в mbed и найдете там десятки колец и деревьев если нужно, но это не отменяет необходимость в быстрых файловых системах.    
  

[jcxz 184]

2 часа назад, AlexandrY сказал:

Потом вы какие-то очень примитивные приложения себе представляете.
Мои логи скажем от GPS трекера содержали тысячи KML файлов. Дивайс поддерживал FTP сервер с доступом ко всем логам.   

И опять громкие фразы "тысячи файлов" и куча других страшных слов... и никакой конкретики. И так всегда... Каждый тут может сам сделать вывод и оценить что чего стоит. 

И какая разница: FTP-сервер или ещё какой-то сервер будет читать эти логи - какая связь между ним и способом хранения логов? И причём тут опять же какая-то примитивность или непримитивность приложений? Как это относится к способу хранения логов? И если уж говорить о скорострельности доступа, то без ФС будет однозначно быстрее чем с ней. По определению.

[AlexandrY 2]

1 hour ago, jcxz said:

И причём тут опять же какая-то примитивность или непримитивность приложений? Как это относится к способу хранения логов?

Напрямую. Если у вас мало задач, то вам и невдомек как они влияют друг на друга через файловую систему. Это постигается на опыте. 

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

Не надо только разводить полемику по поводу логи это уже или не логи и зачем такие логи.  
И что это за понятие такое - способ хранения. Тут не способ, а целый набор технологий от избыточного кодирования, до красно-черных деревьев.
Конкретики на целую книгу можно набрать.  Если нету сил изучать, то я тут при чем?   
 

[jcxz 184]

34 минуты назад, AlexandrY сказал:

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

Не надо только разводить полемику по поводу логи это уже или не логи и зачем такие логи.

процитирую известного деятеля: Если бы у бабушки был ххх, то она была бы дедушкой, а не бабушкой. Надеюсь поняли  

Ладно - Вы видимо живёте в каком-то своём мире, Ваше право....

[AlexandrY 2]

On 11/27/2018 at 4:56 PM, jcxz said:

процитирую известного деятеля: Если бы у бабушки был ххх, то она была бы дедушкой, а не бабушкой. Надеюсь поняли  

Ладно - Вы видимо живёте в каком-то своём мире, Ваше право....

Что, сами поставили SPI Flash и не осилили FS для нее? 
Есть такие кому "не интересно", обломавшись на примитивных структурах данных (это ж трудоемко ) ищут серебряную пулю и чтоб все им разжевали.  

Рекомендую в следующий раз применять HyperFlash NOR и RAM
Этот интерфейс, кстати, поддерживает семейство i.MX RT.

[haker_fox 60]

В общем была использована Reliance Edge (здесь тоже упоминается). Сначала хотели сделать кольцевой буфер, как предлагал уважаемый @jcxz, но поскольку в приборе также было необходимо хранить файлы контента, то остановились на "нормальной" ФС. В целом - понравилась. Правда есть нюансы: конфигурировать только через специальную утилиту, которая свободно скачивается с сайта  производителя. Возможно можно и без неё, не разбирался. Также максимальное количество файлов и директорий необходимо задать в конфигурации, т.е. на этапе компиляции, и под "указатели" в файловой таблице место "отъедается" сразу, даже если ни один файл не записан. На один указатель тратится два кластера ФС. Всё остальное вполне себе прекрасно. В проекте была написана оболочка виртуальной файловой системы, чтобы приложение могло одинаково работать со съёмными носителями (FatFS), так и с внутренними. Не очень, может быть, тщательное тестирование показало, что фска не разрушается неожиданными отключениями питания прибора во время записи. Тест включал в себя запись и чтение файлов случайного размера из нескольких задач (ОС FreeRTOS), питание выключалось случайным образом, длительность теста - около 3 часов. Файлы либо не создавались, либо имели нулевой размер в момент "сбоя", но целостность ФС была соблюдена.

[AlexandrY 2]

55 minutes ago, haker_fox said:

В общем была использована Reliance Edge (здесь тоже упоминается). 

Кстати, если кто-то еще здесь заинтересован в надежной,  мощной и качественной файловой системе то рекомендую ThreadX FileX  
Умеет работать с терабайтными файлами, выравнивает износ, защищена от сбоев.

Дают совершенно бесплатно!
Правда придется использовать  микроконтроллеры семейства Renesas Synergy.     

[Kabdim 0]

1 час назад, haker_fox сказал:

В общем была использована Reliance Edge (здесь тоже упоминается).

Спасибо что не поленились написать живой отзыв. Когда ищешь что-то новое для себя их по жизни не хватает в общем гаме тех кто слышал, но не использовал.