[b]Поддержка многопоточности/b]

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

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

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

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

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

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

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

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

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

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



В этом разделе приводятся описания различных тестов производительноти и несколько диаграмм и таблиц результатов. Материал довольно прост и в переводе не нуждается. Интересующиеся могут посмотреть его в оригинальном документе:

http://www.oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html


Аналогичные по тематике переводы и статьи можно найти на fresco.front.ru

индекс статьи
страница 1 : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка
страница 4 : страница без заголовка
страница 5 : страница без заголовка
страница 6 : страница без заголовка
страница 7 - текущая : страница без заголовка