На поле битвы современных технологий хранения данных Btrfs и ZFS (OpenZFS), несомненно, являются двумя из самых доминирующих файловых систем. Хотя обе построены на основе принципа COW (Copy-on-Write), а также предлагают возможности самовосстановления и создания моментальных снимков, они демонстрируют совершенно разные инженерные решения при работе с физическим уровнем хранения (например, RAID5/RAID50) и расширением устройств.
Справка: Файловая система ZFS (Zettabyte File System) появилась в 2001 году. Она была разработана компанией Sun Microsystems под руководством Джеффа Бонвика и Мэттью Аренса, и создавалась как 128-битная система для Solaris, призванная решить проблемы масштабируемости, надежности и управления данными. Компания QNAP начала использовать ZFS в сентябре 2020 года с выпуском специализированной операционной системы QuTS hero. Она была внедрена для обеспечения высокой целостности данных, поддержки практически неограниченных снимков состояния (snapshots) и эффективной дедупликации/сжатия данных, что критично для корпоративных NAS.
Справка: Файловая система Btrfs (B-treeFS) появилась в 2007 году, когда ее разработку инициировала корпорация Oracle с целью создать современную, отказоустойчивую и масштабируемую файловую систему для Linux, способную стать открытой альтернативой ZFS. Основным автором является Крис Мейсон, поставивший целью устранить недостатки старых файловых систем (ext3/4) и внедрить технологию CoW (Copy-on-Write). Btrfs появилась в устройствах Synology NAS с выходом операционной системы DiskStation Manager (DSM) 6.0 около 10 лет назад в качестве замены ext4.
1. Философские различия в механизмах записи: гибкость против эффективности
Btrfs и ZFS используют принципиально разные стратегии при обработке записи данных, и это различие напрямую определяет их соответствующие сценарии использования.
Btrfs: заполнение, подобное игре в тетрис
Btrfs абстрагирует физические устройства в логические блоки размером 1 GiB, известные как «chunks». Такая конструкция позволяет динамически определять ширину полосы во время записи на основе количества доступных в данный момент дисков. Ключевое преимущество — исключительная аппаратная гибкость. В рамках одного пула хранения можно смешивать диски разной емкости, и Btrfs будет максимально эффективно использовать пространство, как в игре в тетрис. С архитектурной точки зрения, у этой файловой системы отсутствует автономный профиль RAID50 — вместо этого она объединяет несколько блоков RAID5, фактически функционируя как параллельный RAID50.
ZFS: логика производительности на основе транзакций
ZFS, напротив, следует стратегии, ориентированной на производительность. В ней используется подход с переменной шириной полосы, и для каждой транзакции записи динамически определяется структура полосы. Преимущество ZFS заключается в полном исключении традиционного цикла RAID «чтение-изменение-запись» (RMW), что значительно повышает эффективность ввода-вывода. ZFS поддерживает запись с полной полосой. Она вычисляет четность в реальном времени на основе размера данных и выполняет запись с полной полосой, гарантируя, что четность не выходит за пределы границ данных. Если в вашей среде используются различные старые запасные диски, архитектура Btrfs хорошо подходит для смешивания дисков разного возраста и емкости. Однако, если вам нужна максимальная пропускная способность ввода-вывода и согласованность корпоративного уровня, архитектура транзакционного потока ZFS в данном случае имеет явное преимущество.
2. Стоимость расширения: перебалансировка против динамического потока данных
Что происходит, когда емкость хранилища уменьшается и добавляется новый диск? Это один из наиболее часто неправильно понимаемых аспектов среди операционных групп.
Стоимость полной перезаписи в Btrfs
Для использования нового диска и достижения большей ширины полосы Btrfs должна выполнить операцию балансировки btrfs. Результатом является процесс полной перезаписи. Для массивов в несколько терабайт этот процесс может занять несколько дней и создать значительную нагрузку на ввод-вывод. В результате, только после завершения длительного процесса перезаписи распределение данных и уровень RAID будут полностью преобразованы.
Преимущества и недостатки ZFS: логическая перестройка
ZFS не требует перемещения существующих данных во время расширения. Такое поведение называется «отсутствие принудительной перезаписи». В рамках этого механизма распределитель пула хранения ZFS (SPA) отслеживает свободную емкость и отдает приоритет направлению новых операций записи на (новые) устройства с большим свободным пространством. Это форма взвешенного распределения, ориентированного на емкость.
Однако существует распространенное заблуждение относительно расширения: многие ошибочно полагают, что данные автоматически перебалансируются после расширения, что неверно. Существующие данные остаются на исходных дисках, что приводит к возникновению «горячих точек» чтения. Количество операций ввода-вывода в секунду (IOPS) вновь добавленных дисков обеспечивает ограниченную выгоду при доступе к существующим данным. В таких случаях лучшим решением является достижение истинного баланса путем ручного выполнения перезаписи ZFS или использования новой технологии расширения RAIDZ. Однако следует отметить, что при наличии снимков это может привести к удвоению используемого пространства.
В последних версиях OpenZFS уже есть такие функции, как zpool remove и другие возможности модификации устройств, а также инструменты, которые можно использовать для перебалансировки. Проще говоря, модель расширения ZFS отличается от динамического расширения Btrfs, но она не является полностью статической. На практике, после определения емкости, более подходящим вариантом является соответствующая настройка и отказ от дальнейшего расширения. Предприятиям следует заранее оценить необходимые характеристики и совершать соответствующие закупки, чтобы избежать будущих проблем. Однако это также является недостатком ZFS, поскольку гибкость расширения всего RAID-массива не так высока, как у Btrfs.
3. Ключевое поле битвы за целостность данных: уязвимость записи в RAID
«Уязвимость записи» — это критический риск, возникающий при сбое питания во время процесса записи, потенциально приводящий к несогласованности данных и четности.
ZFS: структурная устойчивость
ZFS предотвращает эту проблему на архитектурном уровне, используя несколько технологий. Первая — это атомарные обновления: ZFS использует группы транзакций (TXG) и кольцевой буфер. Система сканирует кольцевой буфер, чтобы найти последнюю TXG с «действительной контрольной суммой». Неполные TXG (те, которые записываются во время сбоя питания) полностью игнорируются, и система немедленно возвращается к последнему согласованному состоянию. Вторая — это Merkle Tree (древо Меркла). Вся файловая система структурирована как массивное хеш-древо, где любое повреждение базовых данных приводит к сбою проверки контрольной суммы верхнего уровня, тем самым предотвращая скрытое повреждение данных. Сервера Uberblock служит единственным якорем доверия для этого дерева и никогда не перезаписывается на месте.
Btrfs: от экспериментального статуса к восстановлению через RST
Btrfs RAID5/6 долгое время считалась «экспериментальной» именно из-за фатальной уязвимости записи. В ядре Linux 6.2 была представлена структура RAID Stripe Tree (RST). Это новая древовидная структура, которая управляет физическим расположением на уровне экстентов и изначально была разработана для решения проблемы уязвимости записи. До этого Btrfs полагалась на полный цикл чтения-изменения-записи (RMW) для проверки контрольных сумм, что приводило к снижению производительности.
Однако, согласно официальной странице состояния btrfs readthedocs (по состоянию на ядро Linux 6.17), большинство функций Btrfs отмечены как «ОК» или «В основном ОК». RAID5/6 остается непригодным для использования в производственной среде и не отмечен как «ОК» в таблице состояния. Начиная с ядра Linux 6.12, для экспериментальных функций требуется включить CONFIG_BTRFS_EXPERIMENTAL, и сохраняются известные проблемы. Кроме того, основные причины возникновения «дыры записи» не были полностью устранены. Текущая реализация смягчает некоторые сценарии повреждения данных при записи, но долгосрочные последствия все еще требуют дальнейшего изучения.
В современных ядрах Linux (например, в серии 6.x) нативная поддержка RAID5/6 в Btrfs демонстрирует постепенное улучшение. За последние несколько лет сообщество Btrfs и разработчики исправили известные ошибки в реализации RAID5/6, однако основная реализация RAID5/6 еще не достигла полной зрелости или стабильности. В некоторых случаях, таких как восстановление данных после сбоя устройства, могут все еще возникать проблемы с надежным восстановлением.
Другими словами, хотя обработка RAID5/6 в современных ядрах стала более зрелой, чем раньше, она все еще уступает надежности, предлагаемой RAID1/10 или зрелыми реализациями, такими как RAID-Z в ZFS. Поэтому в технических дискуссиях по-прежнему целесообразно использовать более стабильные конфигурации RAID, такие как RAID1/10 или RAID5/6, построенные с помощью mdadm и дополненные Btrfs — в качестве альтернативы, а не полагаться напрямую на встроенную реализацию RAID5/6 в Btrfs в критически важных производственных средах.
На практике было обнаружено, что, хотя ядро Linux 6.2 и более поздние версии улучшают некоторые аспекты обработки записи и контрольных сумм в Btrfs, уязвимость записи все еще сохраняется — особенно в частных случаях, связанных с отключением питания и отказом устройств. В то же время операции проверки и балансировки могут оставаться медленными. На массивах большой емкости они могут занимать дни или даже недели.
4. Риски, связанные со снимками: скрытые проблемы в Btrfs
Снимки — это ключевая функция файловых систем CoW, но при расширении или реорганизации массива снимки могут стать обузой. В ZFS наборы данных и снимки формально разделены. В отличие от этого, подтома и снимки в Btrfs сохраняют гибкость, используя одно и то же внутреннее пространство имен.
Риск в Btrfs заключается в выполнении операции балансировки при наличии большого количества снимков, поскольку обновление экстентов, на которые ссылаются эти снимки, может вызвать отложенный взрыв ссылок. Это может привести к падению производительности до нуля. Даже были катастрофические инциденты, когда сбои проверки метаданных препятствовали монтированию файловой системы. Однако многие из этих проблем были устранены в более новых версиях Btrfs и последних версиях ядра Linux.
Устойчивость ZFS отражается в том, что ее указатели блоков являются неизменяемыми. Функция Reflow изменяет только физическую структуру на уровне RAID и не зависит от функций файловой системы, таких как снимки. Даже при наличии тысяч снимков расширение массива не угрожает целостности метаданных и не приводит к снижению производительности.
Что выбрать корпоративным пользователям?
При оценке пригодности Btrfs в корпоративных средах ключевым фактором является не наличие расширенных функций, а пригодность в качестве основы для хранения данных, способной выдерживать наихудшие сценарии. С инженерной точки зрения, Btrfs уже достаточно зрелая система в конфигурациях RAID1, RAID10 или с одним диском и несколькими копиями, и широко используется для системных дисков, управления образами и сценариев отката снимков в дистрибутивах Linux. Однако, когда требования к хранению данных смещаются в сторону эффективности использования емкости и отказоустойчивости, наиболее ценимых предприятиями (например, RAID5/6), модель риска Btrfs может не в полной мере удовлетворять их ожиданиям в отношении предсказуемых режимов отказов и надежности восстановления данных. Хотя Btrfs RAID5/6 постепенно устраняет некоторые известные проблемы в текущем основном ядре Linux серии 6.x, ее внедрение по-прежнему явно не рекомендуется для критически важных производственных сред. Это заставляет некоторые предприятия задуматься, готовы ли они принять на себя дополнительную неопределенность в обработке инцидентов, определении ответственности и долгосрочной эксплуатации и обслуживании.
В целом, нельзя сказать, что Btrfs непригодна для корпоративного использования, но эта фаловая система лучше подходит для системного уровня, уровня платформы или архитектур хранения, обеспечивающих защиту верхнего уровня. Напротив, для сценариев, в которых хранятся основные корпоративные данные, требуется многолетняя стабильная работа и которые сильно зависят от эффективности использования емкости RAID5/6, следует отдавать приоритет решениям с более высокой инженерной зрелостью и контролируемостью рисков, что уже сейчас предоставляет ZFS.
ZFS имеет более четко определенную роль в корпоративных средах. Ее основная конструкция предполагает, что система должна хранить критически важные данные в течение длительного времени и при этом сохранять согласованность и восстанавливаемость данных в экстремальных условиях, таких как сбои оборудования, аномалии электропитания или одновременные отказы нескольких дисков. Кроме того, ZFS объединяет файловую систему и управление дисками в единый стек хранения. Благодаря сквозным контрольным суммам, механизму Copy-on-Write и тесной взаимосвязи RAID-Z, она обеспечивает предсказуемые режимы отказов и зрелые процессы самовосстановления, что является именно теми инженерными характеристиками, которые наиболее ценятся предприятиями.
Поэтому ZFS особенно хорошо подходит для критически важных корпоративных хранилищ, бэкэндов виртуализации (например, виртуальных машин и контейнерных томов), крупномасштабных развертываний NAS и хранилищ резервных копий. Это особенно актуально в средах, где требуются архитектуры на основе четности, такие как RAID5/6, для баланса между эффективностью использования емкости и целостностью данных, поскольку ZFS обеспечивает более высокую стабильность и более предсказуемое поведение при отказах, чем большинство файловых систем общего назначения.
Конечно, ZFS имеет свою цену: более высокие требования к оборудованию, более высокие общие затраты и более жесткую модель расширения. Однако в масштабах предприятия такая философия проектирования, предполагающая обмен ресурсов на предсказуемость, часто более приемлема для организаций, обеспокоенных долгосрочной эксплуатацией, соблюдением нормативных требований и управлением рисками.
Обе файловые системы имеют свои преимущества
При интеграции модели RAID-Z, ZFS обеспечивает сквозное контрольное суммирование и механизмы самовосстановления, в то время как Btrfs в основном полагается на конфигурацию RAID и операции проверки для подтверждения данных. Однако Btrfs по-прежнему имеет существенные ограничения и риски в сценариях с метаданными и RAID5/6.
ZFS предъявляет относительно высокие требования к оперативной памяти, особенно при включенной дедупликации. Это необходимо тщательно учитывать при развертывании, поскольку может увеличить общую стоимость системы, особенно в эпоху высоких цен на память, что делает ее значительным фактором затрат. Взамен она также обеспечивает более высокую производительность и более высокую целостность данных.
Вот сравнение основных различий между двумя файловыми системами:
| Файловая система | Btrfs | ZFS |
| Аппаратная гибкость | Поддержка смешивания дисков | Более ограничительная (ограничения VDEV) |
| Влияние расширения | Высокое (требуется полная перезапись через балансировку) | Низкое (переполнение, перезапись не требуется, но необходимо отслеживать точки с высокой частотой чтения) |
| Защита от дыр при записи | Зависит от версии ядра Linux (6.2+ RST) | Архитектурная устойчивость (атомарные TXG) |
| Стабильность расширения снимков | Риск (взрыв отложенных ссылок) | Безопасность (неизменяемая защита от дыр при записи) |
Для крупномасштабных сред, где защита данных и долгосрочная надежность являются обязательными приоритетами, OpenZFS — это окончательный выбор. Ее стабильность, наряду с древом Меркла и атомарными обновлениями, обеспечивает математически проверяемую целостность. Именно поэтому QNAP позиционирует ZFS для корпоративных SAN/NAS
И если ZFS — это файловая система промышленного уровня, то Btrfs подойдет для опытных пользователей Linux, которым требуется гибкое управление дисками, например, использование старых дисков различной емкости в домашней лаборатории, и которые готовы управлять совместимостью версий ядра и особенностями работы.
