Алексей Федорчук
17 сентября 2008 г
Много лет (в масштабах времени IT-сферы) я слежу за развитием файловых систем свободных Unix’ов вообще и файловых систем FreeBSD — в частности. Потому что при всех многочисленных достоинствах этой операционки быстродействие файловых манипуляций традиционно было узким её местом — по крайней мере, при настольном применении и в сравнении с файловыми системами соплеменного Linux’а. И мне хотелось верить, что эта «файловая пробка» рано или поздно будет ликвидирована. Результаты проверки моих ожиданий периодически размещались на моих старых сайтах, на этих страницах.
Первый раз за сравнение файловых систем FreeBSD и Linux я принялся в 2001 году. Напомню, что в первой ОС (первых версий 4-й ветки) в то время применялась ещё просто UFS, и механизм 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, являющей собой сочетание менеджера томов и собственно файловой системы. На её достоинствах здесь останавливаться не буду, замечу только, что они многочисленны и разнообразны; с некоторыми из них можно ознакомиться в соответствующей подборке материалов на этом сайте. А вот с рассмотрения быстродействия 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) оказывается не столь явным.
Рис. 1. Копирование музыкальных файлов
Рис. 2. Копирование дерева портежей
Рис. 5. Удаление дерева портежей
Так что очень большого значения абсолютным цифрам при сравнении 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 |
Даже в табличном виде производит впечатление, не так ли? А уж в графическом воплощении — просто ошеломляет (рис. 6).
Рис. 6. Операции над деревом портов FreeBSD, UFS2 и ZFS
И потому, даже на фоне возрастания скорости файловых операций в UFS2 за счет роста быстродействия винчестеров и вообще нивелирующего влияния оных, у нас не возникает вопроса, какое пиво пить. Возникает другой вопрос: кто бежит за водкой?
Да, файловая система ZFS во FreeBSD имеет статус экспериментальной, и надёжность её в этой операционке, в отличие от родного для неё Solaris’а, еще не проверена временем. Но ведь это не более, чем вопрос времени, и я думаю, что не столь уж длительного. Так что если промышленное применение ZFS на критически важных серверах — штука пока рискованная, то уж использовать её в личных целях на домашних машинах можно вполне. При условии регулярного резервного копирования жизненно необходимых данных, разумеется. Но эту процедуру не отменяли ещё никакие достижения в области построения файловых систем…
Прыкольно!!! :)
Где бы про неё (ZFS) подробнее почитать на русском?..