Ведение журнала данных типа "Черный ящик"

Question

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

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

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

Answer 1

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

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

Answer 2

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

Если вам не нужно выполнять поиск в системе, то CSV работает отлично.

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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