3.2.5 Производительность EA и ACL

Так как ACL предоставляют более продуманный и проработанный механизм управления доступом, они используются всегда, когда необходимо принятие решения о правах доступа к объектам файловой системы. Интересно сравнить время, которое необходимо потратить на принятие такого решения с ACL и без него.

Измерения были проведены на ПК с операционной системой SuSE Linux 8.2 с ядром SuSE 2.4.20. В ПК установлены процессор AMD Athlon с тактовой частотой 1.1 ГГц и оперативная память, объемом 512 Мб. Тестирование проводилось на жестком диске IBM Ultra ATA 100 объемом 30 Гб со скоростью вращения цилиндров 7200 об/м, среднее время посиска 9.8 мс, размер дискового кэша 2 Мб. Файловые системы Ext2, Ext3, ReiserFS и JFS создавались на разделе размером 8 Гб с параметрами по-умолчанию. В случае XFS для сравнения EAs, которые хранятся в inode, и EAs, которые хранятся вне inode, были созданы файловые системы XFS с размерами inode 512 байта и 256 байт. Эти файловые системы названы XFS-512 и XFS-256 соответственно.

Таблица 5 показывает результаты тестирования времени, затраченного на начальную проверку прав доступа к файлу с ACL и без ACL после перезагрузки системы. Для того, чтобы исключить время, потраченное на загрузку файлового inode в кэш, вызывался системный вызов stat перед каждой проверкой прав доступа. Время, потраченное на этот вызов не показано. Первое использование ACL доступа файла может потребовать одного или более прямых доступов к диску, которые во много раз медленнее доступа к диску через кэш. Настоящее время этих доступов к диску довольно широко зависит от скорости вращения цилиндров и относительного расположения блоков, к которым предоставляется доступ. Функция, используемая для измерения времени имеет порядок аппроксимации в микросекунду. В случае ACL файл, к которому проверялись права доступа, имел ACL с пятью ACE.

Таблица 5: Производительность ACL в SuSE 8.2

XFS с размером inode 512 байт (или больше) и JFS хранят ACL прямо в inode. Поэтому в этом случае нет необходимости в дополнительных доступах к диску для получения ACL.

После первого использования ACL вся информация полностью кэшируется. В каждом тесте одна и та же операция повторялась много раз и усреднялось время, потраченное на проделывания этих операций.

Команда ls –l показывает в своем выводе имеет ли файл расширенный ACL. Внутренне она использует функцию acl_extended_file библиотеки libacl. Эта функция почти так же быстра, как и системный вызов stat, который команда ls –l также вызывает для каждого файла, так что итоговые временные расходы малы.

Таблицы 6 и 7 показывают включенные временные расходы на копирование файлов из одной файловой системы в другую. Все копируемые файлы имеют ACL, но не имеют дополнительных EAs. Тесты показывают время, потраченное на операции, начиная с команды cp и заканчивая командой sync, которая запускалась сразу же после команды cp. Команда sync гарантирует, что файлы будут немедленно записаны. В первом случае использовалась версия cp, которая не имеет поддержки EAs и ACL. Во втором случае использовалась версия cp, которая поддерживала и EAs и ACL. В обоих тестах файловая система-источник оставалась неизменной, в то время как файловая система-приемник менялась.

В примере для теста в таблице 6 размеры достаточно мал для всех файлов, чтобы уместить их в главную память. Время, потраченное на первое чтение файлов в память, не учитывалось. Эти тесты повторялись 5 раз. Результаты содержат среднее и стандартное распределение. В примере для теста, показанного в таблице 7, размеры файлов больше чем размер главной памяти и размер системного файлового журнала. Эти тесты проводились единожды.

Таблица 6: Копирование файлов из памяти в файловую систему (11351 файлов, 608 каталогов, итоговый размер файлов = 137 Мб)

Таблица 7: Копирование файлов между файловыми системами (96183 файлов, 6323 каталогов, итоговый размер файлов = 2.8 Гб)