Про SPIFFS и запись одного и того же файла в разные части памяти. Теория. И вопрос.

[Slacky]

Добрый день.

Есть, допустим, конфигурационный файл. Пусть будет config. И пусть будут еще 32 клона config0, config1 ... config31.

Писать в разные файлы не проблема. Но как понять при старте, какой читать?

Остается переименовать и читать всегда из файла config.

А вот тут вопрос, ибо не силен я сам в этом. Функция rename возвращает ошибку, если файл, в который мы хотим переименовать, существует. Ладно. Удаляем. Переименовываем config в, допустим, config10, пишем в config9 и переименовываем его обратно в config. При следующем обращении переименовываем config в config 11, пишем в config10 и переименовываем его обратно в config. И т.д.

Собственно вопрос - будут физически "затрагиваться" два разных "места" в памяти или?

Спасибо.

 

[pvvx]

Файл в Flash в SPIFFS представляет из себя кусочки данных раскиданные по секторам. Если вы переписываете файл, хоть один бит в нем, то все кусочки будут переписаны в новое место, а старые объявлены как удаленные. При этом переписывается разметка описывающая где и что хранится.

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

При переименовании файла переписывается только область заголовков…

Это обычное дело для большинства файловых систем.

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

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

Записывая новый файл, пишите новый счетчик n+1, а самый старый файл стираете.

Вот только для SPIFFS это всё ужасно из-за неоптимального использования объема FLASH и полной деоптимизации - частой перезаписи при минимальных действиях с файловой структурой, т.к. специализация SPIFFS в минимально используемой RAM за счет производительности CPU и безжалостного расхода объема FLASH и кол-ва перезаписей.

 

[Slacky]

О, по времени. Спасибо!