Блог

В встраиваемом приложении Linux, которое я разрабатываю, существует необходимость записывать некоторые события, которые происходят время от времени. Эти записи сохраняются на флэш-устройстве MTD, и после их записи нет необходимости изменять их или выполнять эффективный поиск, но для отображения данных пользователю требуется доступ для чтения. Большая проблема заключается в том, что питание может отключиться в любой момент без надлежащей последовательности отключения. Частота возникновения этих событий может быть очень низкой (дни/недели), но несколько из них произойдут одновременно. Данные, которые должны быть сохранены для каждого события, строго типизированы: дата, время, пара коротких текстовых строк и несколько целых чисел.

В настоящее время я унаследовал решение, основанное на jffs2 и SQLite, которое далеко не оптимально, потому что файл БД иногда повреждается. Когда это происходит, весь файл становится нечитаемым, и невозможно понять, было ли это вызвано ошибкой в jffs2 или в SQLite, или если сектор флэш-памяти был неисправен, или питание было отключено в неподходящее время.

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

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

Если вам не нужно искать в системе, то CSV-файл отлично работает.

Мы используем обычный старый syslogd для раздела YAFFS2 на флэш-памяти NAND, похоже, он работает хорошо: когда сообщения отправляются в регистратор и питание отключается сразу после (

Это основано на наблюдении, а не на моем явном знании того, что все всегда будет согласовано по замыслу, имейте в виду.

Существует ряд встроенных файловых систем (не совместимых с fat), разработанных именно для этой цели. Я не могу предложить, так как никогда не использовал его, но здесь что-то из Google. Я уверен, что вы можете раскопать больше, и, надеюсь, кто-нибудь здесь сможет предоставить больше информации, может быть, есть что-то на основе GPL. Сравнение различных файловых систем приведено здесь

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

Таким образом, если вы выйдете из строя во время первой записи, все данные во второй копии (вплоть до этой записи) все равно будут там.

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

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

Какие услуги вам доступны? Лучшим вариантом часто является вход во внешний ресурс, например, через системный журнал, SNMP, необработанный сокет или последовательный порт. Это защищает ваши журналы от неприятностей на самом устройстве.

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