Устойчивость Btrfs внутри RAID5

AFAIK это не будет иметь никакого значения.

RAID - это уровень абстракции для физических дисков, он делает несколько дисков / разделов похожими на одно «блочное устройство» для файловой системы. Некоторые уровни RAID (включая RAID1 и RAID5) могут прозрачно обрабатывать сбои физического диска: извлеките диск, и для файловой системы, похоже, ничего не изменилось.

Но файловая система работает поверх уровня абстракции «блочное устройство». Использование RAID5 в качестве блочного устройства помогает справляться с сбоями физического диска, но ничего не делает для самой файловой системы, поэтому риск повреждения файловой системы остается тем же.

Блоки RAID (mdadm 'chunks' с размером по умолчанию 64 КБ) отличаются от блоков файловой системы (размер по умолчанию ext4 4 КБ) и предназначены для обнаружения повреждений другого типа.

RAID5 работает путем разделения данных из файловой системы и записи одного фрагмента на каждый из дисков N-1 и контрольной суммы на N-й диск. RAID5 предназначен для обнаружения «поврежденных данных» в смысле поврежденных секторов, и в этом случае оригинал может быть восстановлен из контрольной суммы, а N-2 останется исправным.

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

См. в этой статье (pdf) примеры коррупции, которые остаются незамеченными RAID. В контексте повреждения файловой системы, я предполагаю, что «разорванные записи» (только некоторые из данных, которые должны были быть записаны на самом деле) особенно актуальны.

Программное обеспечение Linux RAID5 фактически усугубит ситуацию с перебоями в питании - намного хуже - по уже указанной причине. Даже в ext3 / 4 воспроизведение журнала после сбоя питания не не исправит несоответствие RAID5, которое неизменно возникает из-за того, что программный RAID не имеет собственного энергонезависимого «журнала» для воспроизведения. В результате происходит повреждение не только пользовательских данных, но и данных файловой системы в случае сбоя питания во время операции записи. Выделенные аппаратные RAID-контроллеры с кэшем с резервным питанием от батареи не страдают от этого, но это все еще не компенсирует отсутствие возможности запуска fsck на btrfs.

Если вы заботитесь о своей целостности данных, не запускайте btrfs без инструмента fsck и не запускайте RAID5 (или любой другой уровень RAID четности) без энергонезависимого кэша или ИБП.

При отказе диска RAID5 / 6 вся подсистема ввода-вывода временно застревает, когда ядро ​​пытается получить контроль над неисправным диском, сбрасывая шину SATA или диск. Задержка может занять десятки секунд, что каким-то образом повлияет на BTRFS, чтобы быть поврежденным, за исключением восстановления.

См. Отказ диска MDRAID приводит к повреждению BTRFS Ошибка ядра.