Запобігання пошкодженню даних на ext4 / Linux при втраті електроенергії

У мене є кілька вбудованих плат, на яких розміщені американські біоси Megatrends з вбудованим Linux як ОС. Проблема у мене полягає в тому, що ідеї промислового спалаху будуть пошкоджені при втраті електроенергії. У мене вони відформатовані як ext4. Щоразу, коли це відбувається, я зазвичай можу виправити спалах за допомогою fsck, але це не буде можливо в наших розгортаннях. Я чув, що відключення кешування записів повинно допомогти, але не можу зрозуміти, як це зробити. Крім того, чи є ще щось, що я повинен зробити?

Більше інформації

Привід - це флеш-модуль 4 Гб. У мене є один розділ, який є ext4. На цьому розділі встановлена ​​ОС, а grub - мій завантажувач.

fdisk -l показує / dev / sda як мій флеш-модуль з / dev / sda1 в якості мого основного розділу.

Після втрати електроенергії, як правило, я не можу це зробити повністю за допомогою скриптів для завантаження.

Коли я монтую накопичувач на іншому ПК, я запускаю fsck / dev / sda1. Він завжди показує повідомлення типу

"zero datetime on node 1553 ... fix (y)?"

Я виправляю їх, і він чудово завантажується до наступних втрат живлення.

Коли я приїду завтра до офісу, опублікую фактичний вихід fdisk -l

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

Ось вихід з dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

Кеш запису зазвичай не має нічого спільного з BIOS, в основному немає можливості переключити налаштування кеш-диска. Що стосується linux, використання hdparm -W 0повинно допомогти.

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

BTW: Я б подумав ідею про незаписувану кореневу файлову систему (щоб ваша система могла завантажуватись у певному «режимі відновлення» та дозволяти віддалений доступ, навіть якщо файлову систему, яку можна записати, з якихось причин не можна встановити). І якщо ви можете змінити конструкцію обладнання, подумайте про використання пристроїв mtd замість дисків IDE / SATA з файловою системою, відомої про спалах, як jffs2 . Ми вже кілька років використовуємо цю комбінацію з декількома вбудованими пристроями (в основному рішеннями маршрутизаторів VPN у цій галузі) з хорошими результатами.

Оновлення: корінь вашої проблеми, здається, полягає в тому, що ви запускаєте файлову систему ext4 з вимкненим журналом - has_journalвідсутній у Filesystem featuresсписку. Просто вимкніть усі сервіси, перевірте, чи все ще використовуються відкриті файли lsof +f -- /, перезавантажте кореневий розділ, доступний лише для читання mount -o remount,ro /, увімкніть журнал tune2fs -O has_journal /dev/sda1і встановіть "упорядкований" режим журналу як варіант монтажу за замовчуванням, використовуючи tune2fs -o journal_data_ordered /dev/sda1- вам доведеться повторно запустіть fsck (бажано з рятувальної системи) та перезавантажте корінь / перезавантажте після цієї операції.

Якщо ці налаштування встановлені, метадані гарантуються відновленням із журналу навіть у разі раптового відключення живлення. Фактичні дані також послідовно записуються на диск, хоча ви можете бачити дані за кілька секунд до втрати живлення під час завантаження. Якщо це неприйнятно, можливо, ви можете скористатися параметром tune2fs -o journal_data /dev/sda1кріплення з вашою файловою системою - це включатиме всі дані, записані на диск у журналі - це, очевидно, призведе до кращої узгодженості даних, але за рахунок штрафу за продуктивність та більш високий рівень зносу на вашому SSD.

Пропозиція кешу написання записів - вдалий початок, але це звучить як вада архітектурного дизайну. У вбудованій системі внутрішня спалах, ймовірно, НЕ повинна встановлюватися R / W, за винятком рідкісних обставин. Ви дійсно повинні проводити більшу частину роботи у файловій системі пам'яті та синхронізувати зміни до спалаху RW після певної команди користувача або регулярного інтервалу. Дійсно вбудована система використовує звичайну файлову систему (наприклад, ext4) у режимі rw під час звичайної роботи. Якщо є якась вимога програми, де вам потрібно багато місця для зберігання, вам слід подумати про те, щоб ваш системний розділ був іншим, і спроектувати його таким чином, щоб розділ даних можна було fsck -y'ed як частина запуску.

Якщо вам потрібні деякі вихідні моменти, я би роздивився, як люди налаштовують бездискові Linux-системи:

http://frank.harvard.edu/~coldwell/diskless/

і починати звідти. Загальна ідея полягає в тому, що ваші системні бінарні файли та дані можуть бути встановлені лише для читання, щоб ваша файлова система не була пошкоджена. Однак вам потрібно вміти писати до певних областей, тому вам зазвичай потрібно щось, як правило, файлова система пам'яті / tmp, / var / tmp. Навіть якщо певні речі потребують запису, ви просто створите скрипт для монтажу розділу як r + w, а потім виконайте зміни, а потім поверніться лише до читання.

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