Jump to content

    

Отказоустойчивая ФС, направьте, пожалуйста, в нужном направлении

14 минут назад, Arlleex сказал:

Целостность данных в файловом представлении в момент выключения питания от качества карты не зависит ровно никак.

Именно. WAL решает как раз на уровне транзакций записи в БД. 

Минус SQLite - желательно её использовать всё таки с одного потока ... :) 

Share this post


Link to post
Share on other sites
2 minutes ago, psyhologic said:

Именно. WAL решает как раз на уровне транзакций записи в БД. 

Минус SQLite - желательно её использовать всё таки с одного потока ... :) 

Но WAL не решает проблему транзакций при записи на SD. Поэтому все тщетно. 
Да и речь шла о файловой системе.
А это значит файловое API с символьными именами, поиском по именам, копированием, переносом, добавлением, директориями и проч. атрибутикой.   
Файловые сами по себе базы данных.
Так что база данных поверх  базы данных будет сильный оверхед. 

Share this post


Link to post
Share on other sites
1 час назад, AlexandrY сказал:

Эт в теории.

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

Share this post


Link to post
Share on other sites
1 час назад, Arlleex сказал:

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

Последствия зависят от типа FS. https://ru.wikipedia.org/wiki/Журналируемая_файловая_система

Share this post


Link to post
Share on other sites
2 часа назад, AlexandrY сказал:

Но WAL не решает проблему транзакций при записи на SD. Поэтому все тщетно. 
Да и речь шла о файловой системе.
А это значит файловое API с символьными именами, поиском по именам, копированием, переносом, добавлением, директориями и проч. атрибутикой.   
Файловые сами по себе базы данных.
Так что база данных поверх  базы данных будет сильный оверхед. 

 

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

Overhead будет всегда, почти все СУБД хранят свои данные в виде файлов (данных и лога).

Цитата

Добрый день, коллеги! В приборе, которому могут неожиданно отключить питание, необходимо сохранять логи (файлы длиной 50 - 150 кб). Допускается потеря лога в момент отключения питания (либо другого сбоя), но не разрушение ФС вместе с остальными данными. Прибор сделан на базе Cortex-M4F. Используем FreeRTOS. Из журналируемых "свободных" решений нашёл только uc/FS. Может быть есть какие-либо ещё доступные ФС с такими возможностями, пригодными для применения в embedded? В целом, не требуется совместимости с FAT, хотя и желательно.

Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))

 

Share this post


Link to post
Share on other sites
2 minutes ago, psyhologic said:

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

Overhead будет всегда, почти все СУБД хранят свои данные в виде файлов (данных и лога).

Не, именно проблема карты у автора и встала в полный рост.
Или дайте реалистичный сценарий как можно просто не дописав блок на SD карту убить всю файловую систему.

И зачем здесь поминать СУБД непонятно. У автора есть на выбор не меньше 5-6 опенсорсных надежных встраиваемых файловый систем. 
СУБД здесь будет десятая по списку. 
 

Share this post


Link to post
Share on other sites

Для примера вот сколько мусора мы собрали за пару лет использования SD карт GoodRAM 

Это из партии в пару сотен штук.

1025270457_uSDGoogRAM.jpg.3d5746e7e8c8f3fc9327a6f7fa4d5e85.jpg

Чаще всего у них просто перестают прозваниваться ноги по питанию.
Но бывает рушиться вся файловая, но потом поддаются форматированию.  

У Kingston такого не замечали.
Так что на заметку. 

 

Share this post


Link to post
Share on other sites
19 hours ago, psyhologic said:

Автор топика не решает проблемы с физической деградацией карты памяти

Автор темы вообще не решает проблемы с картой)))) Подразумевались микросхемы памяти n25q128. Впрочем, это вообще не важно какой носитель. Но про карты тоже интересно послушать)

Share this post


Link to post
Share on other sites
34 minutes ago, haker_fox said:

Автор темы вообще не решает проблемы с картой)))) Подразумевались микросхемы памяти n25q128. Впрочем, это вообще не важно какой носитель. Но про карты тоже интересно послушать)

SPI NOR - это сложно.
В плане что простые советы типа бери то-сё  не покатят.
Журнальные FS без  RAM на сотню другую килобайт могут начать сильно тормозить при большом количестве файлов и директорий. 
Нужно тестирование.
А то может и риалтайм сломаться.  

Share this post


Link to post
Share on other sites
11 minutes ago, AlexandrY said:

SPI NOR - это сложно

Но с точки зрения ПО они от SD отличаются тем, что стирать надо секторами, например по 4 кБ, а писать страницами по 256 байт. С SD в этом плане - проще. Но внутри SD тоже может либо NOR, либо NAND быть.

Share this post


Link to post
Share on other sites
6 hours ago, haker_fox said:

Впрочем, это вообще не важно какой носитель. Но про карты тоже интересно послушать)

 

Посмотрите про eMMC

https://www.embeddedarm.com/about/resource/preventing-filesystem-corruption-in-embedded-linux


 

Quote

 

"Write Reliability" mode, and a "psuedo SLC" mode. These modes can be access by setting a fuse on the eMMC device. With both of these enabled the eMMC only risks up to 512B during a write. In the event of a power loss that 512B of data would return the values from a previous write rather than corrupt or erased data like a typical SD card.


 

 

Share this post


Link to post
Share on other sites
15 часов назад, haker_fox сказал:

Но внутри SD тоже может либо NOR, либо NAND быть.

Внутри SD может быть MLC NAND или TLC NAND или еще худшее говнище. Никакого NOR в SD быть не может потому что гигабайты на NOR это фантастика.

Share this post


Link to post
Share on other sites
54 minutes ago, _3m said:

Внутри SD может быть MLC NAND или TLC NAND или еще худшее говнище. Никакого NOR в SD быть не может потому что гигабайты на NOR это фантастика.

Не, ну можно было бы предположить, что NOR запаковали в какую-нибудь SD карту, я б не отказался от такого. 
Но тогда NOR  лишится своего главного преимущества - рандомного чтения байт. 

А так NOR несколько меняет предпочтения в выборе файловой системы.  

Share this post


Link to post
Share on other sites
В 20.11.2018 в 10:09, AlexandrY сказал:

Для примера вот сколько мусора мы собрали за пару лет использования SD карт GoodRAM 

Это из партии в пару сотен штук.

1025270457_uSDGoogRAM.jpg.3d5746e7e8c8f3fc9327a6f7fa4d5e85.jpg

Чаще всего у них просто перестают прозваниваться ноги по питанию.
Но бывает рушиться вся файловая, но потом поддаются форматированию.  

У Kingston такого не замечали.
Так что на заметку. 

 

Да вы правы, Бывают проблемы с ними, увы умирают без видимой причины ...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now