EAs представляют собой пары имени и значения, которые постоянно ассоциированы с объектами файловой системы, схожим образом с переменными окружения процесса. Системные вызовы EA используются как интерфейс взаимодействия между системными и пользовательскими именами и значениями атрибутов между пользовательскими и системными адресными пространствами. Страница attr(5) руководства Linux содержит более подробное описание EAs в Linux. Работа Роберта Ватсона (Robert Watson) о поддержке инфраструктуры расширений безопасности в FreeBSD содержит сравнение различных реализаций EA на различных системах [25].

Другие операционные системы, такие как Sun Solaris, Apple MacOS и Microsoft Windows, позволяют нескольким потокам (или процессам) информации быть ассоциированы с одним единственным файлом. Эти потоки поддерживают обычную файловую семантику. После получения адреса потока, становится возможным получить доступ к содержимому потока, используя обычные файловые операции, такие как чтение и запись. Ошибочно в Solaris эти потоки тоже называются расширенными атрибутами. В Linux и некоторых других UNIX-подобных системах EAs не имеют ничего общего с этими потоками. Более ограниченный интерфейс EA предоставляет несколько преимуществ. Они более легки в реализации, операции EA иерархично атомарные и интерфейс не страдает от нагрузок от получения и освобождения адреса файла. Для наиболее часто используемых объектов, таких как ACL, эффективность особенно важна.

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

3.2.4.1 Ext2 и Ext3

Как описано в исходном коде ядра Linux, каждый inode содержит поле i_file_acl по историческим причинам. Если это поле ненулевое, оно содержит номер блока файловой системы, в котором хранится EAs, ассоциированные с этим inode. Все EAs определенного inode должны располагаться в одном EA блоке.

Для увеличения эффективности, несколько inode с идентичными наборами EAs могут указывать на один и тот же EA блок. Количество inode, ссылающихся на EA блок, отслеживается счетчиком ссылок в EA блоке. Разделение EA блоков прозрачно для пользователя: Ext3 хранит список блоков, к которым недавно был предоставлен доступ, и таблицу с двумя индексами (реализованную в виде хэш таблиц дважды связанных листов). Один индекс характеризует номер блока, другой – контрольную сумму содержимого блока. Блоки, содержащие одинаковые данные, с которым должен быть ассоциирован новый inode, используются заново до тех пор, пока счетчик ссылок блока не достигнет верхнего предела величиной 1024. Это уменьшает возможное повреждение, которое может быть вызвано сбоем одного блока. Когда inode ссылается на разделяемый EA блок и меняется значение EAs этого inode, используется механизм copy-on-write до тех пор, пока другой кэшированный EA блок не будет содержать такого же набора атрибутов, в этом случае будет использоваться этот блок.

Текущая реализация требует, чтобы все EAs конкретного inode располагались в одном дисковом блоке, который имеет размер 1, 2 или 4 Кб. Это ограничение также определяет максимальный размер отдельных атрибутов.

Если наборы EAs уникальны внутри inode, нет никаких разделений EA блоков и время на проверку потенциального разделения потрачено зря. Если каждый inode имеет уникальный набор EAs, каждый из этих наборов будет сохранен в отдельном дисковом блоке, что приведет к излишним потерям в дисковом пространстве. Крайний случай возникает тогда, когда приложения требуют хранения уникальных EAs для каждого inode. К счастью в реальной ситуации в наиболее общем случае механизм разделения EA достаточно эффективен.

Были предложены альтернативные способы с меньшим числом ограничений [5], но оказалось, что они довольно сложны в конкретной реализации. На данный момент для данной схемы не существует никаких альтернатив.

3.2.4.2 JFS

JFS хранит все EAs конкретного inode в последовательности блоков файловой системы [3]. Пары имен и значений расширенного атрибута хранятся последовательно в этой последовательности. Если EAs в совокупности достаточно малы, то они хранятся целиком внутри inode, к которому они принадлежат.

JFS не реализует механизма разделения EA. В ней нет ограничений на один блок как в Ext2 и Ext3. Размер отдельного атрибута ограничивается размером 64 Кб.

3.2.4.3 XFS

Из всех файловых систем, поддерживаемых в настоящее время в Linux, XFS использует наиболее тщательно проработанную схему хранения расширенных атрибутов [1]. Маленькие наборы EAs хранятся прямо в inode, наборы среднего размера хранятся в листовых блоках B+ деревьев, а большие наборы EAs хранятся в полных B+ деревьях. Это находит свое выражение в производительности хранения очень большого количества EAs.

XFS обладает настраиваемым размером inode, который задается в процессе создания файловой системы. Минимальный размер равен 256 байтам, именно такой размер и устанавливается по-умолчанию. Максимальный размер равен половине размера блока файловой системы. В минимальном случае, inode слишком малы для того, чтобы содержать ACL, и, следовательно, ACL будут храниться отдельно. Если увеличить размер inode, ACL сможет храниться в inode. Так как inode и ACL часто используются за короткий промежуток времени, то в результате такой организации будут быстрее производиться проверки на доступ, но зато это потребует большего дискового пространства.

XFS не использует механизма разделения EA. Размер отдельных атрибутов ограничен 64 Кб.

3.2.4.4 ReiserFS

ReiserFS поддерживает механизм поглощения хвостов файлов. Это означает, что несколько файлов могут разделять один и тот же дисковый блок для хранения своих данных. Это делает файловую систему очень эффективной для хранения большого числа маленьких файлов. Существует одно потенциальное препятствие: поглощение хвоста может требовать существенных временных ресурсов процессора.

Так как ReiserFS хороша для хранения маленьких файлов, EAs могут напрямую использовать этот механизм. Для каждого файла, который имеет EAs, в специальном каталоге создается каталог с именем, которое определяется уникальным идентификатором inode. Специальный каталог обычно спрятан от пространства имен файловой системы. Внутри специфического для данного inode каталога, каждый EA храниться в виде отдельного файла. Имя файла совпадает с именем атрибута. Содержимое файла – это значение атрибута.

В настоящее время ReiserFS не использует механизм разделения атрибутов, но такое расширение возможно будет реализовано в будущем. Разделение может также быть реализовано на по-атрибутной основе, это будет наиболее эффективным и гибким решением. Размер отдельного атрибута ограничивается 64 Кб.