FreeBSD: ZFS vs UFS, и обе — против всех

http://alv.me/?p=66
Автор: Алексей Федорчук

Много лет (в масштабах времени IT-сферы) я слежу за развитием файловых систем свободных Unix’ов вообще и файловых систем FreeBSD — в частности. Потому что при всех многочисленных достоинствах этой операционки быстродействие файловых манипуляций традиционно было узким её местом — по крайней мере, при настольном применении и в сравнении с файловыми системами соплеменного Linux’а. И мне хотелось верить, что эта “файловая пробка” рано или поздно будет ликвидирована. Результаты проверки моих ожиданий периодически размещались на моих старых сайтах, на этих страницах, а полную подборку всех старых материалов я недавно собрал в своём блоге (со временем она перекочует сюда).

Первый раз за сравнение файловых систем FreeBSD и Linux я принялся в 2001 году. Напомню, что в первой ОС (первых версий 4-й ветки) в то время применялась еще UFS (позднее её назовут UFS1), и механизм SoftUpdates при инсталляции не включался по умолчанию, его следовало задействовать ручными, хотя и не сложными, манипуляциями. А в Linux’е тогда безраздельно господствовала ext2: поддержка ReiserFS была только-только штатно включена в ядро, и эта файловая система считалась не вполне опробованной, до официального утверждения ext3 оставалось еще полгода, XFS примерно в это время была только-только портирована на Linux, но официального признания ещё не получила, а JFS, насколько мне известно, использовалась не очень широко.

Так вот, тогда UFS без механизма SoftUpdates сильно отставала по быстродействию от ext2 и reiser, с подключением же оного положение выравнивалось. К сожалению, результаты тогдашних измерений я найти так и не смог, но UFS+SU, несколько проигрывая ext2, шла практически вровень с тогдашней реализацией reiser (справедливости ради замечу — ещё довольно сырой).

Резкое изменение ситуации произошло с появлением UFS2 в 5-й ветке FreeBSD. Несмотря на многочисленные достоинства (64-разрядность, позволяющая работать с большими разделами, возможность фоновой проверки после сбоев и так далее), быстродействие её оставляло желать лучшего. В частности, в общем соревновании файловых систем, устроенном мной в 2004-м году, UFS2+SU во всех режимах монтирования вчистую проиграла всем файловым системам для Linux’а практически по всем показателям, разве что JFS местами продемонстрировала несколько худшие результаты.

Ситуацию с быстродействием UFS2 можно несколько подкорректировать — во-первых, монтируя её в асинхронном режиме, во-вторых, размещая её на программном RAID-массиве. Оба способа дают некоторый прирост производительности файловых операций (см. статьи по ссылкам), однако первый способ чреват снижением надёжности, второй же реализуем только при наличии более чем одного винчестера. И в любом случае скоростные характеристики UFS2 всё равно не дотягивают до ext2 или reiser.

Подмога для UFS2 пришла с неожиданной стороны — не по линии совершенствования файловой системы, а от производителей “железа”. А именно — от появившихся винчестеров с интерфейсом SATA. Измерения, выполненные на первых их моделях (2005 год, результаты приведены здесь), показали для UFS2 рост быстродействия некоторых файловых операций чуть не в два раза — уж в полтора практически для всех. Конечно, и быстродействие файловых систем для Linux’а с переходом на SATA-интерфейс также увеличилось, но органолептически — не в такой мере, хотя сравнительных измерений я тогда не проводил. В настоящей статье это упущение будет исправлено — уже по результатам для современного “железа” и, в частности, винчестеров SATA-II. Благо, для файловых систем Linux такая работа уже была проделана на той же самой аппаратуре.

Однако перед этим обратимся к другому событию — портированию на FreeBSD системы ZFS, являющей собой сочетание менеджера томов и собственно файловой системы. На её достоинствах здесь останавливаться не буду, замечу только, что они многочисленны и разнообразны; с некоторыми из них можно ознакомиться на в подборке переводных и оригинальных (искать по слову ZFS) материалов. А вот с рассмотрения быстродействия UFS2 и ZFS мы и начнём.

Конфигурация машины, на которой осуществлялось тестирование, описана здесь. Единственное изменение — в неё был добавлен третий винчестер, который на этот раз и выступал в качестве игровой площадки. Ну и схема размещения дисков несколько изменилась.

Первым диском теперь выступает 500-гигабайтник, несущий Linux’ы и его файловые системы и потому интереса для нас не представляющий — как я уже говорил, сравнительные материалы для файловых систем Linux берутся из предыдущей заметки.

Номер второй — SATA-II на 160 Гбайт от Samsung с 8 Мбайт встроенного кэша. Он был разбит на два слайса. На первом созданы корневой раздел (/dev/ad6s1a) размером 512 Мбайт и раздел подкачки (/dev/ad6s1b) на 12 Гбайт. И то, и другое было использовано для установки FreeBSD 7.1 PreRelease.

Второй слайс (всё, что осталось от первого) был отдан на растерзание ZFS как пул tank, в котором выделялись файловые системы под каталоги /tmp, /var, /usr, /usr/local и так далее (детали разбивки нам сейчас не важны), а также под каталог /usr/home в качестве рабочего хранилища данных.

И, наконец, номер третий — опять же SATA-II от Samsung, хотя и всего на 120 Гбайт, но с тем же восьмимегабайтным кэшем. На нём тоже было создано два слайса. Первый, размером в 20 Гбайт, зарезервирован под иные, пока тайные, цели, второй же, около 100 Гбайт, предназначался собственно для предстоящего тестирования, методика которого — то есть его объекты и совершаемые над ними действия, — была описана в предыдущей заметке о файловых системах Linux (с соответствующими поправками на ОС, разумеется).

То есть: сначала весь слайс размечался как раздел /dev/ad8s2d, и на нём была создана файловая система UFS2+SU. На него, после монтирования (в режиме по умолчанию, то есть noasync) и установления прав доступа для обычного пользователя, из файловой системы ZFS, смонтированной в каталоге /usr/home, копировался массив данных для тестирования. Каковой, напомню, включал в себя каталог с музыкальными файлами формата FLAC (357 Мбайт), дерево портежей Gentoo (суммарно 229 Мбайт), avi-файл размером 3,4 Гбайт и iso-образ компакта (586 Мбайт). Далее, внутри тестового раздела, над объектами тестирования проводились операции копирования и удаления (с замерами времени).

После всего этого раздел размонтировался, удалялся, а освободившееся пространство было переопределено как пул ZFS tank2, на котором размещена единственная файловая система ZFS же, монтировавшаяся в каталог /usr/home/mnt. В нём, после установления прав доступа обычного пользователя, были повторены все предшествующие процедуры.

Результаты этих процедур приведены в таблице 1. В ней же даны заимствованные из предыдущей заметки сравнительные данные для файловых систем Linux — ext2 и ext3 (ordered) с параметрами монтирования по умолчанию, reiser с опциями монтирования notai,noatime, размещённых на дисковых разделах.

Таблица 1. Сравнительное быстродействие файловых систем UFS2, ZFS, ext2, ext3 и ReiserFS

Тест Копирование Удаление
Действия Всё Музыка Портежи Avi Iso Портежи Всё


UFS2 02:28 00:07 01:09 02:55 00:29 00:22 00:17
ZFS 02:50 00:12 00:29 02:30 00:21 00:16 00:15
Ext2 05:10 00:08 01:28 03:09 00:31 00:18 00:20
Ext3 04:37 00:06 01:41 02:36 00:25 00:17 00:43
ReiserFS 04:22 00:07 01:29 02:37 00:25 00:04 00:09


Первое, что бросается в глаза при обращении к таблице 1 и серии иллюстрирующих её диаграмм (рис. 1-5) — то, что современные SATA-диски наконец-то позволили преодолеть вековое отставание UFS от файловых систем Linux: для всех операций над всеми объектами быстродействие их оказалось сопоставимым, а в некоторых случаях UFS2 вырвалась вперёд.

Последнее особенно ощутимо для операции валового копирования с раздела на раздел. Напомню, что раздел-источник располагался на другом диске и нёс на себе файловую систему ZFS. Сочетание этих факторов, видимо, и определило столь значительный отрыв от аналогичной операции для файловых систем Linux, где валовое копирование выполнялось между разделами, лежащими на одном диске, а раздел-источник нёс на себе файловую систему ext3 (ordered): при копировании массива данных на файловые системы Linux, лежащие на программном RAID’е, преимущество UFS (и ZFS) оказывается не столь явным.


Так что очень большого значения абсолютным цифрам при сравнении UFS с файловыми системами Linux я придавать не буду. Ограничившись констатацией того факта, что их быстродействие стало сопоставимым. Правда, похоже, что заслуга в этом не файловой системы FreeBSD: просто современные “винты” с их быстро считываемыми пластинами и огромными встроенными кэшами, подобно револьверу Кольта, уравняли шансы.

А вот про сравнительное быстродействие UFS2 и ZFS сказать стоит: тут различия нельзя списать на повышение производительности железа. А различия, я думаю, видны из табл. 1 и рис.1-5. И они по большинству показателей явно в пользу ZFS. Для подтверждения этого я провел еще несколько измерений — теперь уже только для файловых систем FreeBSD при условиях, только что описанных:
развёртывание архива портов FreeBSD (архив tar.gz, 40 Мбайт) последовательно на UFS- и ZFS-разделы
копирование экстрактированного дерева портов (200 Мбайт суммарно);
удаление копии каталога с деревом портов.

Результаты измерения времени, затраченного на эти манипуляции (они не вполне идентичны манипуляциям над деревом портежей Gentoo вследствие различия их внутреннего устройства) приведены в таблице 2.

Таблица 2. Время выполнения операций над деревом портов FreeBSD в файловых системах UFS2 и ZFSПорты Untar Copy Delete


UFS2 00:47 01:53 00:27
ZFS 00:12 00:31 00:17

Даже в табличном виде производит впечатление, не так ли? А уж в графическом воплощении — просто ошеломляет

И потому, даже на фоне возрастания скорости файловых операций в UFS2 за счет роста быстродействия винчестеров и вообще нивелирующего влияния оных, у нас не возникает вопроса, какое пиво пить. Возникает другой вопрос: кто бежит за водкой?

Да, файловая система ZFS во FreeBSD имеет статус экспериментальной, и надёжность её в этой операционке, в отличие от родного для неё Solaris’а, еще не проверена временем. Но ведь это не более, чем вопрос времени, и я думаю, что не столь уж длительного. Так что если промышленное применение ZFS на критически важных серверах — штука пока рискованная, то уж использовать её в личных целях на домашних машинах можно вполне. При условии регулярного резервного копирования жизненно необходимых данных, разумеется. Но эту процедуру не отменяли ещё никакие достижения в области построения файловых систем…

Обновлено: 12.03.2015