FreeBSD ZFS vs UFS, і обидві - проти всіх
17 September 2008 р
Багато років (у масштабах часу 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 прийшла з несподіваного боку - не по лінії вдосконалення файлової системи, а від виробників "заліза". А саме - від вінчестерів з інтерфейсом 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. У ньому, після встановлення прав доступу звичайного користувача, було повторено всі попередні процедури.