Яка файлова система пропонує найкращий захист для захисту даних від корупції через втрату електроенергії?


9

Я біг невеликого uClibcі busyboxвбудована система , засновану на x86 - пристрої. Я використовую initramfs, але також монтую користувальницький ext3каталог на компактному флеш-пристрої в режимі IDE, який я використовую для зберігання стійких даних журналу вимірювань, створених спеціально написаним додатком c ++. Я вибрав ext3файлову систему, як це рекомендується для безпеки від втрати електроенергії при використанні приводів CF в режимі IDE в декількох книгах, які я прочитав ( Створення вбудованих систем Linux Каріма Ягмура та Вбудований праймер Linux Крістофера Холлінана). Це особливо важливо, і дані є критичними.

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

  1. Є чи на ext3самому ділі кращий вибір для цієї установки?
  2. Чи втрата електроенергії під час операції запису диска лише пошкоджує частину даних, яку я періодично додаю до файлу, або може пошкодити весь файл?
  3. Чи дані, які не записуються в момент втрати електроенергії, цілком безпечні? Зокрема, чи є ризик того, що мій initramfs.cpioфайл також може бути пошкодженим?
  4. Чи є якийсь метод, який я можу використовувати у своєму коді програми для захисту даних (тобто створення додаткового розділу та записування моїх даних у дзеркальні зображення, щоб завжди було 2 копії) - швидкість не є справжньою проблемою для мого додатка, тому дорогі операції з копіювання є прийнятними.

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

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

Відповіді:


11

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

Деякі з цих машин навіть працювали на файлових системах, які не реєструються (зазвичай ufs та ext2). Деякі з них були вбудованими, а деякі - мобільними телефонами, як Nokia N900 - тому хороший блок живлення зовсім не був гарантований.

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

Відповідаючи на ваші буквальні запитання:

  1. Принаймні, перша книга, на яку ви згадувались, була написана раніше ext4- коли автор пропонує використовувати ext3, вони дійсно говорять "не використовувати нестабільні або нереєстровані файлові системи, як-от ext2"). Спробуйте ext4, він досить зрілий і має кілька пристойних варіантів для неперекручуваних дисків, які можуть продовжити тривалість життя вашого флеш-пристрою.
  2. Цілком ймовірно, що ви втратите останній-два блоки, а не весь файл. З файловою системою, що ведеться журналом, це стосуватиметься лише єдиних втрат. Існують сценарії відмов, де я міг бачити випадкові дані, розпорошені по файлу, але вони здаються приблизно такими ж ймовірними, як мікрометеорит, що потрапляє прямо через ваш вбудований пристрій.
  3. Дивіться 2. Ніщо не є безпечним на 100%.
  4. Якщо у вас є другий канал IDE, вставте туди другу CF-карту і періодично захопіть резервну копію файлової системи. Є кілька способів зробити це: rsync, cp dump, dd, навіть при використанні md(4)(програмне забезпечення RAID) пристрої (додати другий диск іноді, нехай це синхронізувати, а потім видалити його - якщо обидва пристрої знаходяться під напругою весь час, вони біжать такий же ризик пошкодження файлової системи). Якщо ви використовуєте LVM, ви можете навіть робити знімки. Для вбудованого пристрою збору даних я б просто застосував спеціальне рішення, яке монтує другу файлову систему, копіює через журнал даних та негайно відключає його. Якщо ви турбуєтесь про те, що пристрій має гарне зображення завантаження, наклейте другу копію диспетчера завантаження та всі необхідні зображення завантаження на другому пристрої та налаштуйте комп'ютер для завантаження з будь-якої CF-карти.

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

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


+1, однак реплікація страждає від тих же проблем, що і первинна копія - якщо ви почнете синхронізувати два пристрої (будь то через RAID або утиліту вищого рівня), і живлення вимкнеться (поки постійне додавання даних), ви знову сміття. Що може допомогти - це те, що час від часу RAID1 фізично змінює один з пристроїв і робить автономну резервну копію видаленої. Вам потрібно заморозити FS перед тим, як видалити його, щоб переконатися, що він є послідовним (тобто зробити знімки). XFS - одна з файлових систем, яка підтримує це.
петерф

Справді. Як я писав, гарантій немає. Щоразу, коли ви пишете дані, у вас може виникнути корупція. Люди на електроніці.stackexchange.com грають із суперконденсаторами та виявленням коричневого виходу, де вбудована система отримує сповіщення про вимкнення живлення, і все ще отримує достатньо соку для переривання записів. Можливо. :) Вся справа в тому, наскільки ймовірно, ви вважаєте, що це потенційна небезпека, і скільки грошей / зусиль ви хочете витратити, щоб усунути проблему під рукою (і почніть розглядати наступну).
Алексіос

Дякую за цю відповідь. Це значно роз’яснює для мене речі.
математик1975

4

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

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

Ви сказали, що ефективність насправді не є великою проблемою, тому з розумом використовуйте fsync().

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

Я використовую файлові системи extN протягом багатьох років особисто та на Інтернет-серверах із низьким середнім рівнем трафіку, і, як і Alexios, я не бачив багато корупції через відключення електроживлення (хоча, якщо чесно, сервери мають UPS і не можу згадати одна з них насправді йде вниз). Набагато серйознішою проблемою є корупція внаслідок апаратних збоїв, які різні файлові системи можуть (знову ж таки) бути все більш і менш здатними впоратися з проблемою, але (знову ж таки) це в принципі поза їх контролем, і вони не можуть її запобігти.

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

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

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

Чи є якийсь метод, який я можу використовувати в коді програми для захисту даних?

Варто повторити пункт про fsync () . Для об'єктів C ++ / iostream немає методу цього (:: flush і :: sync не fsync), але все, що вам потрібно, - це дескриптор файлів.


Дякую за цю відповідь, дуже корисно також. Я монтую розділ, на який записується через syncопцію у /etc/fstabфайл, оскільки я розумію, що це змушує запис відбуватися синхронно. Я припускаю, що це означає, що коли мій код запису файлу повертається, то дані фізично записуються на диск. Я зрозумів, що встановлення з syncпо суті робить те саме, що і дзвінок fsync(my_filedescriptor)після запису. Чи правильно я розумію це?
математик1975

@ mateician1975 Я би припустив, що це не те, що я досліджував. IMO, доки це не якось незручно, введення fsync()в точки, які ви вважаєте за потрібне, все одно не зашкодить , і зробить систему більш надійною (наприклад, якщо пристрій встановлено випадково без набору синхронізації тощо).
золотинки

1

ZFS, безумовно, є файловою системою, захищеною від корупції дизайном і, можливо, єдиною. Однак я не впевнений у доступності реалізацій ZFS (на основі запобіжників чи нативних) для платформ на базі uClinux.


0

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

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

Ознайомтеся з DataLight (компанія) та / або продукт " Reliance NITRO ". (Довіра - це їхнє застаріле і безпечне, але не дуже ефективне рішення, яке замінено Reliance NITRO ). Навіть якщо у вас немає грошей на користування цією системою, у них є досить непогані статті, в яких розповідається про те, як працює їх система, чому вона надійніша, ніж, наприклад, ext3 і ext4.

Мої вибачення, якщо це читалося як реклама, просто хотілося вказати на варіанти.


Привіт і ласкаво просимо на сайт. Якщо ви збираєтесь запропонувати товари, будь ласка, i) надайте посилання на відповідний продукт; ii) поясніть, чому це краще, ніж альтернативи (ви просто стверджуєте, що це виконує величезну роботу, але не пояснюйте, чому це краще за все); iii) якщо ви пов’язані з компанією, яка це робить, вам потрібно зробити це явним або бути звинуваченим у спамі (не кажучи про те, що ви є, просто головою вгору).
terdon
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.