Общая тема : Руководство по "продвинутым" файловым системам, часть 9


Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs9.html


Презентация XFS.

Daniel Robbins (drobbins@gentoo.org)
President/CEO, Gentoo Technologies, Inc.
January 2002

С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. Daniel Robbins отвечает на эти вопросы по ходу пояснения инсталляции этих новых продвинутых filesystems под Linux 2.4. В этой статье Daniel представляет XFS, SGI's free enterprise-class файловую систему, ставшую доступной для Linux.

В этой статье мы познакомимся с XFS, SGI's free, 64-bit, высокопроизводительной файловой системой для Linux. Сначала будет проведено сравнение XFS с ext3 и ReiserFS и описаны некоторые из технологий, которые используют внутренние структуры XFS. В следующей статье будет описан процесс инсталляции XFS на вашей системе и даны несколько советов по настройке XFS и ее полезных features, например ACL (access control lists) и поддержки extended attribute.

Презентация XFS.

Файловая система XFS первоначально была разработана Silicon Graphics, Inc. в начале 90-х годов. В то время в SGI пришли к выводу, что их "базовая" файловая система (EFS) по скорости перестала соответствовать современным требованиям. Изучив проблему, в SGI пришли к выводу, что лучше "с нуля" спроектировать новую высокопроизводительную 64-bit файловую систему, чем попытаться модернизировать EFS. Рождение XFS произошло в релизе IRIX 5.3 в 1994. С этого времени именно эта файловая система становится базовой для всех SGI's IRIX-based продуктов для workstations на основе supercomputers. Совсем недавно XFS стала доступна и для Linux. Появление поддержки XFS в Linux событие значимое. Теперь Linux community обладает устойчивой, современной файловой системой с богатым набором feature, масштабной и удовлетворяющей самым высоким требованиям к хранилищам данных.

Сравнение производительности XFS с ReiserFS и ext3.

До недавнего времени выбор файловой системы для Linux был ободряюще прямым. Те, кому требовалась высокая производительность, склонялись к ReiserFS, а те, кого волновала целостность данных, предпочитали ext3. С появлением поддержки XFS для Linux выбор стал не столь прямолинеен. В частности, большой вопрос, а действительно ли ReiserFS при всех условиях является лидером по производительности?

Недавно мной было проведено тестирование с целью сравнения XFS, ReiserFS и ext3 в отношении raw performance. Но, прежде всего я замечу, что результаты отражают только общую тенденцию зависимости производительности файловых систем от нагрузки на однопроцессорной системе. Тесты, не претендуя на "абсолютную" истинность результатов, тем не менее, могут помочь в ответе на вопрос: для какой специфической задачи какой файловой системе следует отдавать предпочтение. И еще раз, результаты моего тестирования не рассматривайте как заключительные. В любом случае, для ответственного выбора следует проводить тестирование на конкретных приложениях.

Результаты.

Тестирование показало, что XFS очень быстрая файловая система. XFS постоянный лидер в тестах с манипуляциями большими файлами. Собственно такой результат вполне предсказуемый (она и проектировалась именно под это). Была замечена одна "причуда" в производительности - относительно медленные операции удаления файлов. В этом вопросе она проиграла и ReiserFS, и ext3. По замечанию Steve Lord (Principal Engineer по файловым системам в SGI) недавно был написан patch, решающий эту проблему (будет доступен в ближайшее время).

В других тестах производительность XFS была близка к таковой у ReiserFS и всегда превосходила ext3. Приятная особенность XFS - она не генерит (впрочем, как и ReiserFS) излишнюю дисковую активность. XFS пытается кэшировать как можно больше данных и "основанием" для сброса на диск является заполнение памяти, а не интервал времени. Когда происходит сброс данных на диск, это не оказывает заметного влияния на другие IO операции. Как противоположность - в ext3 (режим "data=ordered") периодический сброс данных на диск порождает проблемы с интерактивностью и, при высокой интенсивности операций IO, даже disk thrashing.

Следующие тесты на производительность и адаптацию к внешним факторам сосредоточились вокруг распаковки kernel source tarball на RAM disk и последующее рекурсивное копирование source tree в новый каталог на той же файловой системе. XFS справлялась с такой задачей хорошо, но проигрывала ReiserFS. Однако, после повторного mkfs.xfs и игры с опциями mount, XFS смогла немного "обойти" по скорости ReiserFS даже при обработке файлов среднего размера, характерных для kernel source tree. Словом, преимущество почти во всем, кроме маленькой детали - удаления старых файлов, "неудобной" для XFS операции (ReiserFS и ext3 удаляют файлы быстрее, чем XFS).

Выводы по производительности.

Сказанного достаточно для понимания общей идеи относительно ожиданий производительности от XFS. Результаты тестирования подтвердили, что XFS лучший выбор среди файловых систем, если требуются манипуляции с большими файлами. При работе с файлами среднего размера XFS вполне конкурентоспособна, а в ряде случаев даже немного быстрее ReiserFS. Последнее справедливо, если создавать и монтировать XFS с некоторыми performance-enhancing опциями. Ext3 в режиме "data=journal" показывает сравнительно неплохую производительность с учетом гарантии целостности данных (а не только метаданных). Однако дать по настоящему высокую оценку ext3 мешают проблемы при сбросе данных на диск.

Проект XFS.

В документе "Scalability in the XFS Filesystem" (смотри Resources) представленном в USENIX '96, инженеры SGI поясняют, что XFS была разработана под девизом "думайте о большем". И действительно, XFS снимает некоторые ограничения, присущие традиционным файловым системам. Остановимся на некоторых интригующих features проекта XFS.

Презентация allocation groups.

При создании файловой системы XFS основное block device разбивается на восемь или больше равных по размеру линейных областей. Их можно было бы назвать "chunks" или "linear ranges", но в терминологии XFS они именуются "allocation group". Уникальность allocation group в том, что каждая группа управляет своими собственными inodes и free space, что превращает группы в своего рода автономные sub-filesystem, сосуществующие в рамках общей XFS.

Allocation groups и масштабность.

А зачем разработчики XFS решили использовать allocation groups? В первую очередь это сделано для эффективной параллельной обработки операций IO. Поскольку каждая allocation group это эффективно управляемый автономный объект, ядро может распределять нагрузку между несколькими allocation groups. Без allocation groups код файловой системы XFS стал бы "узким горлом" для производительности, вынуждая IO-hungry процессы "выстраиваться в цепочку" для модификации inode и выполнения других операций над метаданными. Благодаря allocation groups код XFS допускает multiple threads, а процессы могут работать параллельно, даже при сложных IO операциях на одной файловой системе. Если у вас работает XFS, то ограничения по скорости, даже на high-end hardware, не будут определяться кодом файловой системы. Allocation groups в еще большей степени способствуют оптимизации параллельных IO операций на многопроцессорных системах, так как "in transit" одновременно могут находиться несколько модификаций метаданных.

B+ trees повсюду.

Внутренне, allocation groups используют эффективные B+ trees для отслеживания важных данных, например, диапазонов [ranges] (еще называются "extents") свободного дискового пространства и, конечно, inodes. Фактически, каждая allocation group имеет три B+ trees, при этом для отслеживания free space используются два. Одно дерево индексирует extents свободного дискового пространства по размеру, а второе - по начальной физической location на блочном устройстве. Способность быстро находить подходящие regions в free space - критическое условие для maximizing операций записи (то, что положительно отличает XFS от других файловых систем).

В XFS очень эффективно организовано управление inodes. Каждая allocation group ассигнует inodes как ей это удобно в группы по 64. Каждая allocation group хранит свои inodes, используя B+ tree, и каждый конкретный inode number может быть быстро найден на диске. Можно сказать, что XFS использует B+ trees где это только возможно, что и способствует повышению производительности.

Journaling.

Разумеется, как и большинство современных файловых систем, XFS поддерживает журналирование метаданных для быстрого восстановления в случае аварийной перезагрузки. Подобно ReiserFS, в XFS используется логическое журналирование. Иначе, журнал ведется не файловыми блоками (как в ext3), а в эффективном дисковом формате с регистрацией только изменяемых метаданных. Для XFS логическое журналирование особенно "показано". На high-end hardware (что обычно для XFS) журнал наиболее спорный ресурс. Использование space-efficient logical journal минимизирует непроизводительное расходование ресурсов. Кроме того, XFS допускает хранение журнала на другом блочном устройстве (partition, скажем так, на "дешевом" диске). Эта feature не только экономит дорогие ресурсы, но в еще большей степени "работает" на увеличение скорости XFS.

Как и ReiserFS, XFS журналирует только метаданные и не делает это для самих данных. Из этого следует, что в XFS (как и в ReiserFS) возможна потеря данных, измененных перед аварийной перезагрузкой. Но, у журнала XFS имеется два свойства, снижающих вероятность потери данных по сравнению с ReiserFS.

В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла. Помимо очевидной потери данных, гипотетически это может иметь более серьезные последствия. В XFS имеется гарантия, что любые "недозаписанные" блоки заполнены нулями. Так как блоки с нулевыми байтами в системных файлах игнорируются, устраняется лазейка в безопасности.

Теперь непосредственно о проблеме потери данных. Такая проблема в XFS минимизируется вследствие того, что операция сброса на диск ожидающих обработки модификаций метаданных в XFS происходит чаще, чем это происходит в ReiserFS (особенно при высокой интенсивности операций IO). Как следствие, после аварии в XFS потерь будет меньше, чем при тех же условиях в ReiserFS. Заметьте, сама по себе более частая запись метаданных не "купирует" проблему, а лишь провоцирует более частый сброс на диск и самих данных.

Delayed allocation.

Этот краткий технический обзор XFS завершается описанием delayed allocation, еще одной feature, уникальной среди файловых систем. Определимся с терминами. Понятие allocation относится к процессу обнаружения областей free space для записи новых данных.

XFS выполняет allocation, разделяя, казалось бы, неделимый процесс на два шага. Сначала, когда XFS получает данные для записи, выполняется запись ждущей транзакции [pending transaction] в RAM и просто резервируется соответствующее количество пространства на основной файловой системе. При этом, резервируя "количество пространства" для новых данных, XFS не решает, какие именно блоки файловой системы эту информацию будут хранить. XFS откладывает принятие окончательного решения до самого последнего момента, когда данные фактически сбрасываются на диск.

Через delaying allocation файловая система XFS получает дополнительные возможности оптимизации скорости. Когда наступает момент фактического сброса данных на диск, XFS может быстро и интеллектуально ассигновать free space под оптимизацию производительности. В частности, если новые данные добавляются в конец одного файла, XFS может ассигновать смежные region на диске. Если бы XFS не задерживала "до последнего" принятие решения по ассигнованию физических блоков, возможно, данные были бы "размазаны" по множеству несмежных участков. Благодаря задержке "физического" ассигнования, XFS способна делать запись одной операцией, повышая производительность и снижая фрагментацию.

Delayed allocation имеет еще один положительный эффект. Если создается много временных файлов с "маленьким временем жизни", XFS вообще не будет сбрасывать их на диск (ну и что, не только XFS). А теперь внимание, поскольку физические блоки не allocated, отсутствует необходимость в их последующей deallocate. Иначе, не пишутся на диск не только данные, но и не изменяются метаданные файловой системы (а вот это уже кое-то, по сравнению с другими FS).

Заключение.

Я надеюсь, вам понравился рассказ о производительности и технических характеристиках XFS, одной из самых мощных файловых систем Linux нового поколения. Тогда приглашаю к чтению следующей статьи, где пойдет разговор о вещах практических. В планируемой статье будут также рассмотрены некоторые XFS' advanced features, например ACLs и extended attributes. До встречи!

Resources

About the author

author Residing in Albuquerque, New Mexico, Daniel Robbins is the President/CEO of Gentoo Technologies, Inc., the creator of Gentoo Linux, an advanced Linux for the PC, and the Portage system, a next-generation ports system for Linux. He has also served as a contributing author for the Macmillan books Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved with computers in some fashion since the second grade, when he was first exposed to the Logo programming language as well as a potentially dangerous dose of Pac Man. This probably explains why he has since served as a Lead Graphic Artist at SONY Electronic Publishing/Psygnosis. Daniel enjoys spending time with his wife, Mary, and their daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.

Перевод: Vladimir Kholmanov