CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
30.07.2016

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Файловые системы

Дистрибутивы :: BSD :: FreeBSD

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

Страницы: 1 :: 2 :: следующая

Много лет (в масштабах времени 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 :: 2 :: следующая

Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: следующая

аноним, Tue Jan 27 20:42:36 2009:
Не понял ни слова
Реальный опыт - если ставил ПСБСД 7.02 с файловой системой UFS SU (по умолчанию) - то просто скучал, глядя в окно, после каждого щелчка мышей
Та же система с ZFS yна том же разделе - после щелчка мышей можно сходить, попить кофе, покурить - и не торопитесь, а то замучаетесь ждать, когда вернетесь
Машина летает под УБУНТУ 8.10 - и железо вполне на уровне, особенно объем оперативки - 2гига, нормально, проц 1,8Ггц, Семпрон
Гоните, товарищ
аноним, Wed Jan 14 11:10:25 2009:
но реально можно и гораздо меньше сделать. но тогда не будет 4х кедов и прочего. в том числе и не нужного хлама.
аноним, Wed Jan 14 11:09:11 2009:
2 mumpster, среда, 14 января 2009 г. 08:52:48:

где то с гига даже на убунту своп вообще не используется. если только какие нибудь тяжеловесные проги, как оракл, тогда да, своп нужен большой. при установке просит и не ставится, если меньше. мандриву смотрел. что то около 490 под систему и 276 с чем то под кэш. примерно. точные цифры не помню. но гига хватает, чтобы полностью в ОЗУ осесть.
аноним, Wed Jan 14 11:09:09 2009:
2 mumpster, среда, 14 января 2009 г. 08:52:48:

где то с гига даже на убунту своп вообще не используется. если только какие нибудь тяжеловесные проги, как оракл, тогда да, своп нужен большой. при установке просит и не ставится, если меньше. мандриву смотрел. что то около 490 под систему и 276 с чем то под кэш. примерно. точные цифры не помню. но гига хватает, чтобы полностью в ОЗУ осесть.
mumpster, Wed Jan 14 08:52:48 2009:
> наличной памяти на 2
ну да - а если памяти будет 128 гигов - то своп что - на 256 делать что ли?
реально нужно делать не больше размера ОЗУ.
и то, трижды подумать.
аноним, Tue Jan 13 00:50:33 2009:
"Напомню, что раздел-источник располагался на другом диске и нёс на себе файловую систему ZFS. Сочетание этих факторов, видимо, и определило столь значительный отрыв от аналогичной операции для файловых систем Linux, где валовое копирование выполнялось между разделами, лежащими на одном диске."
Кто же так делает? Это же нельзя сравнивать!! понятно что с диска на диск скорость в разы больше
Alex Brainfucker, Tue Sep 23 09:43:12 2008:
Александр, скорость копирования/записи файлов очень сильно зависит от размера блока. Чем больше размер блока, тем быстрее будут производиться дисковые операции с большими файлами и наоборот. Люблю FreeBSD, но тест, имхо, весьма субьективен.
Алексей Федорчук, Sun Sep 21 18:35:09 2008:
2 arkhnchul
похоже, во Фре мы всё-таки меряем быстродействие дискового железа, а не файловых систем...
я ведь специально не стал акцентироваться на цифрах
в любом случае факт тот, что за фрю больше краснеть перед линуксом не приходится
аноним, Fri Sep 19 20:37:44 2008:
Фря меня прикалывает, нравится. Упорядоченна. С лялехом потыкался и плюнул. Как то все криво: то - так, то - этак.
Но, по скоку ламер, еще не понял как FS поменять. На этой я настроил все, кроме вебсайта и базы - за ненадобностью и невозможностью в локалке. Надо потренироваться при других условиях. Я так подозреваю - это надо делать при разбивки харда - тип fs? если кому не в лом подскажите? А, нет буду в гугле ковырятся. Все-ж общение приятнее.
arkhnchul, Fri Sep 19 10:40:49 2008:
попробовал тож повторить - у мну ZFS малость отстает от UFS, правда, на обычном сата, а не на II. И жертвы другие были: из мелких файлов - около 32к рандомно сгенеренных текстовиков размером от байта до 4 килобайт, крупный - образ винта qemu в 25 гигов.

Страницы комментариев: 1 :: 2 :: 3 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds