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

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

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

Я задал вопрос на 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-контроллеров . Обычно они отключают кэши обратной записи на диске и вместо этого используют собственный кэш обратной записи. Есть два распространенных способа ошибиться:

• Кеш RAID-контроллера - это ОЗУ. Если он не поддерживается батареей или подобной технологией, вы можете потерять значительный объем данных.
• Некоторые диски не отключают свои кэши обратной записи, когда их об этом просят . Это чаще случается с дешевыми настольными дисками, чем с серверными дисками, предназначенными для RAID.

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