Чи гарантує BTRFS послідовність даних щодо відключення електроенергії?

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

Я не зміг знайти таку заяву для BTRFS. Чи довгостроково між відключеннями електроенергії (або розроблено / планується)?

Я задавав питання на #btrfs IRC, вони сказали, should be ok if your hw isn't "buggy"де не - "баггі" означає your hw has correct flush/barrier semantics.

TL; DR: Це означає, що btrfs захищений від пошкодження даних через втрату електроенергії аналогічно ZFS.

Ось чому: Загальна ідея ZFS та btrfs схожа. Обидва використовують дерева Меркле як структуру даних . Записи можуть вимагати оновлення декількох блоків на диску (дисках). Файлова система обробляє це, записуючи нові дані в порожні блоки (навіть якщо існуючий файл змінюється, таким чином, йому не потрібно змінювати блоки, що відображають старий стан) та будувати нове оновлене дерево. Після того, як все важке підняття буде зроблено і дані + оновлене дерево записуються на диск, вказівник голови оновлюється до нового дерева, роблячи видимі зміни.

Ось як слід вести себе під час запису у файл:

1. Запишіть дані у вільні блоки на диску.
2. Зробіть копію дерева Merkle *, оновіть її відповідно до змін, записаних у (1).
3. Попросіть апаратне обладнання передати дані на диск - апаратне забезпечення записує всі очікувані дані.
4. Оновіть вказівник голови на нове дерево Меркла.
5. Безкоштовні старі блоки, які вже не потрібні.

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

Ось приклад того, як все може піти не так з апаратним забезпеченням "баггі":

1. Запишіть дані у вільні блоки на диску.
2. Зробіть копію дерева Merkle *, оновіть її відповідно до змін, записаних у (1).
3. Попросіть апаратне обладнання передати дані на диск - апаратне забезпечення підтверджує завершення, але не проміє до кінця (наприклад, дані можуть залишатися в кеш-пам'яті запису на диску).
4. Оновіть вказівник голови на нове дерево Меркла. Ці дані записуються на диск перед іншими очікуваними даними (наприклад, тому, що головка диска знаходиться в потрібному місці).
5. Дані, записані в кроках (1) та (2), записуються на диск.
6. Безкоштовні старі блоки, які вже не потрібні.

Файлова система стане непослідовною, якщо втрачено живлення між (4) та (5) або під час виконання кроку (5). Як наслідок, дерево Меркле та / або дані можуть бути записані лише частково, що спричинить непослідовність файлової системи.

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

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

* Тут я спрощую речі. Фактично не потрібно копіювати все дерево. Необхідно додати лише ті зміни, які змінилися - решту частин можна розділити між старим і новим деревом .