Сравнительное тестирование файловых систем под Linux

На Зелёном опять подняли вопрос о сравнении и целесообразности использования различных файловых систем. Я попробовал посмотреть в Гугле и обнаружил, что последний раз сравнительное тестирование делалось весной 2007 года. Поскольку за это время в ядро и драйвера fs были внесены существенные изменения решил освежить данные. Вот что получилось…

Сначала на чём тестировал. Четырехядерный Intel® Xeon® CPU X5355 @ 2.66GHz, 4G оперативной памяти. Файловые системы располагались на SAN HP EVA подключённой по Fibre Channel через два альтернативных линка. Размер тестовых файловых систем 50G. В тестах, где использовалась пара fs, каждая подключалась по индивидуальному FC-линку. Linux 2.6.27-gentoo-r8. Ядро оптимизировано под Core 2. Архитектура x32 PAE. Все файловые системы монтировались с параметрами по умолчанию.

Комментарий: x32 потому, что по данным Intel процессоры с архитектурой Core 2, если взять за базовую производительность в режиме x32 с плоской адресацией памяти, при использовании PAE теряют до 30% производительности, а в x64 до 40%

Цифры результатов предлагаю считать измеренными «в попугаях». Абсолютные значения на разном железе могут сильно отличаться. Точным можно считать соотношение показателей. Во всех тестах меньше — лучше.

Теперь собственно тесты и комментарии результатов.

Создание fs (форматирование)




— ext3 единственная из рассматриваемых честно создаёт все необходимые структуры fs при форматировании. Остальные собираются делать это по мере надобности в процессе использования fs.

Монтирование




— reiser, в отличие от остальных, тщательно проверяет fs при монтировании. ИМХО очень полезное свойство для корневой fs.

Теперь у нас есть пустые файловые системы. Сравним доступный объём.





Далее на одной из fs создаётся дерево каталогов с файлами размером от нескольких килобайт до десятков мегабайт. Посмотрим насколько эффективно файловые системы использовали дисковое пространство.




— reiserfs здесь абсолютный лидер.

Копирование дерева каталогов в пределах одной fs




— reiserfs и xfs делают это существенно быстрее ext3 и jfs. Обратите внимание, что у reiserfs, при этом, существенно больше system time. Это, грубо говоря, то процессорное время, которое будет отобрано у прикладных задач при работе собственно fs.

Копирование дерева каталогов с одной fs на другую




— этот тест демонстрирует способность fs к параллельной работе. В нём участвуют две fs. Обратите внимание, что по сравнению с предыдущим тестом результаты ext3 и jfs ухудшились, а reiserfs и, особенно, xfs улучшились.

Поиск файлов с заданным именем в дереве каталогов




— вот эти результаты для меня загадка. Очень неожиданные результаты xfs. Сижу и думаю, не ошибся ли я где.

Создание файла 10G длинными блоками 1M



— способность fs работать с файлами большого объёма. Лидерство xfs объяснимо. Её для этого и создавали. И это результаты работы fs без real time section. С ней лидерство xfs было бы ещё больше. Также хорошие результаты продемонстрировала jfs.

ЗЫ: Учитываем, что здесь речь идёт о последовательном доступе. Заливаем на fs поток данных с максимально возможной скоростью.

Создание файла 10G короткими блоками 1K




— стараемся усложнить задачу. Пишем файл короткими блоками. Удивительно, но jfs при этом существенно улучшает свои показатели.

Копирование большого файла с одной fs на другую




— как мы видели выше, у jfs не очень хорошо с параллельной работой, а у reiserfs с большими файлами. Победитель очевиден — xfs.

Файловые системы заполнены максимально. Посмотрим, что у нас с эффективностью использования пространства.




— Абсолютное преимущество reiserfs. Несмотря на наличие на всех fs двух файлов по 10G. Преимущество над ext3 составляет 10% (!) от общего объема файловой системы.

Удаление файлов, освобождение места на fs




— заметное отставание jfs. Объяснения этому у меня нет. Возможно jfs пытается оптимизировать fs под будущее использование.

Посмотрим, насколько «чисто» файловые системы освободили место.




— reiserfs и xfs выглядят так же, как сразу после создания. На jfs свободного места стало меньше. Что объяснимо (см. форматирование). На ext3 свободного места стало чуть больше, чем было сразу после форматирования.

Размонтирование fs, синхронизация, сброс грязных буферов




— лидерство jfs подтверждает предыдущее предположение. Обратите внимание что ситуация с массированным удалением файлов достаточно редкое событие. В «нормальном» случае, когда некоторые файлы создаются, некоторые удаляются, стратегия используемая jfs может оказаться «выигрышной». Особенно в условиях большой нагрузки на систему.

<ИМХО>
Выводы.

ext3 — не увидел ничего выдающегося. У меня ext3 только на boot partition.

jfs — на первый взгляд тоже ничего особенного. Но только на первый. Обратите внимание на маленький system time почти во всех тестах. jfs явный лидер по этому показателю. ФС явно старается не анноить работающую систему. Отличный выбор для боксов с большой вычислительной нагрузкой.

reiserfs — лучший кандидат для root partition, /usr, /var. Есть у меня подозрение, что на разделах до 16G показатели reiserfs будут значительно лучше. Обязательно проверю и напишу. А перечисленные разделы обычно меньше. Архивы образов CD, DVD, бэкапы на reiserfs лучше не хранить.

xfs — любые большие разделы, запись потоков, больших объёмов данных. Надо будет на серверах где много юзверей и большой /home перековать его на xfs.

</ИМХО>

Что не сделано и планы.

1. Обязательно повторю тесты на разделах до 16G и на разделах 250G (больше нету). Напишу.
2. Не проверены возможности fs по навигации внутри большого файла. Только последовательный (потоковый) доступ. По-этому делать вывод о целесообразности использования, например, xfs для размещения очень большого файла базы данных пока рано.
3. Было бы интересно повторить тесты не на raw partitions, а на логических томах LVM-а.

Автор: VaD_
Оригинал статьи: http://w2a.ru/blog/linux/252.html

_________________

С Уважением!

P.S. Един Admin и Support - подаван его!