Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
2006 г.

Руководство по продвинутым файловым системам
Презентация XFS

Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука

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

Зачем оно нужно?

В этой статье мы познакомимся с 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 с ОС IRIX от рабочих станций до суперкомпьютеров. Совсем недавно XFS стала доступна и для Linux. Появление поддержки XFS в Linux событие значимое. Теперь Linux обладает устойчивой, современной файловой системой с богатым набором функций, масштабируемой и удовлетворяющей самым высоким требованиям к хранилищам данных.

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

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

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

Результаты.

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

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

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

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

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

Проект XFS.

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

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

При создании файловой системы XFS основное блочное устройство разбивается на восемь или больше равных по размеру линейных областей. Их можно было бы назвать "chunks" или "linear ranges", но в терминологии XFS они именуются "allocation group" (что можно на русский язык можно перевести как группы выделения, или группы размещения, однако оригинальное название более понятно - А.Ф.). Уникальность allocation group в том, что каждая группа управляет своими собственными информационными узлами (inodes) и свободным пространством, что превращает группы в своего рода автономные файловые подсистемы, сосуществующие в рамках общей XFS.

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

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

B+ trees повсюду.

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

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

Журналирование

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

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

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

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

Delayed allocation.

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

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

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

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

Заключение

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

Новости мира IT:

Архив новостей

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

Группа ЕСН купила РБК (1)
Monday 19.06, 11:46
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...