Пошкоджена від пошкоджень файлова система SD-карт для вбудованого Linux?

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

Я хотів би уникнути подібних ситуацій у майбутньому, і я хотів би перенести ОС у файлову систему, яка б це не допустила. Існує купа файлових систем, призначених для пристроїв MTD, де для їх запуску на SD-картці (стандартний блок пристрою) потрібні серйозні стрибки з обручем. Існують також деякі інші файлові системи (подорож тощо), які можуть похвалитися хорошим опором проти корупції. Мені ще потрібно побачити певне розумне порівняння їх плюсів і мінусів.

Яка файлова система, наявна в Linux, забезпечила б найкращий опір проти корупції при несподіваних збоях живлення та не потребувала б переходу через неможливі обручі на зразок yaffs2 для встановлення на SD.

Збалансування зносу - це плюс, але не є вимогою - SD-карти зазвичай мають свої механізми, хоча і не більш досконалі, хоча система повинна бути "щадною для спалаху" (системи типу NTFS можуть знищити SD-карту протягом місяця).

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

Переваги:

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

Ось як це зробити:

Я запускаю RaspberryPi на Linux ARARM 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 . Тому вам потрібно зробити наступне, поки ваша система ще працює на вашій старій файловій системі.

Малина зазвичай не використовує 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

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

btrfs scrub start /

Він буде працювати у вашій файловій системі, порівнюючи контрольні суми всіх файлів та виправляючи їх (замінюючи правильну копію), якщо виявить корупцію.

Поєднання BTRFS RAID1, одиночного середовища та Raspberry Pi - це дуже приваблива штука. Щоб зібрати всі шматки, потрібен був певний час та робота, але ось це.

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

Оперативний диск

Якщо образ RPi не повинен змінюватися, і це звучить так, як ні, якщо нічого не буде намагатися (або слід намагатися) записати на диск, то спробуйте скористатися кореневою файловою системою, створеною для розпакування в ОЗУ . Ідея тут полягає в тому, що у вас під час завантаження у вас стисла коренева файлова система, яка розпаковується в оперативну пам'ять. Всі зміни відбуваються на диску оперативної пам’яті, тому фактично нульове записування на SD-карту, читання лише при завантаженні. це має скоротити читання / запис на ваш диск, зберігаючи його життя. Це схоже на те, що робиться під час завантаження Linux з компакт-диска , і це одне з перших речей, що відбувається під час завантаження Linux .

Я б пішов іншим шляхом і просто використав би файлову систему лише для читання. Я ніколи не отримую свою малину pi достатньо стійкою при використанні кореневої файлової системи для читання-запису на sdcard. Ви можете просто завантажувати корінь через cmdline ядра (ro) або використовувати initramfs з piggyback, включаючи вашу повну систему.

І те й інше можна створити за допомогою саморобної системи збирання OpenADK. ( http://www.openadk.org )

Ну, проблема у вас є в тому, що використання "сучасної" файлової системи, наприклад, ext *, швидше за все, зносить вашу SD-карту; з мого досвіду, який відбудеться протягом року, або наступного року, якщо ви візьмете вищий кінець.

Проблема полягає в тому, що сучасні файлові системи постійно переміщуються по блоках, щоб запобігти фрагментації даних. Що добре на спінінг-дисках, де потрібно зібрати всі свої дані, завантажуючи їх у кеш. Мінус полягає в тому, що він робить більше записів, які не можна кешувати, оскільки прибирання обробляється, коли відбувається не так багато вводу-виводу.

Це також трапляється, коли ви обробляєте багато журналів, що може знадобитися зробити під час налагодження вбудованого пристрою. Записи журналів - це найгірший вид записів, тому що регулярно відбувається багато крихітних записів, що породжує багато фрагментації.

Як ви кажете, що ваша система також обробляє дані датчика, дуже ймовірно, що ви зберігаєте їх у спалах, коли вони надходять. І вони такі ж погані, як дані журналу.

Я зіткнувся з тією ж проблемою, з якою ви стикаєтесь, і ось мої висновки. Я намагався шукати карти SD, які продаватимуться як "більш надійні", тобто вміти обробляти більше записів, ніж інші, але я не знайшов орієнтації на ринку, який би зосереджувався на цьому, на відміну від орієнтирів на SSD. Оскільки всі вони зосереджені лише на швидкості, неможливо дізнатися кількість записів на блок пам'яті та технологію, що використовується на SDCard.

Хоча я помітив, що "сандалії" промислового класу мали більший термін експлуатації, який не має назви. Що не дивно, коли платите більше, ви отримуєте більше.

Зрештою, із активованим інтенсивним веденням журналу я не виявив жодної SD-карти, яка би тривала довше, ніж на пару років, один рік, де настає найбільше смерть.

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

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

Примітка: мій досвід використання Angstrom Linux на Beaglebone, серед пробного запуску 20 сенсорних пристроїв. Журнал цієї системи був дуже багатослівним, використовуючи систему журналів systemd.

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

Ext2 файлової системи набагато більш крихкою. Це ідеально хороша файлова система для систем, які можуть змонтувати її лише для читання або відключити її правильно. Але надзвичайно вірогідна корупція при відключенні електроенергії на ext2 .

Іншим варіантом може бути розгляд jfs, хоча файлова система jfs не є надійною у деяких версіях Linux. Корупція є менш ймовірною для jfs, ніж для ext4 . Jfs також має швидкий час монтажу та перевірку файлової системи.