CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
15.12.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: BSD :: DragonFly BSD

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

Отдельной крупнейшей работой, которую нам предстоит выполнить, является наладка VFS. Во-первых, в основе существующего в настоящее время API виртуальной файловой системы лежит модель массовой повторной входимости, а мы хотим попытаться подогнать его к API, основанному на нитях и сообщениях. Во-вторых, существующий в настоящее время API VFS - это один из наиболее сложных интерфейсов системы... Достаточно посмотреть на VOP_LOOKUP и его коллег, распознающие маршруты к файлам. Наладка VFS включает две основные части работы.

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

Во-вторых, VOP(Virtual Object Protocol)-интерфейс вообще будет переделан в интерфейс на основе сообщений. Все прямые адреса в пользовательском пространстве будут преобразовываться ядром в диапазоны объектов виртуальной памяти. Интерфейс VOP больше НЕ будет заниматься адресами пользовательского пространства. Основываясь на новом интерфейсе, VOP сможет и далее работать синхронно, чего мы и добиваемся на начальном этапе. Но наше намерение состоит в том, чтобы разбить большую часть VOP-интерфейса на нити (т.е. заменить модель массовой повторной входимости сериализованной многонитиевой моделью сообщений). Для файловой системы с несколькими нитями (по одной на процессор) мы теоретически можем достичь того же уровня эффективности, что и с применение модели массового повторной входимости. Однако точки блокировки типа bread(), встречающиеся повсюду в коде файловой системы, должны быть либо асинхронизированы, что трудно, либо нам придется породить намного больше нитей, чтобы справиться с параллелизмом. Сначала мы можем нацелиться на достижение (большой) производительности и сериализовать операции VOP в одну нить, а затем можно оптимизировать и небезразличные для нас файловые системы вроде UFS. Следует заметить, что модель массовой повторной входимости не будет работать намного лучше, чем, например, 16-нитиевая модель, потому что в обоих случаях узким местом является ввод/вывод. Если одному потоку разрешить обрабатывать неблокирующие (кэшированные) запросы, мы сможем достичь 95% эффективности модели массового повторного вхождения.

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





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds