24 сентября 2001 состоялось третье заседание семинара. Александр Боковой прочел лекцию "Журналируемые файловые системы. Мифы и реальность".

Лекция была отличная. Александр и выглядит хорошо, и умеет говорить, он не суетился возле доски, и вообще поднял планку лекций семинара на такую высоту, что следующим лекторам придется попотеть, чтобы допрыгнуть. :)

Александр рассмотрел 4 наиболее известные файловые системы - ReiserFS, JFS, XFS и ext3 - однако не вообще, а применительно к конкретной задаче - создание высокопроизводительного надежного файлового сервера. Александр не назвал лучшую, и я не назову - сначала дайте критерии "лучшести". Как будет видно ниже, по разным критериям лучшие бывают разные.

Мифов же уважаемый лектор развеял немного. Первый и единственный миф - что журналируемые файловые системы спасут вас и ваши данные от любого сбоя. Нет, не спасут. Они просто предназначены для другого.

Вот, скажем, сценарий. Вы открываете файл, и пишете в него большой объем данных. В середине записи происходит сбой, перезагрузка, и после восстановления файл оказывается пустой. Нулевой длины. Как же так, говорите вы, а где же то, что я туда писал? Ответ такой - журналируемые файловые системы ТАК не работают. Они предназначены не для восстановления всех ваших данных любой ценой, а для поддержания непротиворечивости метаданных файловой системы на момент сбоя. Поэтому такая система работает так: вы открываете файл - и он успешно открывается, файловая система отмечает открытие в своем журнале записью транзакции. Затем вы начинаете писать. Но файловая система не запоминает копии этих данных. И когда происходит восстановление после сбоя, происходит откат до последней успешной транзакции - открытия нового пустого файла.

Следующие общие слова Александр сказал об алгоритмах журналируемых файловых систем. Большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья.

Из четырех рассмотренных файловых систем 3 используют сбалансированные деревья.

Второй способ оптимизации журналируемой файловой системы - вынесение журнала на другое независимое устройство (для асинхронного доступа). Это увеличивает эффективность системы на 30-50%! Не все из рассмотренных систем имеют вынос журнала. XFS имеет, для ReiserFS нужен особый патч.

В основной части лекции Александр рассказал подробности о каждой из файловых систем.

XFS была создана в начале 90-ых (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт; а больше и не надо - такое количество незакрытых транзакций тяжело получить.

JFS, журналируемая файловая система фирмы IBM, была создана для ОС AIX. В дальнейшем была перенесена на OS/2, но проявила себя там очень вяло. Нынешняя ее версия для Linux и то лучше. Размер журнала - примерно 40% от объема файловой системы, но не больше 32 мегабайт. Особенностью этой файловой системы являются "агрегаты" - в этой файловой системе может быть несколько сегментов, включающих журнал и данные, и каждый из таких сегментов можно монтировать отдельно.

Проект ReiserFS тоже начинался в 90-ых годах, первый прототип носил название TreeFS. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Уже есть патчи, интегрирующие Squid с ReiserFS, аналогичный проект начался для qmail. В этом смысле работа Ханса Райзера с коллегами уникальна, потому что они ведут научные исследования, и воплощают результаты в свободный код!

И, наконец, ext3. Это журналируемая надстройка над ext2. Достоинство ее в том, что она не меняет внутренние структуры ext2. Файловую систему ext3 можно создать из ext2 просто запустив программу создания журнала. Впоследствии эту файловую систему можно опять подмонтировать драйвером ext2. А потом опять драйвером ext3, и создать журнал.

Во второй части лекции Александр показал кучу графиков сравнения производительности 4-ех описанных файловых систем. Сравнение проводилось с помощью стандартного теста NetBench, точнее, как стало понятно из лекции чуть позже, с помощью его свободного аналога DBench. NetBench - это распределенный клиент, который с сотни виндовых машин дает нагрузку на файловый сервер - создает, переименовывает, пишет и читает файлы, всего около 90 тысяч транзакций. DBench создан Эндрю Триджелом, автором Самбы, еще когда он работал в SGI, и у него была возможность использовать сотню виндовых машин. DBench не является, как я понял, распределенным клиентом, а эмулирует NetBench на одной машине, но отклонение от результатов NetBench составляет 1%. Вполне приемлемо. DBench был создан так - через сервер с Самбой прогнали NetBench, и Самба все операции записала в лог.

Вот этим-то DBench'ем Александр нагрузил файловые сервера, создавая нагрузку, эквивалентную нагрузке NetBench от 1 до 25 клиентов. Результаты были представлены в виде графиков падения производительности на 1 клиента в зависимости от числа клиентов. Тестирование проводилось на сервер самой обычной конфигурации - Celeron 800Mhz, 256M памяти, 4 независимых IDE-контроллера; на одном Linux, на другом тестируемая файловая система, на третьем журнал (в тех FS, которые позволяют вынести журнал), один запасной.

Я не буду пытаться воспроизвести эти графики здесь, возможно, Александр опубликует их отдельно. Приведу лишь общие выводы. Вывод номер один, самый главный: на таком железе (даже не Pentium4) файловые системы обладают такой высокой производительностью, что забивают 100-мегабитную сеть. То есть для того, чтобы выйти на предел, уже надо было бы иметь гигабитный ethernet.

Теперь по отдельным файловым системам. Слабее всех проявила себя JFS. Ее производительность с самого начала невысокая, и падает она быстро. Зато ее падение производительности очень гладкое; тем, кому важна не только производительность, но и предсказуемость поведения, это важно.

Лучше себя ведет XFS. Ее производительность на 1 клиенте выше, и падает медленнее. А при вынесении журнала на независимый контроллер ее производительность сильно улучшается, и она приближается к топовым показателям. Про XFS следует отметить, что она разрабатывалась как файловая система для больших файлов, а NetBench выполняет операции с небольшими, поэтому можно предполагать, что на реальных файловых серверах XFS будет вести себя еще лучше. К тому же у этой FS тоже очень гладкий график падения производительности.

ReiserFS показал еще лучшую производительность, но зато у него негладкое падение. Где-то в районе 12-15 клиентов график начинает скакать вверх и вниз довольно резко (на вопрос из зала, воспроизводимо ли такое поведение, или это ошибка эксперимента, Александр ответил, что графики эти выверены, и все скачки воспроизводимы). После 15 клиентов график становится более гладким, возможно, за счет приближения к полной загрузке сети, а не файлового сервера.

Графики ext3 до такой степени мало отличаются от ResierFS, что на сводном графике и не увидишь разницы.

Особой проблемой является то, что во время интенсивной записи на диск файловые системы постоянно перебалансируют свои B+ деревья. Загрузка процессора при использовании XFS достигает 90%. ReiserFS дает 70%, потому что оптимизирует порядок операций. Другая оптимизация ReiserFS - она может упаковывать несколько маленьких файлов в один дисковый блок, а совсем маленькие - просто записать в inode :)

Что касается стабильности, то наиболее устойчивой оказалась ReiserFS, которую Александр назвал рабочей лошадкой, на которую вполне можно положиться.

Во время лекции и после нее возникло пара вопросов о совместимости журналируемых файловых систем с сетевыми. То есть можно ли поверх ReiserFS поставить NFS, или поверх XFS - Coda. Не все хорошо оказалось в этой области, но подвижки есть. Лучше всего должны быть совместимы Coda и ext3 - у них один автор Peter Braam. :)