Корректная файловая система SD-карты для встроенного Linux?

Недавно у нас была довольно неприятная ситуация с нашим клиентом - «киоск» на основе Raspberry Pi, используемый для отображения данных дистанционного зондирования (ничего более необычного, чем браузер в режиме киоска, отображающий самообновляющуюся веб-страницу с сервера сбора данных), не загружался из-за повреждение файловой системы. Ext4, требуется руководство по fsck, система станет частью важной презентации завтра, обслуживание требуется немедленно. Конечно, мы не можем требовать, чтобы клиент красиво выключал систему, выключая ее на ночь; система должна просто противостоять такому жестокому обращению.

Я хотел бы избежать таких ситуаций в будущем, и я хотел бы переместить ОС на файловую систему, которая предотвратит это. Существует множество файловых систем, предназначенных для устройств MTD, где их запуск на SD-карте (стандартное блочное устройство) требует серьезных прыжков в длину. Есть также некоторые другие файловые системы (журналирование и т. Д.), Которые могут похвастаться хорошим сопротивлением коррупции. Мне все еще нужно увидеть некоторые разумные сравнения их плюсов и минусов.

Какая файловая система, доступная в Linux, обеспечит наилучшую устойчивость к повреждениям при неожиданных сбоях питания и не потребует перехода через невозможные циклы, такие как yaffs2 , для установки на SD.

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

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

Выгоды:

1. сохраняя способность RW к файловой системе
2. современная, полнофункциональная файловая система с очень полезными опциями для RPi, такими как прозрачное сжатие и снимки
3. разработан с учетом флэш-памяти (среди прочего)

Вот как это сделать:

Я запускаю свой RaspberryPi на ArchARM linux, и моя карта находится в SD-ридере, поэтому измените эти инструкции соответствующим образом для других дистрибутивов и / dev интерфейсов.

Вот пример макета раздела:

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

Чтобы получить btrfs в RAID1, вы создаете файловую систему следующим образом:

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

Тогда вы rsync -aAXvк этому ранее резервировали систему.

Чтобы загрузить его из BTRFS в raid1, вам нужно изменить initramfs . Поэтому вам нужно сделать следующее, пока ваша система работает на старой файловой системе.

Raspberry обычно не использует mkinitcpio, поэтому вы должны установить его. Затем вам нужно добавить «btrfs» в массив MODULES в mkinitcpio.conf и пересоздать initramfs с помощью

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

Чтобы узнать, что печатать вместо YOUR_KERNEL_VERSION, запустите

ls /lib/modules

Если вы обновляете ядро, вы ДОЛЖНЫ воссоздать initramfs ПЕРЕД перезагрузкой.

Затем вам нужно изменить загрузочные файлы RPi.

В cmdline.txt вам нужно иметь

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

и в config.txt, вам нужно добавить

initramfs initrd 0x01f00000

После того, как вы все это сделали и успешно загрузились в RAID-систему btrfs, остается только настроить периодическую очистку (каждые 3-7 дней) либо с помощью системного таймера (предпочтительно), либо cron (dcron) следующим образом:

btrfs scrub start /

Он будет работать в вашей файловой системе, сравнивая контрольные суммы всех файлов и исправляя их (заменяя правильной копией), если обнаружит какое-либо повреждение.

Комбинация BTRFS RAID1, single medium и Raspberry Pi делает эту довольно загадочную вещь. Потребовалось некоторое время и работа, чтобы собрать все части воедино, но вот оно.

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

RAM диск

Если образ RPi не должен изменяться, и, похоже, он не меняется, если ничто не будет пытаться (или должно пытаться) записать данные на диск, попробуйте использовать корневую файловую систему, созданную для распаковки в ОЗУ . Идея в том, что при загрузке у вас есть сжатая корневая файловая система, которая распаковывается в ОЗУ. Все изменения происходят на RAM-диске, поэтому запись на SD-карту фактически нулевая, только чтение при загрузке. это должно сократить чтение / запись на ваш диск, сохраняя его жизнь. Это похоже на то, что происходит при загрузке Linux с компакт-диска , и это одна из первых вещей, которая происходит при загрузке Linux .

Я бы пошел другим путем и просто использовал бы файловую систему только для чтения. Я никогда не получаю свой Raspberry Pi достаточно стабильным при использовании корневой файловой системы для чтения и записи на SDCard. Вы можете либо просто загрузить свой root через ядро ​​cmdline (ro), либо использовать initramfs с piggyback, включая вашу полную систему.

И то, и другое можно создать с помощью моей самодельной системы сборки OpenADK. ( http://www.openadk.org )

Проблема в том, что использование «современной» файловой системы, такой как ext *, может привести к износу вашей SD-карты; из моего опыта, который случается в течение года или следующего года, если вы возьмете верхний предел.

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

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

Поскольку вы говорите, что ваша система также обрабатывает данные датчиков, весьма вероятно, что вы сохраните их на флэш-накопителях по мере их поступления. И они так же плохи, как данные журнала.

Я столкнулся с той же проблемой, с которой вы столкнулись, и вот мои выводы. Я попытался найти SD-карты, которые будут продаваться как «более надежные», то есть способные обрабатывать больше записей, чем другие, но я не нашел на рынке эталона, который бы фокусировался на этом, в отличие от тестов на SSD. Поскольку все они сосредоточены только на скорости, невозможно узнать количество записей на блок памяти и технологию, используемую в SDCard.

Тем не менее, я заметил, что у «промышленных» песочных дисков срок службы больше, чем у безымянных. Что неудивительно, когда вы платите больше, вы получаете больше.

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

Решение, которое я придумал, - это решения @ BigHomie и @wbx: использовать файловую систему extX только для чтения (поскольку журналирование больше не требуется, вы можете даже вернуться к старому доброму ext2). И если вы хотите вести журналы в течение сеанса или записывать временные файлы, вы всегда можете использовать RAMDISK.

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

NB: мой опыт использования Angstrom Linux на Beaglebone, среди пробного запуска 20 сенсорных устройств. Ведение журнала этой системы было очень многословным с использованием системы журналов systemd.

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

Ext2 файловой системы гораздо более хрупкой. Это очень хорошая файловая система для систем, которые могут монтировать ее только для чтения или размонтировать ее правильно. Но коррупция весьма вероятна из-за сбоя питания на ext2 .

Другим вариантом может быть рассмотрение jfs, даже если файловая система jfs не надежна в некоторых версиях Linux. Коррупция с jfs менее вероятна, чем с ext4 . Jfs также имеет быстрое время монтирования и время проверки файловой системы.