Безопасная запись на компактную флэш-память на встроенном Linux

Question

Я занимаюсь разработкой встраиваемой системы Linux, которая работает на компактных флешках и tmpfs. Флэш-память установлена ​​только для чтения и обычно должна оставаться такой, но иногда мне нужно что-то записать на флэш-память.

Какие меры предосторожности следует предпринять при записи на флэш-память (через интерфейс PATA)? По причинам, которые я не могу вспомнить, я использую ext4 файловую систему, смонтированную с barrier=1,data=ordered,nodelalloc,noatime,ro Является ли что-нибудь из этого ужасной идеей? Система должна загружаться быстро без вмешательства пользователя. Я испытываю желание сделать tune2fs -c 0 -i 0. Это еще хуже идея?

Кроме того, когда я пишу что-то, мне, очевидно, нужно перемонтировать флэш-чтение-запись, выполнить запись, а затем перемонтировать только для чтения. Проблема в том, что для этого может потребоваться несколько разных процессов (как двоичных, так и командных сценариев c ++). Понятно, что каждый процесс без разбора перемонтирует файловую систему только для чтения, когда он завершен. Это плохая идея.

Какой лучший способ скоординировать это? flock выглядит многообещающе; это лучший путь и о чем мне беспокоиться? Я не хочу, чтобы устаревшая блокировка блокировала записи или оставляла файловую систему доступной для записи на неопределенный срок.

Чтобы уточнить: Под «случайным» написанием я подразумеваю, что система может работать годами без необходимости что-либо писать. Когда что-то записывается, это может быть пара сотен байтов. В то же время система должна выдерживать непредсказуемые циклы питания без какого-либо вмешательства.

Answer 1

Обеспечение безопасности ext4

ext4 не совсем подходит для этого; В худшем случае всегда происходит сбой питания, когда ваш раздел RW и портит файловую систему.

Несмотря на то, что они предназначены для необработанных устройств NAND, файловая система регистрации, такая как jffs2 или yaffs, все еще может быть полезной. Они имеют полезную особенность в том, что их формат на диске больше похож на список, а не на дерево, поэтому новые данные, как правило, упаковываются более тесно и, таким образом, с меньшей вероятностью удаляют относительно статичные части файловой системы.

Я не могу комментировать, как сделать ext4 «безопасной» в этих условиях; и структура файловой системы, и fsck не знают о распространенных режимах сбоев флэш-устройств (в частности, что во время любой записи существует длительный период, когда целый блок данных недопустим.) Это поведение, конечно, специфично для контроллера на CF-карта, так что в любом случае она не очень предсказуема.

Самым безопасным и предсказуемым способом, который я могу придумать, является тот же макет данных флип-буфера, который используется в небольших встроенных устройствах. То есть у вас есть две области записи (два раздела). В любой момент времени, по крайней мере, одна из них должна быть согласованной. Когда вы хотите написать, выберите более старый из двух. Если вы включите питание и обнаружите несогласованность в буфере A, скопируйте содержимое буфера B через (и не разрешайте никакие записи в B за это время.)

Управление монтированием / перемонтированием

Я бы написал демон, который управляет размонтированием / перемонтированием от имени всех процессов в системе. Это имеет ряд преимуществ:

• вы выделяете логику umount / remount, и вам нужно реализовать ее только один раз
• процессам, которые хотят писать, не нужны привилегии root
• Вы можете встроить какой-нибудь сторожевой таймер, чтобы раздел не оставался RW слишком долго. Если это так, вы можете убить процесс, нарушающий работу (возможно, откат) и remount-RO.
• вы можете измерить, как долго вы монтируете RW, что дает вам некоторое представление о риске, связанном с обновлением

Answer 2

Я сделал встраиваемую систему, работающую с картой CF на 4 ГБ. Я настроил его на 3 раздела:

• / загрузки; ext2; ~ 128
• корень; SquashFS; 500 МБ (поскольку он недоступен для записи, нет возможности случайно перевести его в режим записи.)
• / данных; ext2; ~ 3,5 ГБ любых данных, которые я хочу сохранить

Я использую ext2, потому что я полагаю, что любая из журналирующих FS на самом деле приведет к изменению большего количества блоков для каждой записи. Также нет смысла запускать флеш-файловую систему на CF-карте, потому что система не имеет прямого доступа к флеш-блокам. Внутренняя карта CF содержит собственную логику сопоставления блоков.

Answer 3

Поскольку вы используете CF, вероятнее всего, встроено выравнивание износа, и вы не получите никакой пользы от использования файловой системы, такой как yaffs2, jffs2 и т. Д., В которой встроено выравнивание износа. Фактически большинство файловых систем выравнивания износа не рекомендуются для CF-карт со встроенным выравниванием износа. Тем не менее, вам нужна файловая система со встроенным журналированием, чтобы вы могли безопасно проходить циклы включения / выключения питания без повреждения системы. Здесь есть два варианта - выбрать файловую систему с журналированием или выбрать дБ (при условии, что записи ориентированы на дб) с выравниванием износа, как sqlite. Для файловой системы вы можете использовать либо ext3, либо ext4, хотя лично я рекомендую ext3, поскольку в ext4 все еще есть ошибки, которые могут причинить вам головную боль. Я также рекомендовал бы, чтобы другие имели два раздела, один из которых предназначен только для чтения с использованием файловой системы, такой как squashfs, cramfs, а другой - для чтения и записи с использованием ext3.

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

Answer 4

Я бы сделал отдельный раздел, на котором смонтирована rw.