Снова про ZFS во FreeBSD: диск хорошо, а два лучше

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

Эта небольшая заметка написана по следам двух предыдущих — о быстродействии файловых систем Linux и о файловой системе ZFS в сравнении как с соплеменной UFS2, так и с двоюродными родственниками из Linux’а.

Во второй из указанных заметок сравнивались файловые системы, каждая из которых лежала на собственном дисковом разделе. В результате чего ZFS разделал под орех все файловые системы Linux’а. Однако в первой из заметок мы видели, насколько возрастает быстродействие всех нативных файловых систем Linux в случае, когда они базируются на программном RAID’е нулевого типа.

Однако и от ZFS, пул которой охватывает два раздела на разных дисках, тоже можно ожидать прироста в скорости выполнения файловых операций — не зря же она объединяет в себе функции менеджера томов и собственно файловой системы.

Что и было решено проверить — на той же аппаратной платформе (описанной здесь) и на тех же массивах данных и операциях (также описанных ранее и позднее дополненных).

В качестве операционной системы и на этот раз выступала пререлизная FreeBSD 7.1. И объектами издевательства остались всё те же два диска SATA-II от корейского брата Samsung’а, на 160 Гбайт (на втором разъёме, /dev/ad6) и на 120 (на третьем, /dev/ad8), оба с восьмимегабайтным кэшем. Первый же диск, на 500 Гбайт, по-прежнему нёс на себе Linux и в настоящем тестировании выступал как сравнительный объект со старыми показателями.

А вот разметка диска, естественно, немного изменилась. Корень файловой иерархии и раздел подкачки (512 Мбайт и 12 Гбайт соответственно) занимали разделы первого слайса 160-гигабайтника (далее будем условно назвать его первым диском) /dev/ad6s1a и /dev/ad6s1b. Они остались теми же самыми со времён прошлого тестирования. В пул же ZFS (без избыточности любого рода) были объединены второй слайс первого диска (/dev/ad6s2c) и единственный слайс второго, занимающий его целиком (/dev/ad8s1c). Размер элементов пула был подобран одинаковым с точностью до мегабайта — по 110 “истинных” гигабайт. Ведь, как известно, числа, фигурирующие в названиях диска для обозначения их ёмкости, даются в десятичной системе счисления и потому выглядят больше. Правда, не только производители дисков, но и пуристы от метрологии полагают, что именно эти гигабайты и являются “правильными”, гигабайты же двоичные следует именовать гибибайтами. Но мы оставим привычные единицы — ведь, кроме всего прочего, их проще пересчитывать в дисковые сектора и логические блоки файловых систем.

Пул ZFS был разделён на множество файловых систем — /var, /usr, /usr/local и так далее (детали сейчас не важны). В каталог /home также было смонтировано несколько самостоятельных файловых систем — /home/alv (мой домашний каталог исключительно для настроечных файлов), /home/data (для хранения рабочих данных) и другие, в том числе, созданная специально для целей тестирования — /home/test. Владельцем всех подкаталогов каталога /home был пользователь alv (то есть ваш покорный слуга), так что тесты выполнялись от лица обычного пользователя.

Как и ранее, сначала массив тестовых данных (каталог музыкальных файлов, дерево портежей, avi- и iso-файлы) копировались оптом из места своего постоянного пребывания в подкаталоге внутри /home/data в каталог /home/test. Внутри последнего они по очереди копировались и удалялись. После этого отдельно в /home/test копировался архив дерева портов FreeBSD, где он разворачивался, а полученное в результате дерево также копировалось и затем удалялось.

Результаты всех описанных манипуляций можно видеть в таблице, где для сравнения приведены также аналогичные данные из предыдущей заметки — для файловых систем UFS2 и ZFS в условиях, когда каждая из них лежала на своем собственном слайсе.

Таблица. Результаты измерения быстродействия файловой системы ZFSТест

Копирование Удаление Порты
Действия Всё Музыка Портежи Avi Iso Портежи Всё Untar Copy Delete
UFS2 02:28 00:07 01:09 02:55 00:29 00:22 00:17 00:47 01:53 00:27
ZFS-1 02:50 00:12 00:29 02:30 00:21 00:16 00:15 00:12 00:31 00:17
ZFS-2 02:27 00:08 00:25 01:35 00:14 00:09 00:14 00:11 00:24 00:11


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

Тем не менее, ZFS на “двураздельном” пуле смотрится еще более выигрышно в сравнении с UFS2. Так что при наличии двух (и более) винчестеров нет никакого резона отказываться от многодисковых ZFS-пулов, даже если нет желания создавать избыточность в виде зеркала или по схеме RAID-5.

А теперь посмотрим, как ZFS смотрится на фоне файловых систем для Linux’а при более или менее равных условиях — когда последние также лежат на томах, созданных из разных физических дисков, то есть на нулевом RAID’е (рис.2, сравнительные данные взяты отсюда.

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

Может быть, именно поэтому разработчики Linux’а особенно не комплексуют по поводу невозможности поддержки в своём ядре ZFS…

И тем не менее, ZFS — очень хорошая файловая система. Ведь главное её достоинство вовсе не в быстродействии, которое оказывается чем-то вроде бесплатного приложения. Нет, козырь её — простота обращения с дисковыми разделами, томами и файловыми системами на них. Причём такая, которая и не снилась Linux’овому LVM…

Обновлено: 12.03.2015