2009-01-26
Эта статья написана по мотивам серии заметок, размещавшихся на блогосайте Алисы и alv'а по мере их сочинения. Ныне они собраны воедино, приведены в соответствие друг с другом, причёсаны, исправлены и дополнены. Автор выражает свою признательность Михаилу Рудаченко aka Ali и остальным участникам обсуждения соответствующей темы на форуме POSIX.ru.
Казалось бы, ZFS, интегрировав в себе файловую систему и систему управления разделами и томами, поставила точку в длинной истории тех и других. Если не затрагивать серверного сегмента, то обеспечиваемая ею легкость администрирования устройств хранения данных и быстродействие файловых операций неожиданно сделало анахронизмом все прочие системы этого назначения — в тех ОС, для которых она разрабатывалась (Solaris, OpenSolaris и его клоны) и на которые она портирована (FreeBSD и, по слухам, NetBSD).
Одна беда — на некоторые ОС она не может быть портирована в принципе, из-за лицензионных соображений. В число таких ОС попадает и Linux, несколько более популярный, нежели почти все перечисленные выше системы, вместе взятые: непосредственная интеграция ZFS в ядро невозможна из-за несовместимости лицензии. Конечно, предприимчивые пользователи Linux (уж чего-чего, а предприимчивости записным линуксоидам не занимать стать) немедленно прикрутили её через FUSE (Filesystem in Userspace — файловая система в пользовательском пространстве). Однако, исходя из общих соображений, представляется очевидным, что это не то.
Linux-мир не мог не ответить на наглое бесчинство компании Sun, выпустившей ZFS под лицензией CDDL. И таким ответом стала файловая система btrfs, разрабатываемая Крисом Мейсоном (Chris Mason) под эгидой компании Oracle, при участии волонтёров от FOSS-сообщества и распространяемая на условиях GPL. Работа над btrfs была начата в середине 2007 года, а уже к концу 2008 года был обещан её первый стабильный релиз, что было бы беспрецедентным случаем в области разработки файловых систем.
Чуда не произошло — и в ушедшем году btrfs в стабильной форме мы не увидели. Однако начало наступившего года было всё же ознаменовано радостными событиями: выходом в свет версии 0.17 — раз, её инкорпорацией в пре-релизное ядро linux-2.6.29-rc1 — два, и обещанием включить её поддержку в релиз ядра — три.
Волею обстоятельств личного характера во время Всенародного Рождественского запоя в ночь с 25-го на 14-е мне пришлось отложить до лучших времён и FreeBSD, и OpenSolaris, обратившись к Linux’у. Благо выход бета версии Zenwalk 5.4 дал к тому хороший повод. А поскольку после длительного общения с ZFS все “действующие” Linux’овые файловые системы оставляли чувство глубокого неудовлетворения, находящаяся в предродовой стадии ext4 не обещала ничего принципиально нового, завершения работы над файловой системой tux3 можно ждать разве что к турецкой Пасхе, взоры невольно обратились к btrfs. Тем более, что в ней были обещаны практически все особенности, делающие ZFS такой привлекательной для конечного пользователя — разве что кроме возможности вскипятить мировой океан.
Пацан решил — пацан сделал. После комплекса предварительных мероприятий btrfs была водружена на один из разделов одного из моих винчестеров и в первом приближении опробована в работе — пока в сугубо тестовом режиме. Благоприятный итог первого знакомства дал основание его расширить и углУбить. В результате чего вниманию читателей и предлагается настоящая статья.
Похоже, что btrfs действительно аккумулирует все передовые достижения Unix-like файловых систем за всё время их развития.
Действительно, на Btrfs Wiki её особенности сформулированы следующим образом:
Основанное на экстентах хранилище файлов (максимальный размер файла 264)
Со времён появления из недр проекта BSD файловой системы UFS механизмы хранения файлов развивались одновременно в двух направлениях: по пути внутренней фрагментации логических блоков — для экономии дискового пространства, и по пути группировки блоков в единицы, которые могут быть считаны одной атомарной операцией — для повышения производительности. Экстенты наиболее полно воплощены в XFS. В btrfs мы видим нечто похожее.
Эффективное с точки зрения экономии пространства размещение маленьких файлов.
Ничего не напоминает? Правильно, подход к маленьким файлам в Reiserfs. Что не удивительно — Крис Мейсон участвовал в её разработке.
Эффективное индексирование каталогов.
Представляется самоочевидным.
Динамическое выделение inodes
Шаг в этом направлении был сделан ещё в XFS.
Перезаписываемые снапшоты
Пожалуй, до сих пор эта идея лучше всего воплощена была в ZFS. В btrfs она дополнена снапшотами снапшотов.
Субтома — отдельные корни внутри единой файловой системы.
Похоже на то, как это реализовано в ZFS — с поправкой на различия терминологии.
Уровни зеркалирования и расщепления данных…
обеспечивающие надёжность или (и) быстродействие.
Контрольные суммы для данных и метаданных, для расчета которых доступны различные алгоритмы.
Обеспечивают восстановление целостности данных при сбоя.
Сжатие данных…
… на предмет экономии дискового пространства.
Интегрированная поддержка множественных устройств, с несколькими алгоритмами raid...
... а именно стриппингом, полной (зеркалирование) и частичной избыточностью. Что делает ненужным отдельные инструменты для создания программных RAID-массивов. Возможность подключения устройств "на лету" полностью перекрывает существующие средства управления логическими томами (LVM).
Онлайновая проверка целостности файловой системы.
Некогда предмет гордости UFS2 во FreeBSD — проверка смонтированных файловых систем в процессе работы.
Очень быстрая оффлайновая проверка целостности файловой системы.
Альтернатива предыдущему методу — если он почему-либо нежелателен: проверка отмонтированных файловых систем. В зависимости от ситуации, и тот, и другой метод обеспечивают быстрое восстановление работоспособности системы после сбоев — при современных объемах дисков это важно не только для серверов.
Эффективное инкрементное резервирование данных и зеркалирование файловых систем.
В комментариях не нуждается. “Не шутите с данными, ибо шутки эти глупы и неприличны”, как сказал бы Козьма Прутков.
Онлайновая дефрагментация файловой системы.
Для Unix-like файловых систем обычно не актуально, но может быть востребовано на файловых системах, сильно заполненных. Вообще, при разработке btrfs большое внимание уделяется поддержки “старых” (не в смысле возраста разработки, а в смысле времени использования) файловых систем.
К этому следует добавить также:
Журналирование по алгоритму Copy on Write
ранее реализованное в ZFS, и
конверсию файловых систем ext2/ext3 в btrfs без потери данных
Особенность, которая, насколько мне известно, не имеет ни аналогов, ни предтеч. Ну а о её значении можно особо не распространяться. Причём предполагается, что со временем механизм конверсии будет распространён и на ext4.
Наконец:
Режим оптимизации для работы на твердотельных устройствах, активизируемый посредством опций монтирования.
Вопрос этот приобретает всё большую актуальность — в связи с ростом объемов SSD-накопителей, падением их стоимости и всё более широким использованием в нетбуках, а в перспективе — и на десктопах. При этом ни одна из современных файловых систем общего назначения не ориентирована на эти устройства. Так что и тут btrfs оказывается уникальной.
Не все из перечисленных особенностей btrfs реализованы в настоящее время, и не всегда в полном объёме. Однако ко времени выхода её релиза (а можно предполагать, что он совпадёт с выходом ядра 2.6.29 — или наоборот) следует ожидать воплощения большей их части.
И тогда возникает вопрос: а его ещё остаётся желать от файловой системы?