[devel] [phd@phd.pp.ru: ALT Linux Seminar session 3]

* [devel] [phd@phd.pp.ru: ALT Linux Seminar session 3]
@ 2001-10-01 15:32 Dmitry V. Levin
  2001-10-01 19:05 ` Ivan Zakharyaschev
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry V. Levin @ 2001-10-01 15:32 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 9329 bytes --]

Если кто пропустил...

----- Forwarded message from Oleg Broytmann <phd@phd.pp.ru> -----

Date: Sun, 30 Sep 2001 13:13:51 +0400
From: Oleg Broytmann <phd@phd.pp.ru>
To: Moscow Linux Users Group <mlug-list@mai.ru>
Subject: ALT Linux Seminar session 3
Mail-Followup-To: Moscow Linux Users Group <mlug-list@mai.ru>
User-Agent: Mutt/1.2.5i
Reply-To: mlug-list@mai.ru

24 сентября 2001 состоялось третье заседание семинара. Александр Боковой
(http://www.sam-solutions.net/) прочел лекцию "Журналируемые файловые
системы. Мифы и реальность".
   Лекция была отличная. Александр и выглядит хорошо, и умеет говорить, он
не суетился возле доски, и вообще поднял планку лекций семинара на такую
высоту, что следующим лекторам придется попотеть, чтобы допрыгнуть. :)

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

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

   Следующие общие слова Александр сказал об алгоритмах журналируемых
файловых систем. Большинство из них построено на основе сбалансированных
деревьев, иначе известных как B+ деревья
(http://starship.python.net/crew/aaron_watters/bplustree/bplustree.py.txt)
   Из четырех рассмотренных файловых систем 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 (http://www.netbench.com/), точнее, как
стало понятно из лекции чуть позже, с помощью его свободного аналога DBench
(http://freshmeat.net/projects/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. :)

Oleg.
---- 
     Oleg Broytmann            http://phd.pp.ru/            phd@phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

----- End forwarded message -----

Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread