МОДЕЛЬ И АРХИТЕКТУРА УПРАВЛЯЕМЫХ ФИЛЬТРОВ ФАЙЛОВОЙ СИСТЕМЫ Российский патент 2008 года по МПК G06F3/06 

ОБЛАСТЬ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение в целом относится к компьютерным системам, а более точно к файловым системам и фильтрам файловых систем.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

В современных операционных системах, таких как операционная система Windows® XP фирмы Microsoft Corporation's с лежащими в их основе файловыми системами, такими как Windows® NTFS (файловая система Windows® NT), FAT, CDFS, файловая система перенаправления согласно протоколу SMB, или файловые системы WebDav между менеджером ввода/вывода, принимающим запросы пользователя на ввод/вывод, и драйвером файловой системы могут находиться один или более драйверов фильтров файловой системы. В общем случае драйверы фильтров ('фильтры') являются драйверами ядра, расширяющими нижележащую файловую систему, выполняя различные связанные с файлами вычислительные задачи, которые требуются пользователю, включая такие задачи, как прохождение ввода/вывода (запросов и данных) файловой системы через антивирусное программное обеспечение, средства предоставления квот файловой системы, репликаторы файлов и средства шифрования/дешифрования. Например, антивирусные продукты обеспечивают фильтр, следящий за вводом/выводом в файлы определенных типов и из них (.exe,.doc и т.п.), отыскивая сигнатуры вирусов, тогда как продукты репликации выполняют зеркальное резервирование файлов на системном уровне. Другие типы драйверов фильтров файловой системы предназначены для восстановления системы (производящие резервное копирование системных файлов непосредственно перед их изменением таким образом, что пользователь имеет возможность вернуться к начальному состоянию), обеспечения квотирования диска, резервного копирования открытых файлов, восстановления стертых файлов, шифрования файлов и т.д. Таким образом, при помощи установки ( инсталлирования) драйверов фильтров файловой системы пользователи компьютера могут выбирать особенности (средства) файловой системы, которые они желают или которые им необходимы, способом, позволяющим проводить обновления, замену, добавление, удаление компонентов без необходимости изменения действующей операционной системы или кода драйвера файловой системы.

Существующая модель фильтра файловой системы в современных операционных системах семейства Windows® (например, Windows® NT, Windows® 2000, Windows® XP, Windows®.NET Server 2003) используется модель наследуемого ввода/вывода, представляющая собой пакетно-ориентированный подход. С этой целью фильтры файловой системы загружаются в стек как обычные драйверы и подключаются к объектам устройства томов нижележащей файловой системы. Запросы пользователя на ввод/вывод преобразуются администратором ввода/вывода в пакеты запросов ввода/вывода (-ПЗВВ, IRP), которые посылаются в стек драйверов и обрабатываются верхним драйвером, который может выполнить их, послать их ниже к файловой системе, вызвав другой драйвер, который вызывает следующий нижележащий драйвер и т.д. В общем случае каждый драйвер выполняет обработку ПЗВВ, для выполнения которой он предназначен, и затем в явном виде передает ПЗВВ ниже к следующему нижележащему драйверу (или файловой системе, если это нижний уровень), или выполняет (или не выполняет) ПЗВВ и передает его вверх по стеку вышележащему драйверу (или администратору ввода/вывода, если это верхний уровень).

Хотя упомянутые существующие модели драйверов фильтров предоставляют ряд преимуществ, включая их высокую гибкость, в них также существует ряд унаследованных проблем. Во-первых, запись в файловой системе является нетривиальной задачей, главным образом, вследствие сложности файловой системы. Фильтры представляют собой чрезвычайно сложные компоненты программного обеспечения, которые являются традиционно трудными для отладки и поддержки. Большинство трудностей вытекают из процесса обработки пакетов фильтрами, например необходимость понимания и манипулирования ПЗВВ. В результате страдает надежность и, по меньшей мере, одно исследование показало, что фильтры ответственны за значительный процент крахов системы.

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

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

Другие проблемы включают в себя переполнение стека, поскольку при установленных в одном или более фильтрах переполнение стека является обычным явлением вследствие рекурсивных повторных вхождений ввода/вывода, вызываемых фильтрами. Мертвые точки также представляют собой обычное явление в существующей модели и снова, главным образом, вследствие повторных вхождений ввода/вывода. Другие проблемы включают в себя невозможность динамической загрузки и выгрузки фильтров в стек, т.е. без перезагрузки системы.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Вкратце, настоящее изобретение предоставляет модель/архитектуру, в которой драйверы фильтров управляются администратором фильтров для приема обратных вызовов для запросов на ввод/вывод, в которых драйверы фильтров зарегистрировали свою заинтересованность. Модель исключает традиционное сложное прохождение ввода/вывода, обеспечивая модель управляемого обратного вызова, в которой ПЗВВ, быстрые пути ввода/вывода, обратные вызовы фильтра ФС (файловой системы) и т.п. преобразуются администратором фильтров в обратные вызовы, предоставляющие фильтрам данные обратного вызова в явном, хорошо определенном формате. Фильтры манипулируют данными обратного вызова как им необходимо и возвращают состояние в ответ на обратный вызов, как это описано ниже. Как один из результатов, фильтры более не имеют дела с IRP (пакетами запросов на ввод/вывод (ПЗВВ).

В общем случае, (программа -) администратор фильтров транслирует (преобразует) ввод/вывод, либо ПЗВВ, либо быстрый ввод/вывод, либо обратный вызов фильтра ФС (файловой системы) и т.п. в унифицированную структуру, называемую ''данные обратного вызова''. С этой целью администратор фильтров может быть помещен в стек существующих драйверов фильтров, как если бы он был традиционным драйвером фильтра, таким образом, что он может принимать и обрабатывать ПЗВВ. Затем администратор фильтров может просматривать список соответствующим образом зарегистрированных драйверов фильтров для вызова зарегистрированных вызовов для осуществления ввода/вывода.

Драйверы фильтров могут содержать объекты (или аналогичные им компоненты), которые при установке регистрируются при помощи механизма регистрации в администраторе фильтров. Драйверы фильтров регистрируются только для запросов к файловой системе, в которых они могут быть заинтересованы при обработке, при помощи извещения администратора фильтров о типах запросов на ввод/вывод, в которых они заинтересованы (например, создание, чтение, запись, закрытие и т.д.). В результате данная модель является более эффективной, чем модель фильтров, размещенных в стеке, поскольку драйверы фильтров не видят запросы на ввод/вывод, в которых они не заинтересованы и, следовательно, для которых они не регистрировались.

В одном из вариантов осуществления изобретения драйверы фильтров отдельно подключаются к томам как копии драйверов фильтров, одна копия на каждый том, и драйвер фильтра может подключить множество копий к одному тому. Каждая копия драйвера фильтра ассоциирована с ''высотой'', которая обозначает, где в порядке обратных вызовов расположен данный драйвер. «Высота» может быть определена предварительно или получена из флагов, предоставляемых драйвером, которые указывают на тип обработки, которую драйвер будет выполнять с данными обратного вызова.

Для эффективного отслеживания того, какие драйверы фильтров зарегистрировались для каких типов обратных вызовов и таким образом эффективно производить обратные вызовы требуемых драйверов в надлежащем порядке, администратор фильтров для каждого тома поддерживает упорядоченные списки, причем каждый список индексируется по типу операции, для которой фильтры зарегистрировали свой интерес в получении предварительных обратных вызовов и/или заключительных обратных вызовов. Администратор фильтров использует такой список для обратного вызова фильтров в требуемом порядке, и каждый фильтр возвращает статус (состояние). Если операции прошли успешно, то после последнего предварительного обратного вызова менеджер фильтров производит обратное преобразование данных обратного вызова в ПЗВВ и посылает ПЗВВ файловой системе.

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

Администратор фильтров также обеспечивает богатый набор API (программный интерфейс с приложением), которые обеспечивают функции, обычно требуемые фильтрам. Например, некоторым фильтрам требуется выполнение своего собственного ввода/вывода, поэтому обеспечиваются различные функции, которые упрощают такие операции. Также различные функции обеспечивают эффективную поддержку контекста копий, томов, файлов, дескрипторов потоков или потоков, отслеживая данные контекста для каждого фильтра относительно требуемого объекта. Настоящее изобретение обеспечивает поддержку извещения посредством набора обратных вызовов, которые устанавливают извещение для логического объекта, и упрощает ассоциацию контекста данного логического объекта с каждым фильтром. Контексты могут быть установлены и/или переустановлены произвольное количество раз. Другие функции допускают обмен между драйверами фильтров режима ядра и дополнительными службами и программами пользовательского режима, тогда как другие функции обеспечивают указанную поддержку, как это описано в патентной заявке США №10/187119, поданной 28 августа, 2002.

Другие преимущества будут очевидными из нижеследующего детального описания совместно с чертежами.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На фиг.1 приведена блок-схема, представляющая в общем виде компьютерную систему, в которой может быть реализовано настоящее изобретение.

На фиг.2 приведена блок-схема, представляющая в общем виде архитектуру, включающую в себя компоненты для управления вводом/выводом для фильтров согласно одному из аспектов настоящего изобретения.

На фиг.3 приведена блок-схема, представляющая в общем виде примеры управляемых фильтров согласно одному из аспектов настоящего изобретения.

На фиг.4 приведена блок-схема, представляющая в общем виде структуры данных, используемые администратором фильтров для выборочной передачи ввода/вывода к соответствующим образом зарегистрированным фильтрам согласно одному из аспектов настоящего изобретения.

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

На фиг.6 приведена блок-схема, представляющая дерево для эффективного определения, для каких копий имеются данные контекста согласно одному из аспектов настоящего изобретения.

На фиг.7 приведена блок-схема, представляющая возвращение данных контекста драйверу фильтра согласно одному из аспектов настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

ИЛЛЮСТРАТИВНАЯ РАБОЧАЯ СРЕДА

На Фиг.1 показан пример подходящей среды 100 компьютерной системы, в которой может быть реализовано настоящее изобретение. Среда 100 компьютерной системы является только одним примером подходящей компьютерной среды и не предназначена для введения каких-либо ограничений как на объем, так и на функциональность данного изобретения. Также компьютерную среду 100 не следует интерпретировать как имеющую какую-либо зависимость или требования, относящиеся к любому компоненту, приведенному в иллюстративной рабочей среде 100 или их комбинации.

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

Настоящее изобретение может быть описано в общем контексте выполняемых компьютером инструкций, таких как программные модули, выполняемые компьютером. В общем случае программные модули включают в себя процедуры, программы, объекты, компоненты, структуры данных, и т.п., которые выполняют конкретные задачи или реализуют определенные абстрактные типы данных. Настоящее изобретение также может применяться в распределенных компьютерных средах, в которых задачи выполняются удаленными вычислительными устройствами, связанных коммуникационной сетью. В распределенной компьютерной среде программные модули могут размещаться на носителях данных как локального, так и удаленного компьютера, включая запоминающие устройства.

Со ссылкой на фиг.1 иллюстративная система для реализации настоящего изобретения включает в себя компьютерное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, но не ограничиваться ими, процессорное устройство 120, системную память 130 и системную шину 121, связывающую различные компоненты системы, в том числе и системную память с процессорным устройством 120. Системная шина 121 может быть шинной структурой любого типа, включая шину памяти или контроллер памяти, периферийную шину и локальную шину любой из многочисленных шинных архитектур. Для примера, но не с целью ограничения, такие архитектуры включают в себя шину архитектуры промышленного стандарта (ISA), шину микроканальной архитектуры (MCA), расширенную ISA (EISA) шину, локальную шину ассоциации стандартов видеоэлектроники (VESA) и шину соединений периферийных компонентов (PCI), также известную как шину Mezzanine.

Компьютер 110 обычно включает в себя ряд читаемых компьютером носителей данных. Читаемые компьютером носители данных могут быть любыми доступными носителями данных, к которым может получить доступ компьютер 110, и включают в себя как энергозависимые, так и энергонезависимые носители данных и как съемные, так и несъемные носители данных. Для примера, но не с целью ограничения, считываемые компьютером носители данных могут включать в себя компьютерную среду хранения данных и среду связи. Компьютерная среда хранения данных включает в себя как энергозависимые, так и энергонезависимые, и как съемные, так и несъемные средства хранения данных, реализованные с применением любого способа или технологии хранения информации, такой как считываемые компьютером инструкции, структуры данных, программные модули или другие данные. Компьютерная среда хранения данных включает в себя, но не ограничиваются ими ОЗУ, ПЗУ, EEPROM, флэш память или другую технологию памяти, CD-ROM, универсальные цифровые диски (DVD) или другие оптические средства хранения данных, магнитные кассеты, магнитные ленты, средства хранения данных на магнитных дисках или другие магнитные средства хранения данных или любые другие носители данных, которые могут быть использованы для хранения необходимой информации и к которым может получить доступ компьютер 110. Среда связи представляет считываемые компьютером инструкции, структуры данных, программные модули или другие данные в виде модулированного сигнала данных, такого как несущая или другой транспортный механизм, и включают в себя любую среду доставки информации. Термин "модулированный сигнал данных" означает сигнал, имеющий одну или более его характеристик, установленных или изменяемых таким образом, что при этом в сигнале кодируется информация. Для примера, но не с целью ограничения, среда связи включает в себя кабельные средства, такие как кабельная сеть или прямое кабельное соединение, беспроводные средства, такие как акустические, РЧ (радиочастотные), инфракрасные и другие беспроводные средства. К считываемым компьютером носителей данных также следует отнести любую комбинацию упомянутых выше носителей.

Системная память 130 включает в себя компьютерную среду хранения данных в виде энергозависимой и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ) 131 и оперативное запоминающее устройство (ОЗУ) 132. Базовая система 133 ввода/вывода (BIOS), содержащая основные подпрограммы, участвующие в передаче информации между элементами в компьютере 110, например, во время запуска, обычно хранятся в ПЗУ 131. ОЗУ 132 обычно содержит данные и/или программные модули, которые являются непосредственно доступными и/или выполняются в настоящее время процессорным устройством 120. Для примера, но не с целью ограничения на Фиг.1 показаны операционная система 134, файловая система 135, прикладные программы 136, другие программные модули 137 и данные 138 программ. Компьютер 110 также может включать в себя другие сменные/несменные, энергозависимые/энергонезависимые компьютерные средства хранения данных. Исключительно в качестве примера на Фиг.1 показан привод 141 жесткого диска, считывающий и записывающий на несъемный, энергонезависимый магнитный носитель данных, привод 151 магнитного диска, считывающий и записывающий на съемный энергонезависимый магнитный диск 152 и привод 155 оптического диска, считывающий и записывающий на съемный энергонезависимый оптический диск 156, такой как CD-ROM или другой оптический носитель данных. Другие сменные/несменные, энергозависимые/энергонезависимые компьютерные средства хранения данных, которые могут применяться в иллюстративной рабочей среде, включают в себя, но не ограничиваются ими кассеты с магнитной лентой, карты флэш памяти, универсальные цифровые диски, цифровую видеоленту, твердотельное ОЗУ, твердотельное ПЗУ, и т.п. Привод 141 жесткого диска обычно связан с системной шиной 121 посредством интерфейса несъемной памяти, таким как интерфейс 140, а привод 151 магнитного диска и привод 155 оптического диска обычно связаны с системной шиной 121 посредством интерфейса съемной памяти, таким как интерфейс 150.

Приводы и ассоциированные с ними компьютерные среды хранения данных, обсуждаемые выше и иллюстрированные на фиг.1, обеспечивают в компьютере 110 хранение считываемых компьютером инструкций, структур данных, программных модулей и других данных. Например, на Фиг.1 привод жесткого диска изображен хранящим операционную систему 144, прикладные программы 145, другие программные модули 146 и данные 147 программ. Необходимо заметить, что эти компоненты те же самые или отличаются от операционной системы 134, прикладных программ 136, других программных модулей 137 и данных 138 программ. Операционная система 144, прикладные программы 145, другие программные модули 146 и данные 147 программ имеют в данном случае отличающиеся номера для иллюстрации того, что, по меньшей мере, они являются отдельными копиями. Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, такие как планшет (цифровое устройство ввода графической информации) 164, микрофон 163, клавиатуру 162 и указывающее устройство 167, обычно называемое мышью, трекболом или сенсорным планшетом. Эти и другие устройства ввода часто соединены с процессорным устройством 120 через пользовательский интерфейс 160 ввода, связанный с системной шиной, но могут быть подсоединены через другой интерфейс или шинные структуры, такие как параллельный порт, игровой порт или универсальную последовательную шину (USB). Монитор 191 или другое устройство отображения также подсоединен к системной шине 121 через интерфейс, такой как видеоинтерфейс 190. Монитор 191 может также быть интегрирован с сенсорным экраном или ему подобным. Необходимо заметить, что монитор и/или сенсорный экран может быть физически связан с корпусом, в который встроено компьютерное устройство 110, например, как в персональном компьютере планшетного типа. Дополнительно, компьютеры, такие как компьютерное устройство 110, могут также включать в себя другие периферийные устройства вывода, такие как громкоговорители 192 и принтер 196, которые могут быть подсоединены через интерфейс 194 периферийных устройств вывода или ему подобный.

Компьютер 110 может работать в сетевом окружении, используя логические соединения с одним или более удаленными компьютерами, таким как удаленный компьютер 180. Удаленный компьютер 180 может быть персональным компьютером, сервером, маршрутизатором, сетевым ПК, одноранговым узлом сети или другим обычным узлом сети и обычно включает в себя ряд элементов, описанных выше в связи с компьютером 110, или все указанные элементы, несмотря на то, что на фиг.1 изображено только запоминающее устройство 181. Изображенные на фиг.1 логические соединения включают в себя локальную сеть (ЛС) 171 и глобальную сеть (ГС) 173, но также могут включать в себя другие сети. Такие типы сетевого окружения являются обычными в офисах, промышленных компьютерных сетях, интрасетях, Интернете. Например, в настоящем изобретении компьютерная система 110 может включать в себя машину-источник, из которой пересылаются данные, и удаленный компьютер 180 может включать в себя машину-приемник. Необходимо заметить, что машина-источник и машина-приемник не обязательно должны быть соединены посредством сети или каких-либо других средств, напротив, данные могут пересылаться посредством носителей данных, на которые платформа-источник может производить запись и с которых платформа (или платформы)-приемник может производить считывание.

При использовании в локальной сетевой среде компьютер 110 подсоединяется к ЛС 171 через сетевой интерфейс или адаптер 170. При использовании в глобальной сетевой среде компьютер 110 обычно включает в себя модем 172 или другие средства для установления соединения через ГС 173, такую как Интернет. Модем 172, который может быть внутренним или внешним, может быть подсоединен к системной шине 121 через пользовательский интерфейс 160 ввода или другим подходящим способом. В сетевой среде программные модули, описанные в связи с компьютером 110, или часть их могут храниться в удаленном устройстве хранения данных. Для примера, но не с целью ограничения, на Фиг.1 показаны удаленные прикладные программы 185, размещенные в запоминающем устройстве 181. Очевидно, что показанные сетевые соединения являются иллюстративными и могут быть использованы другие средства организации соединения между компьютерами.

МОДЕЛЬ И АРХИТЕКТУРА УПРАВЛЯЕМОГО ФИЛЬТРА ФАЙЛОВОЙ СИСТЕМЫ

Настоящее изобретение в целом относится к модели и архитектуре фильтров файловой системы и предназначено для улучшения управления вводом/выводом файловой системой при помощи фильтров, включая упрощение взаимодействия между различными продуктами, имеющими отношение к файловой системе. Необходимо заметить, что в данном описании модель в целом описывается со ссылками на драйверы фильтров, работающие между администратором ввода/вывода и основной файловой системой, которая может быть либо локальной, либо удаленной файловой системой и не описывается со ссылками на другие драйверы, включая драйверы фильтров, работающих между файловой системой и драйвером или драйверами устройства хранения данных (таких как FtDisk или DMIO).

Как используется в настоящем описании, "традиционные" драйверы фильтров обрабатывают пакеты запросов ввода/вывода - ПЗВВ, (IRP) традиционным способом по сравнению с новой моделью, которая использует обратные вызовы к зарегистрированным драйверам фильтров, как описано ниже. Поскольку предполагается, что использование традиционных драйверов фильтров будет со временем прекращено, драйверы фильтров, соответствующие новой модели регистрации и обратного вызова, будут называться в настоящем описании просто "драйверы фильтров".

Один из основных аспектов новой модели фильтров направлен на устранение традиционного, сложного прохождения ввода/вывода от традиционного фильтра к традиционному фильтру через модель стека и заменяет эту модель моделью управляемого обратного вызова, в которой ПЗВВ, быстрые пути ввода/вывода, обратные вызовы администратора памяти и т.п. преобразуются администратором фильтров в обратные вызовы, предоставляющие фильтрам данные обратного вызова в определенном формате. Фильтры не вызывают другие фильтры и не передают управление непосредственно другим фильтрам, а производят необходимые манипуляции с данными обратного вызова и возвращают статус (состояние) в виде ответа на обратный вызов, как это описано ниже. Поскольку фильтрам больше не требуется работать с ПЗВВ и т.п., большая часть сложной обработки ввода/вывода удаляется из фильтров и встраивается в один администратор фильтров, устраняя многие проблемы, вызываемые различными фильтрами. Например, ПЗВВ часто содержат неявную, сложную информацию, с обработкой которой традиционные фильтры обычно имеют трудности; настоящее изобретение устраняет эту проблему, вынуждая обрабатывать неявную информацию в администраторе фильтров и пропуская к фильтрам только явный контекст. Модель обратного вызова имеет дополнительное преимущество, решая проблему переполнения стека, и локализует вызовы, связанные с цепочечной отправкой ПЗВВ.

На Фиг.2 представлен иллюстративный вариант 200 реализации новой модели. Одним из преимуществ варианта реализации, представленного на Фиг.2, является то, что для применения новой модели не требуется каким-либо образом модифицировать существующие приложения, компоненты операционной системы и файловые системы. Например, в операционных системах Windows® приложение 202 будет продолжать совершать вызовы файловой системы (например, посредством вызовов функций/методов) через уровень 204 API к администратору 206 ввода/вывода. Как известно, администратор 206 ввода/вывода генерирует ПЗВВ или другой тип ввода/вывода и посылает ввод/вывод к вершине (традиционного) стека 208 драйверов фильтров. Как описано ниже, один из компонентов в стеке 208 является администратором 212 фильтров.

В общем случае администратор 212 фильтров преобразует ввод/вывод, т.е. один из ПЗВВ, быстрый ввод/вывод, обратный вызов фильтра ФС либо им подобные в унифицированные структуры, известные как данные обратного вызова. Подходящая структура данных обратного вызова описана ниже. Затем администратор 212 фильтров просматривает список зарегистрированных драйверов фильтров (например, пять таких драйверов 282А-282Е фильтров показаны на Фиг.2, хотя может быть и любое другое разумное количество драйверов), и для каждого драйвера фильтра может произвести зарегистрированную диспетчеризацию для операции ввода/вывода. Важно то, что в модели настоящего изобретения фильтры не принимают и/или не обрабатывают ПЗВВ, а вместо этого, по существу, инструктируют администратора 212 фильтров в том, что делать с запросом на ввод/вывод.

На Фиг.2 также показано, что традиционные драйверы 210 фильтров также будут поддерживаться в данном варианте осуществления, например, если поместить их на верх стека 210. Необходимо заметить, что возможно организовать их в каком-либо другом порядке относительно других компонентов стека. Например, поскольку традиционные драйверы фильтров приспособлены для обработки ПЗВВ, а не обратных вызовов, такие традиционные фильтры может «окружать» специальный управляющий код, генерирующий ПЗВВ из данных обратного вызова, для передачи в фильтры и приема от них (возможно модифицированного) ПЗВВ и преобразования его в ответ о состоянии. В этом случае традиционный фильтр может быть внедрен в модель обратного вызова и изолирован в ней. В любом случае традиционные фильтры могут быть использованы в новой модели.

Подводя итог рассмотрению варианта осуществления, показанного на Фиг.2, в новой модели используется администратор 212 фильтров файловой системы и помещается в стек 208 драйверов фильтров как традиционный драйвер фильтра таким образом, что он может принимать и обрабатывать ПЗВВ. Необходимо заметить, что это позволяет администратору фильтров упростить работу в существующей системе ввода/вывода, хотя очевидно, что может быть использована эквивалентная модель (например, без вышележащих традиционных фильтров), в которой обновленный администратор ввода/вывода передает данные ввода/вывода в администратор фильтров в виде, отличном от структуры данных ПЗВВ. Например, когда администратор ввода/вывода формирует ПЗВВ, драйвер фильтра генерирует структуру данных обратного вызова из ПЗВВ и, таким образом, может оказаться более эффективным, если администратор ввода/вывода будет непосредственно генерировать структуру данных обратного вызова. Необходимо заметить, что кое-что другое, чем ПЗВВ, уже используется в существующих системах для быстрого ввода/вывода, обратных вызовов менеджера памяти и т.п., основанные для повышения производительности на способе обратного вызова, а не на пакетном способе, для некоторых общих задач ввода/вывода, таких как чтение/запись/управление устройствами ввода/вывода. Дополнительно необходимо заметить, что в существующих системах быстрый ввод/вывод все еще проходит через стек (то есть является цепочечным) и таким образом отличается от модели согласно настоящему изобретению, основанной на обратном вызове. Для простоты, если не оговорено обратное, в настоящем описании будут использоваться главным образом примеры, основанные на ПЗВВ.

В одном из вариантов осуществления изобретения драйверы фильтров содержат объекты или им подобные структуры, которые при создании экземпляра объекта, обычно во время процедуры инициализации их драйвера, регистрируются при помощи механизма регистрации в администраторе 212 фильтров. Для большей эффективности драйверы фильтров обычно регистрируются только для запросов файловой системы, в обработке которых они заинтересованы. С этой целью, в качестве части процедуры регистрации, каждый драйвер фильтра извещает администратор фильтров о типах запросов ввода/вывода, в которых он заинтересован (например, создание, чтение, запись, закрытие и т.п.). Например, драйвер фильтра шифрования может зарегистрироваться для чтения и записи ПЗВВ и не регистрироваться для других, где данные не требуют шифрования или дешифрования. Аналогично, фильтр квоты может быть заинтересован только в операциях создания файлов и записи файлов. В результате данная модель является более эффективной, чем модель стека фильтров, так как драйверы фильтров видят только ввод/вывод, для которого они зарегистрированы.

Для того чтобы сделать возможным подключение к томам, модель согласно настоящему изобретению определяет концепцию "копии" драйвера фильтра (и также контекст тома, как описано ниже). Более точно, драйверы фильтров, которым требуется подключиться к тому, извещаются посредством сообщения об установке копии, когда монтируется новый том. Аналогичное извещение обеспечивается для томов, уже смонтированных перед загрузкой драйвера. Затем драйверы фильтров могут выбрать подключение к тому посредством регистрации, как описано ниже, и, если это так, объект-копия используется для представления копии подключения. Аналогично извещаются драйверы фильтров, когда том демонтируется, а именно, через уведомление об отключении копии. Настоящая модель также позволяет драйверам фильтров динамически отключаться от смонтированного тома.

Драйвер фильтра может быть ассоциирован с «высотой», которая указывает, где в последовательности обратных вызовов расположен этот драйвер, как это в общем виде описано в заявке на патент США №09/768098 озаглавленной "Method and System for Deterministic Ordering of Software Modules". Более того, как показано на фиг.3, драйверы фильтров могут подключаться к одному тому много раз, создавая копию для каждого подключения (хотя для того, чтобы делать это, каждая копия для одного и того же тома должна находиться на разной «высоте», либо по порядковому номеру, либо при помощи какого-либо механизма доминирования).

На фиг.3 показан пример фильтра, который имеет множество копий. На фиг.3 фильтр А, например фильтр "мониторинга активности файловой системы", контролирует файловый ввод/вывод и имеет две копии, фильтр А и фильтр А'. Таким образом, продукт мониторинга файловой активности имеет возможность наблюдать (через фильтр А) ввод/вывод входящий в промежуточный (например, антивирусный) фильтр В, и также наблюдать (через фильтр А') ввод/вывод проходящий в конечном итоге через промежуточный фильтр, на его пути к файловой системе. Например, продукт мониторинга файловой активности может включать в себя программу пользовательского режима (отдельно не показана), которой как фильтр А, так и фильтр А' посылают отчеты при помощи сообщений, как это описано ниже.

Таким образом, копии драйвера фильтра для каждого тома могут быть ассоциированными с «высотой», которая определяет местоположение каждой копии для данного тома. Высоты могут быть заранее заданы для данной копии фильтра, например, как описано в заявке на патент США №09/768098, и/или могут быть использованы механизм флагов или им подобный (описанный ниже) для определения подходящей высоты для фильтра. Например, антивирусному фильтру не должно быть разрешено находиться между фильтром шифрования и основной файловой системой, так как ему необходимо отслеживать данные как они есть, до шифрования. Флаги могут указывать, исследуют ли фильтры данные (например, антивирусный фильтр), модифицируют ли они данные (например, фильтр шифрования) и т.д., исходя из чего может быть определена «высота». В этом случае порядок обратных вызовов основывается не на порядке загрузки драйверов, а на неком заранее определенном логическом базисе.

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

Для большей эффективности, для того чтобы отслеживать, какие драйверы фильтров для каких типов обратных вызовов зарегистрированы и таким образом эффективно определять, какие типы драйверов вызывать при приеме запроса на ввод/вывод (например, ПЗВВ), администратор 212 фильтров поддерживает одну или более структур данных для каждого тома. Например, как представлено на фиг.4, когда копия фильтра регистрируется в механизме 402 регистрации (например, посредством вызова функции), в администраторе 212 фильтров механизм регистрации определяет посредством механизма 404 упорядочивания, где в порядке предварительного обратного вызова расположена копия драйвера. Механизм 404 упорядочивания может быть основан на простом сравнении «высот» или может включать в себя логические средства, оценивающие флаги для определения, для чего подходит данная копия фильтра. В любом случае поддерживаются узлы обратных вызовов для каждого тома с находящейся в них информацией о регистрации.

Как описано ниже, часть информации, посылаемой администратору фильтров при регистрации, составляет (например, в виде массива) список запросов файловой системы, для которых копия фильтра запрашивает предварительный обратный вызов. Эта информация используется для создания упорядоченного списка 408 для каждого тома (например, тома с:) или 410 (например, тома d:) или им подобного, при помощи которых механизм 412 обратного вызова в администраторе 212 фильтров может эффективно определять порядок вызова каждой копии. Например, как представлено на Фиг.4, если принят запрос на чтение файла в томе с:, то может быть быстро получен доступ к копиям фильтров, заинтересованных в чтении (как это указывается основным кодом ПЗВВ), например копия фильтра А, копия фильтра В и копия фильтра А' представляют собой порядок предварительного обратного вызова, как представлено в примере на фиг.4. Необходимо заметить, что это очень эффективно и также облегчает динамическую регистрацию; в любое время при регистрации новой копии фильтра механизм регистрации может подходящим образом перестроить списки.

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

Значения состояния, которые копия фильтра может вернуть в ответ на обратный вызов, в общем случае включает в себя «успех без обратного вызова», «успех с обратным вызовом», «ожидание», «синхронизацию», «завершение» и «запрет быстрого ввода/вывода». В одном из конкретных вариантов осуществления "FLT_PREOP_SUCCESS_NO_CALLBACK" продолжает обработку прохождения ввода/вывода так же, как и состояние "FLT_PREOP_SUCCESS_WITH_CALLBACK", которое дополнительно запрашивает завершение обратного вызова при завершении этого ввода/вывода. Фильтр также может определить FLT_PREOP_PENDING, который удерживает ввод/вывод до тех пор, пока фильтр не вызовет функцию FltCompletePendedPreOperation(). FLT_PREOP_SYNCHRONIZE ждет до завершения ввода/вывода и вызывает заключительный обратный вызов в контексте первоначального порождаемого подпроцесса. Синхронизация ввода/вывода управляется администратором фильтров. Необходимо заметить, что "ожидание" и "синхронизация" не могут быть возвращены при быстром вводе/выводе. FLT_PREOP_COMPLETE завершает ввод/вывод либо с кодом состояния успеха либо неуспеха (что в общем случае аналогично IoCompleteRequest в традиционной организации). FLT_PREOP_DISALLOW_FAST_IO является достоверным только для быстрого ввода/вывода и в общем случае является эквивалентом возврата FALSE в традиционном сообщении.

Таким образом, модель управляемого драйвера фильтра позволяет драйверам фильтров управлять путем (ходом) выполнения ввода/вывода через возврат состояния из подпрограммы предварительного обратного вызова. Это позволяет драйверам фильтров запрашивать различные пути обработки ввода/вывода, включая ожидание, завершение, передачу на нижележащий фильтр, запрос заключительного обратного вызова, запрос ''синхронизированного'' заключительного обратного вызова и т.д.

Как изложено в настоящем описании, копии фильтров регистрируются для заключительных завершающих обратных вызовов. В ответ на заключительный обратный вызов копия фильтра (например, которая перед этим вернула состояние FLT_PREOP_SUCCESS_WITH_CALLBACK) может вернуть состояние FLT_POSTOP_FINISHED_PROCESSING для продолжения завершения ввода/вывода или FLT_POSTOP_MORE_PROCESSING_REQUIRED для прекращения завершения и более позднего завершения ввода/вывода при помощи вызова функции FltCompletePendedPostOperation(). Фильтр может повторно инициировать ввод/вывод во время его обработки после выполнения операции посредством вызова функции FltReissueSynchronousIo() для обработчиков повторной обработки. Состояние FLT_POSTOP_UNDO_CREATE предусмотрено для фильтров, желающих заблокировать открытие файлов путем неудачного завершения запроса на создание (файла).

Завершение ввода/вывода обрабатывается администратором 212 фильтров способом, гарантирующим, что параметры, видимые копией фильтра в ее предварительном обратном вызове, будут теми же самыми в ее заключительном обратном вызове. Необходимо заметить, что это является улучшением по сравнению с традиционной моделью стека, в которой фильтры часто меняют параметры, указатели буфера и т.д., что приводит к многочисленным проблемам. В общем случае, это выполняется, как показано на фиг.5, где администратор фильтров поддерживает узел завершения для каждой копии (то есть, по меньшей мере, для копий, принявших обратные вызовы).

По существу, для каждой копии, вызванной в предварительном обратном вызове, которая (через ее состояние (статус)) имеет запрошенный обратный вызов, администратор фильтров создает моментальную копию параметров перед каждым предварительным обратным вызовом, сохраняет моментальную копию в узле завершения и помещает узел завершения в стек 502. Для управления данными заключительного обратного вызова для каждого ПЗВВ администратор фильтров поддерживает заголовок 504 IRPCTRL, не видимый для драйвера фильтра, который отслеживает информацию, включающую в себя объект устройства, указатель ПЗВВ, информацию узла, включающую в себя размер узла завершения и соответствующую ему копию, и т.д. Затем, во время заключительного обратного вызова администратор фильтров, по существу, проходит назад, извлекая из стека 504 каждый узел завершения и помещая данные узла завершения в данные 506 обратного вызова для данной копии, восстанавливая таким образом его параметры. Необходимо заметить, что стек может быть скопирован в другой стек при добавлении узла завершения, если копия фильтра динамически регистрируется до того, как по порядку совершен ее вызов; если данная копия зарегистрирована после того, как предварительный вызов уже миновал ее в порядке предварительного вызова для данного ПЗВВ, обратный вызов данной копии производиться не будет.

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

Возвращаясь к Фиг.2, после того, как сделан последний завершающий обратный вызов, администратор 212 фильтров проводит обратное преобразование (выполняет маршализацию) данных обратного вызова в ПЗВВ и возвращает ПЗВВ на верх стека по направлению к администратору ввода/вывода через все вышележащие традиционные фильтры 210. Очевидно, что с такой моделью управляемых фильтров устраняется или значительно уменьшается много недостатков традиционной модели.

В дополнение к вышеперечисленным функциям, администратор фильтров также предоставляет богатый набор API, который обеспечивает функции, которые обычно требуются фильтрам. Например, некоторые фильтры требуют выполнения своих собственных операций ввода/вывода, например антивирусный фильтр может потребовать прочтение файла перед его открытием. Когда драйвер фильтра желает инициировать собственную операцию ввода/вывода, он сначала вызывает FltAllocateCallbackData(). Эта функция создает и возвращает структуру FLT_CALLBACK_DATA, в которую затем фильтр заносит необходимые поля. Необходимо заметить, что FltAllocateCallbackData, по существу, является замещением вызова IoAllocateIrp() в традиционной системе. Когда фильтр готов послать запрос на ввод/вывод любому из оставшихся фильтров, традиционным фильтрам и базовой файловой системе, он вызывает FltPerformSynchronousIo() или FltPerformAsynchronousIo() (аналоги IoCallDriver()). По умолчанию, инициированный фильтром ввод/вывод посылается следующему драйверу, подсоединенному к данному тому, минуя любые фильтры, подсоединенные выше фильтра, инициировавшего ввод/вывод. Возможно, тем не менее, послать ввод/вывод на любое устройство в системе, что может потребоваться фильтру управления иерархическим хранением (УИХ).

В качестве другого примера, фильтрам иногда требуется создать файл, и функция FltCreateFile() предоставляется как нанальная точка для инициации ввода/вывода. Эта функция возвращает дескриптор, который может быть использован с API существующих операционных систем, использующих дескрипторы файлов, и разрешает создание файла другими копиями. Данная функция поддерживает переопределение с совместным доступом. Более того, администратор фильтров гарантирует, что любые обратные вызовы будут видны только фильтрам, расположенным ниже фильтра, пославшего запрос, включая загружаемые динамически, что, очевидно, позволяет избегать рекурсивных обратных вызовов. Для этого администратор фильтров создает файл с указанием на копию и использует это указание для идентификации фильтра, пославшего запрос. Необходимо заметить, что вхождение в точки монтирования являются исключением, так как они требуют возврата к вершине стека обратных вызовов.

FltReadFile() допускает синхронный и асинхронный ввод/вывод с поддерживаемым фильтрами обратным вызовом, который совершается при завершении ввода/вывода. FltWriteFile(), FltSetInformationFile() и т.д. имеют аналогичную семантику. FltAllocateCallbackData() позволяет настраивать ввод/вывод, включая FltPerformSynchronousIo(), FltPerformSynchronousIo(), принимающих обратный вызов при завершении ввода/вывода.

Управление контекстом является еще одним примером, когда API, предоставляемый администратором фильтров, является чрезвычайно полезным, поскольку фильтрам часто требуется ассоциировать структуры контекста с каждым дескриптором потока, потоком, копией и томом. Например, фильтры используют контексты для сохранения информации о каждом дескрипторе/потоке/файле/томе/копии, которые просматриваются, когда фильтр перехватывает ввод/вывод. Любой контекст или контексты, которые фильтр установил для логического объекта, будут направлены в фильтр, когда фильтр потребует этого, например, через API. Время жизни контекста управляется администратором 121 фильтров, и фильтры получают обратный вызов, если контекст удаляется вследствие удаления соответствующего объекта (такого как поток/файл/копия /том).

В соответствии с другим аспектом настоящего изобретения, администратор 212 фильтров предоставляет эффективную поддержку контекста для сохранения данных контекста (например, указателей или им подобных) для каждого фильтра в соответствующем объекте, а именно для дескриптора потока, потока, файла, копии или тома. Для этого настоящее изобретение обеспечивает поддержку контекста через набор API, которые возвращают контекст логического объекта, и таким образом упрощают ассоциацию контекста для каждого фильтра с данным логическим объектом. Контексты могут быть установлены и/или заново установлены в любое время. Настоящее изобретение также обеспечивает для копий поддержку извещений через набор обратных вызовов, которые устанавливают извещения для копии.

Типы логических объектов включают в себя копии, тома (том локального диска, или удаленный сетевой совместно используемый том), потоки (для файловых систем, поддерживающих множественные потоки для одного файла), дескрипторы потоков (объекты для каждого файла) и файлы (например, все потоки файла). Что касается копий, как это описано выше, когда фильтр подключается к тому, создается копия, и как так же описано выше, для одного тома может существовать более чем одна копия данного фильтра, например как выше, так и ниже другого фильтра в одном и том же томе. Каждая копия может иметь ассоциированный контекст, например, для указания на персональный регистрационный журнал для данной копии. Контекст тома может совместно использоваться копиями фильтров.

Для того чтобы ассоциировать контекст с объектом, фильтр вызывает FltAllocateContext(), определяя тип контекста (дескриптор потока, поток, файл, копия или том), размер контекста и должен ли быть контекст размещен в пуле страничной памяти или пуле памяти без страничной организации. После назначения и инициализации контекста фильтр ассоциирует контекст с объектом, вызывая соответствующую подпрограмму: FltSetStreamHandleContext(), FltSetStreamContext(), FltSetFileContext(), FltSetInstanceContext(),FltSetVolumeContext().

Как представлено на Фиг.6, для эффективного просмотра копий фильтров, ассоциированных с файлами, потоками и дескрипторами потоков, администратор 212 фильтров добавляет дерево (например, расходящееся дерево) к структурам данных, ассоциированным с файловым объектом. Более конкретно, операционная система облегчает добавление произвольного контекста к потоку, и администратор 212 фильтров использует этот механизм для добавления списка 608 управления потоком и дерева 610 к FSRTL_ADVANCED_FCB_HEADER 612, который, по существу, указывается файловым объектом 614 через его контекст 616. Каждый узел дерева 610 представляет копию фильтра, которая имеет ассоциированный контекст для этого потока. Хотя это не показано специально, могут существовать параллельные деревья: одно для пула страничной памяти и одно для пула не страничной памяти, как это определено копиями фильтра для различных типов доступа, которые могут быть необходимы. Для данного дескриптора потока доступ к каждому узлу дерева осуществляется с помощью ключей, включая файловый объект в качестве одного ключа и копию в качестве второго. Необходимо заметить, что для потоков ключ файлового объекта имеет значение «пусто» (NULL). Как представлено на Фиг.7, если обеспечены три ключа, а именно через данные в вызове функции механизма 412 контекста в составе (или ассоциированного с) администратора 212 фильтров, то для копии 702 драйвера фильтра подходящий узел дерева 610 может быть быстро найден, и соответствующий контекст 704 (например, в виде указателя контекста) возвращен запрашивающей копии 702 драйвера фильтра. Прохождение (дерева) является быстрым частично благодаря тому, что в общем случае данной конфигурации имеется не так много копий фильтров.

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

Typedef PVOID PFLT_CONTEXT;

NTSTATUS

(*PFLT_INSTANCE_SETUP_CALLBACK) (

IN CONST PFLT_RELATED_OBJECTS FltObjects,

IN FLT_INSTANCE_SETUP_FLAGS Flags,

IN DEVICE_TYPE VolumeDeviceType);

Если контекст требуется для конкретной копии, это может быть указано в данном обратном вызове. Контекст имеет тип PVOID, и система воспринимает его как абсолютно прозрачный, так что фильтр может использовать его для сохранения поля флагов, счетчика, указателя и всего, что ему требуется. Если фильтру удалось провести успешную инициализацию обратного вызова его копии и он хотел бы начать мониторинг активности указанного тома, он должен вернуть STATUS_SUCCESS. Если фильтр не желает, чтобы для данного тома создавалась копия, он должен вернуть STATUS_FLT_DO_NOT_ATTACH. Обратные вызовы очистки извещения предоставляются, чтобы должным образом синхронизировать отключение копии, если с томом возможно выполнение новых операций, и включают в себя InstanceQueryTeardown, InstanceTeardownStart и InstanceTeardownComplete.

Фильтр, предоставляющий структуру контекста для какого-либо логического объекта, должен выполнить вызов соответствующего ContextCleanupCallback. Другими словами, для того, чтобы избежать ненужного расхода памяти, фильтру не требуется отслеживать использованные им контексты, поскольку об этом при проведении очистки позаботится система. Если контекст должен быть освобожден, система вызывает ContextCleanupCallback фильтра. В течение указанного обратного вызова фильтр является ответственным за деинициализацию содержимого контекста, и после возврата система освобождает память, выделенную предшествующим вызовом фильтром функции FltAllocateContext(). Очистка предполагается завершенной успешно; поэтому не требуется возврата какого-либо значения. Система также гарантирует, что подпрограммы очистки контекста будут вызваны при IRQL достаточно низком, чтобы освобождение пула памяти могло быть сделано безопасно.

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

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

Контекст дескриптора потока очищается после того, как высвобождается последняя ссылка на дескриптор потока. Это может быть следствием того, что был закрыт пользовательский дескриптор или была высвобождена последняя ссылка администратора памяти или администратора кэша.

Контекст может быть установлен для объекта, если объект в настоящее время не имеет контекста или контекст может быть изменен. Фильтр может очистить контекст, используя одну из следующих подпрограмм, подходящих для конкретной ситуации: FltDeleteContext(), FltDeleteVolumeContext(), FltDeleteInstanceContext(), FltDeleteStreamContext() и FltDeleteStreamHandleContext().

Часто фильтру может требоваться некая базовая информация о логическом объекте для того, чтобы решить, представляет ли оно для него интерес. Для тома это может быть файловая система, является ли том локальным или удаленным, и находится ли он на сменном носителе и т.п. Для файла она может содержать имя файла, метку времени, размер, расширение и т.д. Система может предложить функции (например, FltGetFileInformation(), FltGetVolumeInformation()) для удобного получения такой информации. Фильтр также может желать вызвать FltTagFile() для того, чтобы установить точку повторной обработки файла.

Другой набор API, предоставляемый архитектурой согласно настоящему изобретению, направлен на упрощение связи между копиями фильтров и кодом пользовательского режима. Более конкретно, многие фильтры имеют сервисное дополнение в пользовательском режиме, которое обычно представляет собой компонент администрирования продукта, и существует необходимость обмена фильтров с указанной сервисной частью. Настоящая архитектура позволяет обеспечить API для указанных продуктов как в случае обмена, инициированного пользовательским режимом, так и обмена, инициированного ядром (операционной системы).

Например, для фильтров, обменивающихся с компонентом пользовательского режима, для этих приложений пользовательского режима доступна библиотека. Библиотека содержит подпрограммы, в том числе подпрограммы для загрузки и выгрузки фильтров, присоединения фильтров к томам и отсоединения от томов, открытия каналов связи к фильтрам из пользовательского режима и посылки/приема данных от фильтров и запросов информации у системы о текущем состоянии системы. Например, программа пользовательского режима может сделать запрос об уже загруженных фильтрах, какие копии (фильтров) существуют для данного тома или для данного фильтра, и т.д. Необходимо отметить, что обмен фильтр-пользователь отличается от предоставляемых API администрирования, которые допускают перечисление фильтров/копий, загрузке/выгрузке фильтров и т.д., поскольку API для обмена фильтр-пользователь предназначен для использования фильтрами для осуществления их собственного обмена.

Подводя итог, новая модель фильтров предоставляет способ записи надежных эффективных фильтров файловой системы, допускающих динамическую загрузку/выгрузку, динамическое присоединение/отсоединение от томов, гибкую организацию и доступ к богатому набору API, которые обычно необходимы фильтрам. Ниже представлены конкретные детали одного из иллюстративных вариантов осуществления изобретения, основанного на операционной системе Windows® NT/2000/XP.

ИЛЛЮСТРАТИВНЫЙ ВАРИАНТ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

Ниже описаны некоторые инициированные фильтрами операции, выполняемые посредством вызовов функций, в том числе регистрация администратором фильтров.

Декларация фильтром обратного вызова для интересующих операций ввода/вывода:

Декларация фильтром структуры регистрации:

Регистрация фильтра администратором фильтров:

Получение фильтром предварительного обратного вызова:

В данном иллюстративном варианте осуществления драйверы фильтров файловой системы содержат драйверы ядра NT и как таковые требуют экспорта функции, называемой DriverEntry(), которая является первой функцией, вызываемой при загрузке драйвера. При загрузке фильтр для регистрации вызывает функцию, именуемую в его DriverEntry() как FltRegisterFilter(). FltRegisterFilter() принимает в виде параметра структуру FLT_REGISTRATION, содержащую (среди прочего) обратные вызовы для установки копии и отключения копии, список указателей функций обратного вызова контекста и список указателей обратных вызовов для операций файловой системы. Необходимо заметить, что во многих сценариях, в которых фильтр желает подключать только относительно небольшое количество операций и заинтересован только в установлении контекста для небольшого количества, если они есть, объектов, указанный список может быть очень коротким.

В одном из альтернативных вариантов осуществления изобретения может присутствовать поле флагов, в котором фильтр устанавливает один или более флагов атрибутов фильтра, из которых может быть получена высота. Например, флаг может быть установлен фильтром, который модифицирует данные, например фильтром шифрования или сжатия данных для извещения системы о том, что он модифицирует данные на пути к основной файловой системе или от нее. В данном варианте осуществления любой фильтр, который расщепляет данные пользователя на множество потоков, также должен установить этот флаг. Фильтры также могут устанавливать флаг для индикации того, что фильтр проверяет данные, например вирусный фильтр, которому необходимо видеть простой текст, нешифрованные данные, будет устанавливать этот флаг. Флаги также доступны для фильтров, модифицирующих стандартную информацию (такую как метки времени и даты), для фильтров, проверяющих стандартную информацию (например, для выполнения различных операций над фильтрами исходя из их даты), для фильтров, перенаправляющих операцию создания к файлу/потоку с другим именем (например, фильтр типа символьных ссылок/SIS) и для фильтров, работа которых зависит от имен файлов (такие как вирусные фильтры, сканирующие файлы. EXE и.DOC).

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

Ниже представлен один из логических порядков для типов драйверов фильтров файловой системы:

Монитор активности (наблюдатели файлов и т.д.)

Восстановление после стирания

Антивирус Репликация

Непрерывное резервное копирование

Скрининг контента

Менеджер квот

Кластеризация файловой системы

HSM (управление иерархическим хранением данных, разработанное третьей стороной)

Сжатие

Шифрование

Управление физической квотой

Резервное копирование открытых файлов (мгновенный снимок открытых файлов)

Усиливающий агент безопасности

Защита от копирования

Система

Инфраструктура фильтров (администратор фильтров)

Как описано выше, данные обратного вызова представляют собой единицу представления ввода/вывода, в чем-то аналогичную ПЗВВ, для целей представления необходимой информации, описывающей операцию для драйвера фильтра. Данные обратного вызова содержат нормализованные параметры, ориентированные на использование с фильтрами файловой системы, и существуют для вызовов быстрого ввода/вывода, ПЗВВ и фильтров файловой системы. Секция изменяемых параметров может модифицироваться (то есть искажаться) драйвером, и секция параметров принимается из очереди на обработку администратором фильтров от фильтра к фильтру посредством операции извлечения из стека узла завершения, описанной выше.

Ниже приведен пример структуры данных обратного вызова.

Ниже приведен пример блока параметров ввода/вывода.

Обратные вызовы, выполняемые перед операцией, имеют такую же сигнатуру.

Как описано выше, Обратные вызовы, выполняемые перед операцией, могут возвращать одно из следующих состояний (и другие) для FLT_PREOP_CALLBACK_STATUS:

FLT_PREOP_SUCCESS_WITH_CALLBACK - операция успешна и фильтр требует своего обратного вызова после операции.

FLT_PREOP_SUCCESS_NO_CALLBACK - операция успешна, но фильтр не требует своего обратного вызова после операции.

FLT_PREOP_PENDING - драйвер фильтра завершит операцию в будущем (посредством вызова FltCompletePendedOperation()).

FLT_PREOP_COMPLETE - фильтр завершил операцию. Операция может быть показана, как неуспешная путем установки состояния ошибки и возвращения указанного состояния обратного вызова.

FLT_PREOP_SYNCHRONIZE - фильтр требует завершения обработки, выполняемой в том же контексте цепочки, в котором выполнялся обратный вызов перед операцией; цепочка, инициировавшая данный ввод/вывод, не будет завершена до завершения данного ввода/вывода.

FLT_PREOP_DISALLOW_FASTIO - фильтр требует запретить данную операцию быстрого ввода/вывода; Это указывает на то, что путь быстрого ввода/вывода запрещен, но менеджер ввода/вывода будет использовать обычный путь ПЗВВ для завершения ввода/вывода.

Обратный вызов, совершаемый после операции, имеет аналогичную сигнатуру:

Флаги могут включать в себя:

FILTER_POST_OPERATION_DRAINING - Если установлен, данная копия отключена и эта подпрограмма, вызываемая после операции, вызвана для выполнения очистки.

FLT_POSTOP_FINISHED_PROCESSING:

FILTER_POSTOP_FINISHED_PROCESSING - фильтр завершил обработку операции.

FILTER_POSTOP_MORE_PROCESSING_REQUIRED - драйвер фильтра завершит операцию в будущем (посредством вызова FltCompletePendedOperation).

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

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

Операции, для которых могут быть обеспечены предварительные и заключительные обратные вызовы, включают в себя существующие коды IRP_MJ_ от IRP_MJ_CREATE до IRP_MJ_PNP, IRP_MJ коды, созданные для представления быстрых операций ввода/вывода, для которых не существует эквивалента ПЗВВ, и IRP_MJ коды, созданные для представления операций фильтрации файловой системы. Если будущие версии операционной системы добавят новые коды IRP_MJ_, это не окажет воздействия на существующие фильтры, и они не будут получать никаких обратных вызовов для подпрограмм IRP_MJ_, которые не существовали во время компиляции фильтров. Если фильтр регистрируется с кодом IRP_MJ_, который не распознается операционной системой, FltRegisterFilter() возвращает специальное состояние успеха, и выполняются обратные вызовы функций, существующих в данной версии. Если фильтр не желает продолжать работу и если не будут обеспечены один или более обратных вызовов, фильтр может вызвать FltUnregisterFilter().

Необходимо отметить, что обратные вызовы для IRP_MJ_READ и IRP_MJ_WRITE могут быть выполнены для ввода/вывода, основанного на ПЗВВ и для быстрого ввода/вывода. Предварительный вызов для IRP_MJ_CREATE не передает контексты для файла или потока, поскольку во время перед созданием еще не определено, какой файл или поток (если они есть) должен быть создан. Заключительный вызов для IRP_MJ_CLOSE не передает никакие контексты, поскольку внутрисистемные структуры, с которыми они ассоциированы, освобождаются перед вызовом подпрограммы, выполняемой после закрытия. Предварительные обратные вызовы для IRP_MJ_CLEANUP и IRP_MJ_CLOSE должны быть успешными и возвращать FLT_PREOP_SUCCES_WITH_CALLBACK или FLT_PREOP_SUCCES_NO_CALLBACK.

Обратные вызовы, выполняемые после операции, имеют возможность быть вызваны на уровне DPC и таким образом им не требуется ожидать ресурсов или разрешения взаимных исключений, и также им не требуется вызывать функции, для которых требуется ожидание. Необходимо заметить, что подпрограммы, такие как FltSetFileContext(), захватывают ресурсы и таким образом не могут быть вызваны из обратных вызовов, совершаемых после операции.

Как описано выше, заключительные обратные вызовы возвращают либо FLT_POSTOP_STATUS_SUCCESS или FLT_POSTOP_MORE_PROCESSING_REQUIRED. Заключительные обратные вызовы могут быть завершены неуспешно посредством установки кода ошибки в IoStatus, и в общем случае правилом является то, что фильтр отвечает за ликвидацию всего, что было сделано.

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

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

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

Изобретение относится к области компьютерной техники, в частности к использованию драйверов фильтров, которые управляются для приема обратных вызовов для запросов на ввод/вывод, в получении которых драйверы фильтров зарегистрировали свою необходимость. Технический результат, заключающийся в повышении эффективности и оптимальном использовании ресурсов системы, достигается за счет того, что копии драйверов фильтров для каждого тома регистрируются администратором фильтров для предварительных обратных вызовов (для ввода/вывода к файловой системе) и заключительных обратных вызовов (для ввода/вывода от файловой системы), и идентифицируют, от каких запросов на ввод/вывод (например, создание, чтение, запись) они зарегистрированы для получения обратных вызовов. Администратор фильтров упорядочивает копии для обратных вызовов. При получении запроса на ввод/вывод администратор фильтров преобразует запрос на ввод/вывод в данные обратного вызова и вызывает "заинтересованные" фильтры в порядке обратных вызовов, при помощи чего копии фильтров могут обрабатывать данные ввода/вывода. После возвращения запроса от файловой системы фильтры, требующие заключительного обратного вызова, вызываются в обратном порядке. 4 н. и 90 з.п. ф-лы, 7 ил.

1. Способ обработки пакетов запросов ввода вывода с использованием обратных вызовов к зарегистрированным драйверам фильтров в компьютерной среде, содержащий этапы:

прием запроса на ввод/вывод файловой системы, направленного к файловой системе;

вызов первого драйвера фильтра посредством предварительного обратного вызова, основываясь на порядке предварительных обратных вызовов, что включает в себя передачу данных, соответствующих запросу на ввод/вывод, к первому драйверу фильтра;

вызов по меньшей мере одного другого драйвера фильтра посредством другого предварительного обратного вызова, что включает в себя вызов последнего драйвера, основываясь на порядке предварительных обратных вызовов, и что включает в себя передачу данных, соответствующих запросу на ввод/вывод, к последнему драйверу фильтра; и

передачу запроса файловой системы на ввод/вывод к файловой системе, причем запрос файловой системы на ввод/вывод включает в себя данные, соответствующие запросу на ввод/вывод, который обрабатывается по меньшей мере одним из драйверов фильтров.

множество драйверов фильтров; и

администратор фильтров, который:

а) регистрирует каждый из драйверов фильтров;

б) компонует драйверы фильтров в по меньшей мере одном порядке предварительных вызовов, причем каждый порядок предварительных вызовов соответствует набору из одного или более драйверов фильтров;

в) принимает данные запроса;

г) вызывает по меньшей мере один из драйверов фильтров, основываясь на выбранном порядке предварительных вызовов, что включает в себя предоставление данных обратного вызова, основываясь на запросе, к каждому вызываемому драйверу фильтра;

д) принимает состояние от каждого вызываемого драйвера фильтра; и

е) передает запрос на ввод/вывод к файловой системе, включая данные, соответствующие данным обратного вызова.

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

прием запроса на ввод/вывод, направленного к файловой системе, инициированного в промежуточном драйвере фильтра;

поддержание информации, указывающей, что запрос на ввод/вывод инициирован промежуточным драйвером фильтра;

посылку запроса на ввод/вывод к файловой системе;

прием данных состояния от файловой системы, соответствующих запросу на ввод/вывод;

возврат данных состояния промежуточному драйверу фильтра, который инициировал данный запрос на ввод/вывод;

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