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

- Поддержка много поточности

Другая проблема на пути достижения высокой производительности состоит в том, что многие UNIX-ФС позволяют одному потоку (thread) блокировать inode при работе с файлом. Эта блокировка гарантирует, что только один процесс может выполнять ввод-вывод на данном файле в конкретный момент времени.

XFS использует  более гибкую схему блокирования (locking), позволяющую нескольким процессам работать с файлом одновременно. При использовании нормального, буферизованного ввода-вывода множество приложений может одновременно читать данные из файла, но только одно из них имеет право записывать. Ограничение на количество пишущих процессов проистекает из особенностей реализации, а не из недостатков архитектуры, и, в конечном счете, будет устранено. Когда используется прямой ввод-вывод, множество процессов могут одновременно и без ограничений работать с одним файлом. В настоящее время, при наличии direct I/O и множества writers, мы перекладываем работу по упорядочению запросов на запись в один и тот же участок файла на приложение (т.е. сохранены будут только данные, записанные последними (пер.)). В этом состоит отличие от традиционных UNIX-ФС, где запись в файл является неделимой (atomic) операцией, отделенной от всех остальных, и это является одной из главных причин, по которым мы до сих пор не поддерживаем многопоточную запись при использовании буферизованного ввода-вывода.

Реализация  параллельного доступа к файлу  может дать существенный прирост в производительности ввода-вывода. В случае, если процесс обмена данными между приложением и файлом тормозит процессор, осуществляющий копирование данных в файловый кэш, механизм распараллеливания доступа к файлу позволяет привлечь к копированию несколько процессоров. При использовании direct I/O на большом дисковом массиве распараллеливание доступа позволяет одновременно направлять несколько запросов нескольким дискам. Эта возможность особенно важна для систем, подбных IRIX, осуществляющих асинхронный ввод-вывод с использование потоков. Без параллельного доступак файлам асинхронные запросы выполнялись бы фактически последовательно (из-за блокировки inode), не давая никакого выигрыша в производительности.

4. Доступ к метаданным

Еще один аспект производительности файловой системы  – это процедуры манипулирования  метаданными. Для многих приложений скорость создания, удаления и изменения  файлов и каталогов не менее важна, чем скорость ввода-вывода. XFS решает проблему манипуляций с метаданными с трех направлений. Первое – использование журнала транзакций для обеспечения быстрого восстановления метаданных. Второе – применение перспективных (advanced) структур данных (B+trees (пер.)) для упрощения процедур сканирования и изменения метаданных с линейного до логарифмического уровня сложности (имеется в виду упрощение алгоритма до сложности O(logN) (пер.)). Третье – распараллеливание процедур поиска и обновления различных частей файловой системы. Мы уже подробно обсудили применяемые в XFS структуры данных, а в этом разделе сосредоточимся на описании журнала транзакций и параллелизма.

- Журналирование транзакций

Проблема, актуальная для традиционных UNIX-ФС – использование ими упорядоченных  синхронных алгоритмов изменения дисковых (on-disk) структур данных для того, что бы сделать эти изменения восстановимыми с помощью программ типа fsck. Синхронная запись изменений метаданных существенно снижает производительность файлового ввода вывода, заставляя быстрый CPU простаивать в ожидании завершения записи на диск.

XFS использует  упреждающую запись в журнал  транзакций, что бы собрать все  изменения метаданных и записи о них в журнале в один дисковый запрос и записать их асинхронно, не заставляя процессор ждать завершения дисковой операции. Были предложены и другие схемы для решения этой проблемы, например журнально-структурированные файловые системы (log structured file systems), shadow paging, soft updates (до сих пор применяется с FFS во всех BSD-системах (пер.)) и пр., однако мы считаем, что журналирование является оптимальным сочетанием гибкости, производительности и надежности, т.к. оно обеспечивает нас быстрым и эффективным механизмом обновления и восстановления метаданных без необходимости отказа от способности выдерживать рабочие нагрузки синхронной записи (необходимой, к примеру, для NFS-сервера) и не лишая нас возможности поддерживать большие непрерывные файлы. Глубокий же анализ указанных схем выходит за рамки этого документа.

- Асинхронное журналирование транзакций

Традиционные  схемы упреждающего журналирования пишут в лог синхронно, до объявления о завершении транзакции и разблокирования ресурсов. Конечно, эта схема гарантирует непрерывность обновления метаданных, однако она ограничивает скорость внесения изменений в файловую систему скоростью, с которой та способна записывать транзакции в журнал. Не смотря на то, что что XFS обеспечивает возможность последовательного внесения изменений в файловую систему, например, когда ее данные экспортируются через NFS, нормальный режим ее работы предусматривает асинхронную запись в журнал. Естественно мы гарантируем, что данные не могут быть сброшены на диск, пока запись о запрашиваемых изменениях не будет внесена в дисковый (on-disk) журнал. Однако всесто того, что бы удерживать измененные ресурсы заблокированными до завершения записи транзакции, мы разблокируем ресурсы и “запираем” их в памяти до тех пор, пока все необходимые записи не будут внесены в дисковый журнал (в “запертые” таким образом структуры можно вносить изменения, но на диске они отразиться только по завершении транзакции (пер.)). Ресурсы разблокируются, как только транзакция будет записана в журнальный буфер в памяти – это позволяет сохранить порядок внесения изменений без ущерба для производительности.

Асинхронное журналирование имеет 2 выгодные черты . Первая – множество изменений может быть сгруппировано и записано на диск одной операцией. Это увеличивает эффективность записей в журнал на системах с дисковыми массивами. Вторая – скорость обновлений метаданных обычно не зависит от производительности конкретного оборудования. Конечно, эта независимость ограничена количеством памяти, выделяемой под буферизацию журнала, однако она все равно намного быстрее синхронных обновлений в старых ФС.

- Использование отдельного устройства для журнала

При высокой  интенсивности внесения изменений  в метаданные производительность этих изменений все еще будет ограничена скоростью сброса журнального буфера на диск. Это происходит, если транзакции вносятся в буфер быстрее, чем он пишется на диск. Для подобных случаев XSF предусматривает возможность вынесения журнала на устройство, отделенное от основной файловой системы. Это может быть как отдельный диск, так и карта энерго-независимой памяти. Метод размещения журнала в энерго-независимой памяти уже доказал свою исключительную эффективность на high-end OLTP системах. Он может оказаться особенно полезен в случае экспорта XFS через NFS-сервер (когда все изменения метаданных должны вноситься синхронно) – как для увеличения производительности, так и для уменьшения времени ожидания завершения транзакции.

- Применение параллелизма

XFS построена для применения на больших производительных многопроцессорных системах с разделяемой памятью. Поддержка параллелизма на таких машинах упирается только в один централизованный ресурс – журнал транзакций. Все другие ресурсы файловой системы сделаны независимыми либо на уровне allocating groups, либо на уровне отдельных inode. Это позволяет inodes и блокам быть размещенными и освобожденными параллельно в любом месте файловой системы.

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

Достоинства

• 64-битная файловая система.
• Журналирование только метаданных (если не задать иное параметрами).
• Выделение места экстентами (Extent — указатель на начало и число последовательных блоков). В экстентах выделяется место для хранения файлов, а также экстентами хранятся свободные блоки.
• B-tree индексы активно используются для хранения различных данный файловой системы: для списка блоков с inode-ами, списка эскстентов с содержимым файла, каталогов файлов, списков экстентов свободных блоков (свободные блоки проиндексированы и по размеру блока, и по расположению). Однако использование b-tree индексов не догма — небольшой файл или каталог может быть размещен прямо внутри inode.
• Отложенное выделение места (Delayed allocation). При записи файла для него выделяется место в памяти, а на диске выделяется место только при записи файла на диск. Таким образом под файл оптимально выделяется место на диске, что уменьшает фрагментацию.
• Изменение размера «на лету» (только увеличение).
• Размещение в нескольких линейных областях (по умолчанию — 4 шт.) т. н. «allocation groups» (увеличивает производительность путём выравнивания активности запросов как к разным дискам на RAID-массивах типа «stripe», так и при асинхронном обращении к файловой системе на обычном диске.)
• Дефрагментация «на лету».
• API ввода/вывода реального времени (для приложений жёсткого или мягкого реального времени, например, для работы с потоковым видео).
• Интерфейс (DMAPI) для поддержки иерархического управления носителями (HSM).
• Инструменты резервного копирования и восстановления (xfsdump и xfsrestore).
• «Индексные блоки» inode выделяются динамически (по мере надобности) и неиспользуемые inode могут освобождаться (высвобождая место для хранения данных).
• Малые «накладные расходы» — размер служебных структур данных. На вновь созданной файловой системе XFS на служебные нужды тратится порядка 0,54 %. Это достигается малым количеством заголовков для групп (allocation groups), а также за счет динамического выделения inode.

Недостатки

• Невозможно уменьшить размер существующей файловой системы.
• Старые версии XFS страдали от опасности беспорядочной записи, которые могли привести к возникновению таких проблем как — файлы приложений во время краха/ошибки/аварии ФС или приложения набирали хвост из мусора к следующему монтированию ФС. Эти ошибки исправлены в последних версиях.
• Восстановление удалённых файлов в XFS — очень сложный процесс, поэтому на данный момент существует всего лишь несколько программных продуктов для восстановления удаленных файлов с этой файловой системы, например «Raise Data Recovery for XFS» для ОС Windows.
• Возможность потери данных во время записи при сбое питания, так как большое количество буферов данных хранится в памяти при том что метаданные записываются в журнал (на диск) оперативно. Это характерно и для других файловых систем с журналированием метаданных.
• Относительно высокая нагрузка на центральный процессор.
• Вплоть до последних версий на 32-разрядных системах индексные блоки могли размещаться только в начальных 2 терабайтах на диске.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Приложение