Рассказы о ZFS. О файловых системах

Как известно еще с советских атеистических времен, Господь Бог, создавая человека, хотел сделать его умным, честным и партийным. Но оказалось, что даже он, при всём своём всемогуществе, не смог ему дать больше двух качеств вместе.

Аналогично и с файловыми системами: разработчики хотели бы видеть их быстрыми, надежными и простыми в обращении. Давайте посмотрим, удалось ли им превзойти Господа.

В UNIX-подобных системах требование быстродействия удовлетворяется, во-первых, оптимизированным расположением каталогов, метаданных и данных файлов на физических носителях. Но, во-вторых и главных — кэшированием записи.

Думаю, каждого, кто начинал знакомство с Linux’ом во времена безраздельного господства файловой системы ext2fs, поражала быстрота выполнения всех файловых операций, обусловленная их асинхронностью — то есть кэшированием данных и метаданных. Оборотная сторона медали — отказ системы по любой причине влек за собой тяжкие последствия, вплоть до полного ее разрушения. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) влекли за собой долгую и нудную процедуру проверки целостности файловой системы.

Файловые системы BSD-семейства (например, UFS, используемая во FreeBSD), в которых по умолчанию кэшируются только данные, а метаданные пишутся синхронно, в этом отношении вели себя лучше — но и не столь блистали быстродействием. Да и проверки целостности файловой системы после отказов и там были медленными и печальными.

Были разработаны различные механизмы решения этой проблемы. Так, во FreeBSD был разработан механизм SoftUpdates, который, как это ни парадоксально, способствует не только повышению устойчивости, но и некоторому увеличению быстродействия. Он обеспечивает, с одной стороны, контроль за последовательностью выполнения зависимых обновлений (что способствует целостности состояния файловой системы), с другой — группирует их в единую атомарную операцию синхронного обращения к диску, за счет сокращения числа коих и растет производительность (подробности здесь). Тем не менее, даже UFS+SoftUpdate, в сравнении с файловыми системами Linux, всё равно оставляла желать лучшего по части быстродействия. Что особенно стало заметно с переходом на 64-битную UFS2.

В Linux методы повышения устойчивости файловых систем развивались в другом направлении — так называемого журналирования. Суть его в том, что сведения о файловых операциях записываются в специальный файл журнала до того, как эти операции будут фактически выполнены. Это дает возможность после любого сбоя «откатить» файловую систему до последнего непротиворечивого состояния. Оборотной стороной чего, как обычно, является снижение быстродействия — различное для отдельных файловых систем и видов файловых операций.

Так, если ReiserFS во многих случаях может практически на равных конкурировать с ext2fs, которую можно принять за эталон быстродействия, то журналируемая надстройка над последней, etx3fs, ведет себя очень по разному при различных режимах журналирования (и, главное, абсолютно непредсказуемым образом). Современная журналируемая реализация линии ext2/ext3, то есть ext4fs, в плане быстродействия несколько подтянулась по сравнению с предшественницей, но по прежнему столь же непредсказуема при смене режима журналирования.

Правда, по слухам, форматирование в ext4fs с опцией «без журнала» позволяет добиться быстродействия прямо таки рекордного (и мои наблюдения этому не противоречат — хотя и не вызывают столь сильных эмоций). Однако в отношении надёжности мы тут откатываемся к ровню «дожурнальной» эпохи.

XFS, хорошо проявляющая себя при работе с (очень) большими файлами, пасует перед большими массивами файлов маленьких; а уж удаление последних — это сущий кошмар с точки зрения скорости. О быстродействии JFS говорить без слез трудно — правда, в ее реализации для Linux (говорят, что в родной AIX она по этой части показывает себя вполне достойно).

Правда, с точки зрения простоты использования ни в одну из файловых систем Linux’а бросить камень рука не подымется: создание и монтирование их никаких трудностей не сулит. Так что требование «партийности» выполняется, пожалуй, при всех соотношениях «ума» и «честности». Но эта ситуация сохраняется, пока…

… пока мы не начинаем комбинировать «ум, честность и партийность» файловых систем с аналогичными качествами систем управления RAID’ами или с LVM. В результате чего получаем:

  • либо быстрое и простое решение на основе RAID Level 0, не блещущее надёжностью,
  • либо надёжное решение без ощутимой потери быстродействия на основе одного из RAID с избыточностью, не являющееся, однако, эталоном простоты,
  • либо, наконец, относительно надёжное и потенциально быстрое решение при использовании технологии LVM — однако о простоте здесь можно сразу забыть.

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

И тут-то и возникает вопрос — а нельзя ли уменьшить количество уровней, сделать систему более «плоской»? Ведь история учит нас, что именно максимально «плоские» системы (например, римский легион и административный аппарат Британской Индии) были самыми эффективными в управлении.

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


Назад | Рассказы о ZFS | Вперёд