Гарантирует ли BTRFS согласованность данных при отключениях электроэнергии?

11

Как утверждает ZFS ,ZFS считается неуязвимым ZFS признает, что он может быть уязвим к сбоям питания.

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

btrfs failure-resistance ceremcem
источник
прочти снова. «Если ваш пул поврежден из-за сбоя оборудования или отключения питания, см. Устранение повреждения всего пула хранилища ZFS». (..) Попытка восстановить пул с помощью zpool clear -F команды
Майкл Д.
Итак, вы говорите: «ZFS не гарантирует целостность данных, а только пытается восстановить»?
ceremcem
Да. Здесь есть несколько кешей, встроенный кеш жесткого диска, кеш / буферы ОС. В какой-то момент существует syncили, flushкоторый записывает кэши на диск, или нет во время отключения питания, эти данные будут потеряны. ZFS может отлично работать, если жесткий диск исправен и нет перебоев в питании (или ИБП подключен для правильного выключения компьютера при сбое). Что вы не можете сказать о FAT32 или около того.
Майкл Д.
2
Потеря данных не является проблемой, поскольку это естественное последствие, когда происходит сбой питания, но в моем случае проблема заключается в согласованности данных. Файловая система может потерять данные в таких экстремальных условиях, но не должна вызывать несогласованность данных на диске. Мне нужен объект непрерывных снимков, так что я буду продолжать работать с BTRFS. NILFS2 - самый близкий вариант в моем случае.
ceremcem
1
Я задал вопрос на IRC #btrfs, они сказали, что should be ok if your hw isn't "buggy"означает "не глючит" your hw has correct flush/barrier semantics. Я разместил ссылку на этот вопрос в IRC, надеюсь, кому-нибудь понадобится время на разработку; но пока это все.
Привет, Ангел,

Ответы:

5

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

TL; DR: это означает, что btrfs защищен от повреждения данных из-за потери питания аналогично ZFS.

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

Вот как все должно вести себя при записи в файл:

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

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

Вот пример того, как что-то может пойти не так с «глючным» оборудованием:

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

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

На практике вы должны быть особенно осторожны при использовании RAID-контроллеров . Обычно они отключают кэши обратной записи на диске и вместо этого используют собственный кэш обратной записи. Есть два распространенных способа ошибиться:

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

Мартин
источник
Спасибо за это хорошее объяснение. Тем не менее, цитирование необходимо для всех претензий, включая IRC разговор. Тогда ваш ответ будет принят.
ceremcem
Что касается журналов IRC, я ссылался на комментарий @ Hi-Angel здесь. Может быть, он может предоставить ссылку? Я добавил еще несколько ссылок на другие части.
Мартин
BTRFS не использует деревья Merkle, он использует B-деревья (отсюда и «B-TRee FileSystem»), и ваши примеры ошибок требуют, чтобы аппаратные барьеры записи не были должным образом реализованы (что на самом деле является довольно необычным случаем в наши дни) , В противном случае хороший ответ.
Остин Хеммельгарн
Деревья, используемые btrfs, на самом деле являются B-деревьями (это свойство касается «формы» дерева и того факта, что они являются самобалансирующимися) и деревьев хеш-меркля (листья содержат хэш некоторых данных, узлы содержат хэш их детей, таким образом, каждое изменение распространяется вплоть до корня). Возможность проверить эти хэши - это то, что позволяет btrfs и ZFS обнаруживать поврежденные данные (и считывать их с другого диска, если используется в режиме «зеркалирования»).
Мартин