Файловая система XFS

XFS журналирует все изменения метаданных, включая операции с суперблоком, AGs, inodes, каталогами и свободным пространством. XFS не журналирует пользовательские данные. Например, создание файла требуется сохранить в журнал блок каталога, содержащий новый элемент, вновь размещенный inode, блок inode allocation tree, описывающий этот inode, блок заголовка AG и суперблок, содержащие количество свбодных inodes. Элемент журнала по каждому из этих пунктов содержит заголовочную информацию, описывающую данный блок или inode, и копию самого блока или inode.

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

К сожалению, использование журнала транзакций не позволяет полностью отказаться от программ восстановлния ФС. Аппаратные и программные ошибки, затирающие случайные дисковые блоки, вообще неисправимы с помощью журналирования – они могут привести к недоступности содержимого даже журналируемой файловой системы. Мы не выпустили подобную программу с первым релизом XFS, наивно полагая, что она не понадобиться, однако пользователи убели нас, что мы ошиблись – у них оставался единственный способ вернуть к жизни разрушенную XFS: пересоздать ее с помощью mkfs и восстановить данные с резервных копий. Мы планируем предоставить пользователям программу восстановления XFS в близжайшем будущем.

2. Масштабируемость производительности

На ряду с поддержкой больших дисковых пространств, XFS разработана для обеспечения высокопроизводительного доступа к файлам и файловой системе. XFS задумана для работы на больших разреженных дисковых массивах, в условиях совокупной пропускной способности аппаратных средств от десятков до сотен Mb/s.

Ключами к  достижению столь высокой производительности являются оптимально подобранный размер и эффективное распараллеливание I/O-запросов. Современные жесткие  диски имеют более высокую  пропускную способность при выполнении ввода-вывода большими блоками. В дисковых массивах потребность в обмене большими кусками данных еще больше, потому что длинные запросы состоят  из множества маленьких – к  каждому диску. Т.к. размер отдельного I/O-запроса ограничен, важно выполнять множество запросов параллельно, что бы распределять нагрузку между всеми устройствами. Совокупная пропускная способность дискового массива будет достигнута только в том случае, если все устройства в массиве равномерно загружены.

В этом разделе  мы опишем, каким образом XFS позволяет  приложениям полностью использовать пропускную способность, предоставляемую  аппаратурой. Мы начнем с описания механизма  размещения больших непрерывных(continguous) файлов, затем расскажем о выполнении ввода-вывода на такие файлы, и закончим описанием эффективных алгоритмов работы с метаданными.

- Непрерывное размещение файлов

Первый шаг  к обеспечению возможности выполнять  ввод-вывод посредством длинных I/O-запросов – размещение файлов как  можно более непрерывно, т.к. размер запроса к устройству ограничен количеством непрерывно расположенных блоков в файле, над которым выполняется операция чтения или записи.

- Отложенное размещение (Delaying Allocation)

Одна из ключевых особенностей XFS в деле непрерывного размещения файлов – это отложенное выделение зон (delayed file extent allocation). Алгоритм delayed allocation использует “ленивые” техники назначеня физических блоков файлу. Вместо того, что бы выделять блоки файлу в момент его записи в кэш, XFS просто резервирует блоки в файловой системе, размещая данные в специальных буферах, называемых виртуальными зонами (virtual extents). Только когда буферизованные данные сбрасываются (flush) на диск, виртуальным зонам назначаются конкретные блоки. Решение о размещение файла надиске откладывается до момента, когда ФС будет располагать более точной информацией о конечном размере файла. Когда весь файл содержится в памяти, то он обычно может быть размещен в одном куске непрерывного дискового пространства. Файлам, не умещающимся в памяти, алгоритм delayed allocation позволяет быть размещенными гораздо более непрерывно, чем это было бы возможно без его применения.

Механизм  отложенного размещения хорошо соответствует  концепции современной файловой системы, т.к. его эффективность возрастает с увеличением объема системной RAM - чем больше данных будет буферизовано в памяти, тем более оптимальные  решения по их размещению будет принимать XFS. Кроме того, файлы с малым  временем жизни могут вовсе не получить физического воплощения на диске – XFS просто не успеет принять  решение о размещении до их удаления. Такие короткоживущие файлы –  обычное дело в UNIX-системах, и механизм delayed allocation позволяет существенно уменьшить количество модификаций метаданных, вызванных созданием и удалением таких файлов, а также устранить их влияние на фрагментацию ФС.

Другой плюс отложенного размещения состоит  в том, что файлы, записанные беспорядочно, но не имеющие “дыр”, чаще всего  будут размещаться на диске рядом. Если все “грязные” данные могут  быть буферизованы в памяти, то пространство для этих данных скорее всего будет размещено непрерывно в тот момент, когда они сбрасываются (flushed) на диск. Это особенно важно для приложений, пишущих данные в отображенные (mapped) файлы, когда случайный доступ – правило, а не исключение.

- Поддержка больших зон (large extents)

Для эффективного управления большими непрерывными зонами дискового пространства XFS использует очень большие дескрипторы зон  в карте зон файла. Каждый дескриптор может описывать более двух миллионов  дисковых блоков, т.к. мы используем 21-битное число для хранения длины зоны. Описание множества блоков в одном  дескрипторе экономит процессорное время, устраняя операцию сканирования зонной карты файла с целью  поиска непрерывных кусков.

Дескрипторы зон в XFS – это 16-байтные структуры  данных. В действительности это их сжатый размер, т.к. в памяти дескриптор зоны нуждается в 20 байтах: 8 на смещение в файле, 8 на номер первого блока  и 4 на длину зоны. Наличие таких  больших дескрипторов зон освобождает  место в inode, которое раньше тратилось на большое количество меньших указателей на зоны (как в EFS – 8 байт). Мы считаем, что это разумный подход.

- Поддержка блоков различных размеров

В дополнение ко всем приемам обеспечения непрерывности  выделения дискового пространства, XFS поддерживает размер блока от 512 байт до 64 kb. Размер блока файловой системы – это минимальный размер для I/O-запросов и запросов на размещение. Он так же является элементарной единицей фрагментации файловой системы. При выборе размера блока следует учитывать, что вместе с ним возрастает и внутренняя фрагментация. Файловые системы с множеством мелких файлов, например серверы новостей, обычно используют маленький размер блока, что бы избежать траты места на внутреннюю фрагментацию. Для ФС, хранящих большие файлы, напротив выбирают большой размер блока, что бы уменьшить внешнюю фрагментацию зон файлов и всей ФС.

- Противодействие фрагментации ФС

Практика  показала, что длительное накопление фрагментации в FFS может существенно  снизить ее производительность –  на величину от 5 до 15 процентов. Эта  фрагментация – результат создания и удаления файлов в течение какого-то времени. Даже если все файлы изначально размещаются на диске непрерывно, после удаления нескольких из них  оставшиеся будут разделены кусками  свободного пространства. Это называется фрагментацией свободного места. Учитывая склонность XFS к выполнению длинных I/O-запросов для непрерывного размещения файлов, мы ожидали падения ее производительности.

Однако не смотря на то, что XFS не может полностью  справиться с этой проблемой, по нескольким причинам ее воздействие не столь  серьезно, как того следовало бы ожидать. Первая причина – комбинация отложенного размещения и allocation B+ trees. Используя 2 этих механизма, XFS делает запросы на выделение больших зон, и allocator имеет возможность быстро и эффективно подобрать наиболее соответствующий ситуации отрезок дискового пространства. Это помогает отсрочить проблему фрагментации и существенно уменьшить ее влияние на производительность после ее появления. Вторая причина заключается в том, что XFS-разделы, как правило, намного больше разделов, обслуживаемых EFS или FFS, и, как следствие, XFS располагает большим количеством свободного дискового пространства, поэтому файловая система подвергнется фрагментации лишь со временем. И последнее – файловые системы обычно используются для хранения либо нескольких больших файлов, либо множества мелких. В первом случае фрагментация вообще не будет проблемой, т.к. размещение и удаление больших файлов все равно оставляет в ФС протяженные области непрерывного свободного пространства. Во втором случае фрагментация также не станет серьезной проблемой, т.к. мелкие файлы не нуждаются в больших зонах непрерывного пространства. Однако в долгосрочной перспективе мы все же считаем, что фрагментация может существенно сказаться на производительности XFS, поэтому мы собираемся выпустить он-лайновую утилиту для дефрагментации XFS-разделов.

3. Файловый ввод-вывод

Поскольку мы сумели обеспечить непрерывное расположение файлов надиске, дальнейшие надежды на повышение производительности были возложены на I/O-manager, который должен читать и записывать файлы через длинные запросы к диску, использую всю его пропускную способность. XFS использует группировку запросов, упреждающее чтение, отложенную запись и распараллеливание в процесс эксплуатации оборудования. Для повышения производительности XFS предоставляет приложениям возможность перемещать данные напрямую между памятью и диском, использую DMA. Все эти приемы подробно описаны в данном разделе.

- Обработка запросов на чтение (read reguests)

Что бы добиться высокой производительности последовательного  чтения , XFS использует большие read-буферы и множественные буферы упреждающего чтения. Под большими read-буферами мы подразумеваем то, что для последовательного чтения мы используем большой элементарный (минимальный) размер буфера (обычно 64kb). Конечно для файлов, меньших чем элементарный размер буффера, мы уменьшаем его до длины файла. Однако даже если приложение запрашивает чтение лишь маленького кусочка большого файла, I/O-менеджер все равно читает 64 kb данных этого файла. Для объемных запросов на чтение XFS увеличивает буффер до длины запрашиваемого участка. Этот прием очень похож на группирующее чтение SunOS, однако он более агрессивно использует память с целью ускорения ввода-вывода.

XFS использует  также множественные буферы упреждающего  чтения для эффективного распараллеливания  запросов к дисковым массивам. Традиционные UNIX-системы одномоментно используют только один буфер упреждающего чтения (read-ahead buffer). Для последовательного чтения XFS имеет в запасе 2-3 запроса одинакового размера в первом I/O-буфере. Число запросов изменяется потому, что мы стараемся иметь 3 упреждающих запроса, но не забываем ждать, пока приложение немного догонит процесс упреждающего чтения, прежде, чем выполнять новые запросы. Запросы множественного упреждающего чтения нагружают диски в массиве, пока приложение занято обработкой прочитанных данных. Большее количество таких буферов позволяет нам одновременно нагружать больше дисков в массиве. XFS не выполняет упреждающее чтение вслепую, а всегда “ждет” приложение, не загружая диски бессмысленным чтением большого количества данных, которые могут оказаться не востребованными пользователем.

- Обработка запросов на запись (write requests)

Для достижения хорошей производительности записи XFS использует агрессивную группировку (clustering) запросов на запись. “Грязные” данные файла буферизуются в памяти в отрезках по 64 kb, и когда такой отрезок выбран для сброса на диск, он группируется (it is clustered) с другими непрерывными отрезками для формирования длинного write-запроса. Эти пакеты пишутся на диск асинхронно – участки файлового кэша посылаются на разные диски массива одновременно. Это заставляет все диски массива обрабатывать постоянный поток write-запросов.

Отложенная  запись (write behind), используемая XFS, тесно взаимосвязана с отложенным размещением, описанным выше. Чем дольше мы откладываем сброс данных файла на диск, тем более оптимальное размещение получат эти данны. Здесь важно сохранить балланс между загрязнением памяти и перегрузкой аппаратуры. Это задача главным образом файлового кэша, однако она не будет подробно описана в этом документе.

- Использование прямого ввода-вывода(direct I/O)

На системах с большими дисковыми массивами  не редки ситуации, в которых аппаратура способна обрабатывать данные быстрее, чем CPU сбрасывает их из кэша – то есть процессор становится узким местом в канале передачи данных между приложением  и файлом. Для подобных случаев XFS поддерживает то, что мы называем прямым вводом-выводом. Этот механизм позволяет  приложению читать и записывать данные без посредства файлового кэша. Пользовательский буфер обменивается данными прямо  с диском, используя DMA. Это избавляет  нас от затрат на копирование данных в файловый кэш и позволяет  приложению самостоятельно контролировать размер запроса к диску. Direct I/O подобен традиционному механизму UNIX – сырому доступу к диску (raw disk access), отличие состоит лишь в способах адресации, осуществляемой в direct I/O посредством карты зон файла.

Прямой ввод-вывод  позволяет приложениям использовать всю пропускную способность устройства, вместе с тем избавляя его от сложностей raw access. Приложения обрабатывают файлы намного большие, чем объем системной памяти, и могут избежать использования дискового кэша, т.к. для них он бесполезен. Приложения типа баз данных, воспринимающие дисковый кэш крайне негативно, могут вовсе избежать его использования, довольствуясь выгодами от работы с нормальными файлами. Механизм direct I/O также необходим приложениям реалного времени.

Недостатками  direct I/O можно считать то, что он более ограничен, чем традиционный для UNIX файловый ввод-вывод, и требует большей сложности от использующих его приложений. Под ограниченностью понимается необходимость следить за выравниванием запросов по границам блоков и кратностью длины запросов размеру блока. Обычно это требует от приложения более сложных, чем при нормальной обработке данных через файловый кэш, техник буферизации запроса. Direct I/O также требует наличия большого количества приложений, формирующих эффективные запросы. Если всего один процесс пишет в файл, используя индивидуальные 4-килобайтные direct I/O запросы, он будет работать значительно медленнее, чем если бы использовался файловый кэш, группирующий данные в длинный запрос. Несмотря на то, что direct I/O никогда не заменит буферизованный ввод-вывод, он остается полезной альтернативой для сложных приложений, нуждающихся в быстром вводе-выводе.