DragonFly - операции с устройствами на виртуальной файловой системе

Оригинал: DragonFly - VFS/filesystem Device Operations
Перевод: Валерий Винник, 05.03.03

Новая модель VFS (виртуальной файловой системы)

Как видится, единственным по настоящему крупным участком работ будет приведение в порядок подсистемы VFS. Во-первых, в существующем в настоящее время API виртуальной файловой системы везде используется модель массивного повторного входа (massive reentrancy model), а мы хотим попытаться уложить её в разбитый по потокам API работы с сообщениями (threaded messaging API). Во-вторых, существующий в настоящее время API виртуальной файловой системы - один из самых сложных и громоздких интерфейсов системы... VOP_LOOKUP сотоварищи, преобразующий пути к файлам. Упорядочение VFS будет проводиться в два крупных этапа.

Во-первых, будут полностью переделаны интерфейс VOP_LOOKUP и кэш VFS. Все пути к файлам будут грузиться ядром в кэш VFS в непреобразованном состоянии ДО запуска какой бы то ни было VFS-операции. Ядро будет прочёсывать кэш VFS и, найдя лист, начнёт создавать новые записи для представления непреобразованных элементов путей. "Хвост" этой "змеи" будет передаваться на VFS_LOOKUP() для преобразования. VFS_LOOKUP() будет способен возвращать новый VFS-указатель, если потребуется его дальнейшее преобразование. Например, он нашёл точку монтирования. Тогда ядро прекращает передавать случайные последовательности данных, инициированные пользователями (естественно, используя пространство пользовательского адреса!) подсистеме VFS.

Во-вторых, VOP-интерфейс вообще будет переделан в интерфейс работы с сообщениями (messaging interface). Все прямые адреса в пользовательском пространстве будут преобразовываться ядром в диапазоны объектов виртуальной памяти (VM object ranges). Интерфейс VOP больше НЕ будет заниматься адресами пользовательского пространства. Как интерфейс работы с сообщениями, VOP'ы смогут и далее работать синхронно, чего мы и добиваемся на начальном этапе. Но в планах у нас - разбить большую часть VOP-интерфейса на потоки (т.е. заменить модель массивного повторного входа моделью последовательно-поточных сообщений). Для более эффективной работы файловой системы, управляющей несколькими потоками (один на процессор), мы теоретически можем достичь того же уровня эффективности, что и на массивно-реэнтерабельной модели (massive reentrant model). Однако, блокировочные точки наподобие bread() по всему коду файловой системы, должны быть либо асинхронизированы, что трудно, либо нам придётся наплодить кучу-малу новых потоков, чтобы контролировать параллелизм. Сначала мы можем нацелиться на достижение (высочайшей) производительности и преобразование операций VOP в единый поток, а затем можно оптимизировать и небезразличные для нас файловые системы вроде UFS. Нужно отметить, что модель массивного повторного входа не будет отрабатывать это всё намного лучше, чем, например, 16-потоковая модель, потому что в обоих случаях "бутылочным горлышком" будет I/O. Пока один поток может свободно обрабатывать неблокирующие (кэшированные) запросы, мы всегда можем достичь 95% эффективности массивного повторного входа.

Интерфейс работы с сообщениями предпочтительнее по многим причинам, среди которых не последнее место занимает тот факт, что он обеспечивает правильную работу стековых операций. Например, при помощи нового API слой максимальной производительности (capability layer) может быть нахлёстнут на файловую систему, которая иначе не использует таковой собственный, и конечный пользователь не увидит разницы. Как правило, файловые системы - самодостаточные структуры. API, основанный на сообщениях, позволит таким структурам входить в пользовательское пространство для отладки или даже находить применение там, где фатальные сбои недопустимы. Зачем использовать msdosfs или cd9660 в ядре и рисковать получить крах, если оно будет так же хорошо работать в юзерланде? Отладка и развитие файловой системы - также хорошие поводы для того, чтобы вместо массивно-реэнтерабельного API иметь API работы с сообщениями.

Обновлено: 12.03.2015