LiveStreet

Продолжение перевода статьи о BeFS (часть первая).

I-nodes

Как и в большинстве файловых системах Unix подобных ОС, BFS использует структуру данных для отслеживания дисковых ассигнований. Структура bfs_inode показана ниже. I-node обрабатывает основные метаданные файла включая время создания файла, владельца, размер файла, монопольного использования группы, где хранятся данные файла на диске, и т.д. BFS не обновляет размер файла, пока файл не закрыт. При тестировании было установлено, что это дает существенный выигрыш в производительности.

typedef struct bfs_inode { int32 magic1;
    inode_addr inode_num;
    int32 uid;
    int32 gid;
    int32 mode;
    int32 flags;
    bigtime_t create_time;
    bigtime_t last_modified_time;
    inode_addr parent;
    inode_addr attributes;
    uint32 type;
    int32 inode_size;
    binode_etc *etc;
    data_stream data;
    int32 pad[4];
    int32 small_data[1];
} bfs_inode;

Вновь используется магическое число в bfs_inode для проверки корректности и восстановления при ошибках. Магические числа одинаковы для BeOS и Haiku для совместимости, но различны с реализацией их в SkyOS. UID, GID и mode используется для соответствия стандарту POSIX.

Data_streams

Структура i-node содержит основные атрибуты файла, но не актуальные данные самого файла. Это сделано через структуру компонента данных. Компонент данных определяется в data_stream:

typedef struct data_stream {
	block_run direct[NUM_DIRECT_BLOCKS]; 
	off_t max_direct_range; block_run indirect; 
	off_t max_indirect_range; 
	block_run double_indirect; 
	off_t max_double_indirect_range; 
	off_t size; 
} data_stream;

Структура data_stream отображает данные от физического диска до API потока файла. Доступ с использованием data_streams оптимизирован для пропускной способности, минует системый кэш, и использует DMA (прямой доступ к памяти) в и из использованной памяти. В бенчмарках, BFS в состоянии достигнуть высокой пропускной способности, которая приближается к пиковым дисковым скоростям.

Функции базы данных, использование расширенных атрибутов

Как уже упоминалось ранее, обработка атрибутов является важной функцией файловой системы. Mac HFS первая файловая система, которая стала широко использовать атрибуты файлов для поддержки GUI. Учтите, что оконные ОС должны сохранять и управлять многими атрибутам графического интерфейса, такими как размер фрейма, расположение, цвет, текст и т.д., и нуждается в оптимизации для быстрого отклика.

BFS поддерживает расширенные атрибуты, в виде ключ/значение, ассоциаций файлов. Ключи имеют фиксированный тип и могут быть добавлены в любое время. Возможные типы: string, time, double, float, int, boolean, raw, и image. Если ключ индексирован, основной поиск сильно оптимизирован. Следующие команды нужны для управления расширенными атрибутами файла.

* addattr key value filename: добавляет пару ключ/значение в указанный файл.
* catattr key filename: отображает значение указанного поля.
* listattr filename: перечисляет связанные атрибуты файла, их типы, и их размеры, в байтах.
* rmattr key filename: удаляет атрибут из указанного файла.

Новые поля создаются на глобальном уровне с mkindex. Например,

* mkindex --type=indextype index: создает новый индекс типа long, в текущем томе.
* reindex sourcefile filename: добавляет ключ файла к индексу, если индекс создан после атрибутов файлов.
* rmindex index: удаляет атрибут из текущего тома, делая его недоступным для использования.
* lsindex: список всех атрибутов.

В Haiku доступ к атрибутам файлов поддерживается в графическом режиме с помощью Tracker, а также с использованием «горячих» клавиш. Любой графический объект в Haiku имеет набор атрибутов _trk/pinfo_le задающих позицию иконки файла. BEOS:TYPE содержит прикладную ассоциацию для файла. Больше информации об использовании атрибутов файла можно найти здесь.

Дополнительная информация и примеры использования атрибутов файлов расположена здесь и здесь.

Поиск с помощью Query

Query — инструмент командой строки, используемых для поиска соответствующих атрибутов. Это удобнее чем утилита «find» в Unix.

Вот некоторые примеры синтаксиса запроса:

query "((name="**")&&(BEOS:TYPE=="audio/x-wav"))" - finds all files with MIME type of "wav". Useful if you have wav files that are missing the .wav extension.

query "(last_modified >= %yesterday%)" - finds files older than yesterday

Вывод от запроса может использоваться со средствами создания сценариев из командной строки следующим образом:

touch 'query ((last_modified< %yesterday%)&&(BEOS:TYPE=="audio/mpeg"))'

Это обновит last_modifed у всех mp3 файлов, с last_modifed старше вчерашнего.

Дополнительная информация относительно создания сценария с запросом предоставлена здесь

Использование атрибутов приложениями.

Haiku Mail Kit пример приложения, которое активно использует атрибуты. Haiku mail не имеет собственной базы данных для хранения и управления электронными сообщениями. Вместо этого оно сохраняет каждое электронное сообщение непосредственно в файловую систему BFS и использует больше 15 специфичных для электронной почты атрибутов для поиска и сортировки. Можете ли вы представить себе суммарный объем сообщений электронной почты в 8 экзабайт? Haiku делает это теоретически возможным.

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

Оптимизация поисковых атрибутов

Так как каждый файл на BFS потенциально может иметь множество дополнительных атрибутов, и потенциально может быть сотни тысяч файлов, существует острая необходимость в оптимизации доступа к атрибутам. В BFS, каждый индекс осуществлен в виде структуры данных B+tree. B+tree сбалансирован, древовидная сортировка структуры данных обеспечивает очень быстрый поиск и хорошую масштабируемость. Не удивительно, что это также используется для управления структурами каталогов и широко применяется в других файловых системах, к примеру ntfs. BFS индексы оптимизированы для поиска в таком виде:

query "(name=="temp")"  or query "(name >"111")"

Индексы BFS не оптимизированы для регулярных выражений вида:

query "(name==[aA][bB][cC])"

Этот поиск деградирует от двоичного поиска до последовательного и потенциально может работать дольше в больших файловых системах.

Запросы, которые используют регулярные выражения, но начинаются с фиксированного выражения, оптимизированы в Haiku, например запрос "(name==temp[1234])" будет работать быстрее чем запрос "(name==[tT]emp[1234])".

Часть третья