Для включения ядро Linux 6.2 предложены улучшения Btrfs, касающиеся исправления проблемы “write hole” в реализации RAID 5/6. Суть проблемы сводится к тому, что если крах случился во время записи, изначально невозможно понять какой блок на каком из устройств RAID записался корректно, а в каком запись не была завершена. В случае попытки восстановления RAID в подобной ситуации может произойти разрушение блоков, соответствующих недозаписанным блокам, поскольку состояние блоков RAID рассинхронизиорвано. Эта проблема возникает в любых массивах RAID1/5/6, где не принято специальных мер для борьбы с подобным эффектом.
В реализации RAID, наподобие RAID1 в btrfs, эта проблема решается использованием контрольных сумм в обеих копиях, при несовпадении данные просто восстанавливаются из второй копии. Этот подход также срабатывает если какое-то устройство начинает отдавать некорректные данные вместо полного отказа.
Однако в случае RAID5/6 файловая система не хранит контрольные суммы для блоков чётности: в нормальной ситуации корректность блоков проверяется тем фактом, что они все снабжены контрольной суммой, а блок чётности можно воссоздать из данных. Однако в случае частичной записи этот подход в определённых ситуациях может не сработать. В этом случае, при восстановлении массива не исключено, что блоки, попавшие под незавершённую запись, окажутся восстановлены некорректно.
В случае btrfs эта проблема наиболее актуальна, если производимая запись по размеру меньше страйпа. При этом файловая система должна выполнить операцию чтения-модификации-записи (read-modify-write, RMW). Если при этом попадутся блоки с незавершённой записью, в таком случае операция RMW может вызвать разрушения, которые не будут обнаружены, невзирая на контрольные суммы. Разработчики внесли изменения, при которых операция RMW проверяет контрольную сумму блоков до того как производить данную операцию, а при необходимости восстановления данных выполняет и проверку контрольных сумм после записи. К сожалению, в ситуации с записью неполного страйпа (RMW) это ведёт к дополнительным накладным расходам на вычисление контрольных сумм, однако значительно повышает надёжность. Для RAID6 такая логика пока не готова, однако для такого отказа в RAID6 необходимо чтобы запись не удалась на сразу 2 устройствах, что менее вероятно.
Дополнительно можно отметить рекомендации по использованию RAID5/6 от разработчиков, суть которых сводится к тому, что в Btrfs профиль хранения метаданных и данных может отличаться. При этом можно использовать профиль RAID1 (зеркало) или даже RAID1C3 (3 копии) для метаданных, а для данных RAID5 или RAID6. При этом обеспечивается надёжная защита метаданных и отсутствие “write hole” с одной стороны и более эффективное использование места, характерное для RAID5/6, с другой. Это позволяет избегать разрушений в метаданных, а повреждения данных могут быть исправлены.
Также можно отметить, что для SSD в Btrfs в ядре 6.2 будет активировано по умолчанию асинхронное выполнение операции “discard” (пометка освобождённых блоков, которые уже можно не хранить физически). Достоинством этого режима является высокая производительность из-за эффективной группировки операций “discard” в очереди и далее обработки очереди фоновым обработчиком, из-за чего нормальные операции ФС не замедляются, как в случае с синхронным “discard” по мере освобождения блоков, а SSD может принимать более удачные решения. С другой стороны, более не потребуется использовать утилиты типа fstrim, поскольку все доступные блоки будут очищаться в ФС без необходимости дополнительного сканирования и без замедления операций.