Здравствуйте,

Имеется работающий legacy virtual disk driver, который умеет монтировать образ диска, лежащий в файле. В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.

Появилась необходимость поддержать образы, содержащие dynamic disk. И вот тут мы имеем грабли: драйвер видит все 4 simple volumes, находящихся на сэмпловом dynamic disk'е, но размеры всех, кроме первого, равны нулю.

Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем

2) Полностью переписать драйвер в виде virtual SCSI miniport. Тут, судя по тому, что я нарыл в OSRONLINE есть некоторые неприятные грабли (например, SRB completion), обходящиеся различными хаками. Но в целом этот путь выглядит как вполне органичное решение, практически неминуемо приводящее к счастью

Вопрос в том, какой из путей является чуть менее рисковым
Прежде написанием SCSI miniport'ов заниматься не приходилось, и достойных примеров в DDK найти не удалось, но достижение результата при этом варианте выглядит более реальным.
С другой стороны, есть вероятность, что дописав немного кода к текущему драйверу можно также добиться желаемого, но уже с гораздо более туманными перспективами.

Помогите, пожалуйста, сделать правильный выбор!

Здравствуйте, Ulin, Вы писали:

U>Здравствуйте,

U>Имеется работающий legacy virtual disk driver, который умеет монтировать образ диска, лежащий в файле. В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.

U>Появилась необходимость поддержать образы, содержащие dynamic disk. И вот тут мы имеем грабли: драйвер видит все 4 simple volumes, находящихся на сэмпловом dynamic disk'е, но размеры всех, кроме первого, равны нулю.

U>Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

U>1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем
Самое правильное решение. И никаких проблем.

U>2) Полностью переписать драйвер в виде virtual SCSI miniport. Тут, судя по тому, что я нарыл в OSRONLINE есть некоторые неприятные грабли (например, SRB completion), обходящиеся различными хаками. Но в целом этот путь выглядит как вполне органичное решение, практически неминуемо приводящее к счастью
Ну и неправда ваша. Не выйдет.

U>Вопрос в том, какой из путей является чуть менее рисковым
U>Прежде написанием SCSI miniport'ов заниматься не приходилось, и достойных примеров в DDK найти не удалось, но достижение результата при этом варианте выглядит более реальным.
Самый главный пример — это bus из комплекта toaster.
U>С другой стороны, есть вероятность, что дописав немного кода к текущему драйверу можно также добиться желаемого, но уже с гораздо более туманными перспективами.

U>Помогите, пожалуйста, сделать правильный выбор!

Здравствуйте, Ulin, Вы писали:

В динамическом диске структура диска храниться не в mbr, а в специальной области в конце диска.
Структура достаточно сложная и связанна с операционной системой.

Если вы будете использовать scsi минипорт то база данных динамического диска прочитаеться но он будет foreihn и его нужно будет импортировать в систему. при этом данные в базе данных изменяться и в самой оси тоже.
Соответсвенно если парсить бд ldm то это очень непросто. пример парса есть в исходниках линукс.

Здравствуйте, Ulin, Вы писали:

U>Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

U>1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем

PDO получают на входе AddDevice.Вы должны создать object драйвера через bus driver. Тип object — FILE_CONTROLLER.

Спасибо всем за информацию.
Насколько я понял, задачка все-таки проще решается без полного переписывания драйвера в качестве SCSI miniport (и это не может не радовать, так как при виде обсуждений virtual SCSI miniport на osronline становится грустно ).

Существуют как минимум 2 варианта решения в рамках текущего драйвера:
1. Дополнительно распарсить структуру динамического диска, и создать все партишены руками, как происходить сейчас. Вариант, как я вижу, сильно непростой и рисковый.
2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI. Тогда код по созданию партишенов выбрасывается, но появляется еще 1 драйвер — bus driver для возможности динамически монтировать/демонтировать диски.

Еще раз спасибо за направление. Ушел изучать toaster

Здравствуйте, Ulin, Вы писали:

U>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.
U>Еще раз спасибо за направление. Ушел изучать toaster
Это правильно.

Здравствуйте, IakovK, Вы писали:

IK>Здравствуйте, Ulin, Вы писали:

U>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А можно поподробней. Кто создаст PDO для этого Virtual Disk?
Какой stack будет в этом случае?

U>>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А>А можно поподробней. Кто создаст PDO для этого Virtual Disk?
вы и создаете. См. toaster (bus driver).
А>Какой stack будет в этом случае?
такой же, как и в случае обычного диска.

Здравствуйте, IakovK, Вы писали:

U>>>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>>>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А>>А можно поподробней. Кто создаст PDO для этого Virtual Disk?
IK>вы и создаете. См. toaster (bus driver).
А>>Какой stack будет в этом случае?
IK>такой же, как и в случае обычного диска.
Дело в том что disk.sys в основном не обрабатывает IOCTL а пересылает IOCTL к low stack driver. Например IOCTL_DISK_GET_DRIVE_GEOMETRY. Параметры этого IOCTL заполняются не disk.sys.
Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.

Здравствуйте, eagersh, Вы писали:
...
E>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
Зачем?

Здравствуйте, IakovK, Вы писали:

E>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>Зачем?
Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
Reference: WDK\src\storage\class\disk\

Все же вариант с йоктлами возможно не самый лучший тк при подкличении диска даже при наличии поддержки всех йоктлов его придеться ИМПОРТИРОВАТЬ.
причем если вы будете подключять дин диски созданные на разных системах одновременно то они объединяться в одну группу и потом при новом подключении таких дисков по отдельности вы будете видеть пропущенные диски. да и продумайте как будете обрабатывать волумы raid5,raid0,raid1,spanned. ведь для этого нужно подключать все диски одновоременно иначе у них перестанут совпадать времена создания и их нужно будет импортировать тоже. вариант с парсом структуры диска выглядит лучше с точки зрения юзабилити, тк позволяет избежать всех этих проблем.

E>>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>>Зачем?
E>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
E>Reference: WDK\src\storage\class\disk\

Здравствуйте, assad, Вы писали:

A>Все же вариант с йоктлами возможно не самый лучший тк при подкличении диска даже при наличии поддержки всех йоктлов его придеться ИМПОРТИРОВАТЬ.
A>причем если вы будете подключять дин диски созданные на разных системах одновременно то они объединяться в одну группу и потом при новом подключении таких дисков по отдельности вы будете видеть пропущенные диски. да и продумайте как будете обрабатывать волумы raid5,raid0,raid1,spanned. ведь для этого нужно подключать все диски одновоременно иначе у них перестанут совпадать времена создания и их нужно будет импортировать тоже. вариант с парсом структуры диска выглядит лучше с точки зрения юзабилити, тк позволяет избежать всех этих проблем.

Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.

Здравствуйте, eagersh, Вы писали:

E>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает.
А что это за запросы? partmgr это просто вехний фильтр диска, который мониторит изменения в таблице разделов, с тем чтобы вовремя нотифицировать pnp о создании/удалении раздела.

E>Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
драйвер, лежащий ниже в стеке — это scsi(stor)-port. Касательно ioctl, котрые он должен обрабатывать см. ntddscsi.h

E>Reference: WDK\src\storage\class\disk\
кстати, в WDK тяжело читать disk.sys, т.к. его функциональность теперь несколько размазана. Чисто в образовательных целях я бы рекомендовал изучать по исходникам из c:\WINDDK\3790.1830\src\storage\class\disk\

Здравствуйте, eagersh, Вы писали:

E>>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>>Зачем?
E>Что зачем?
другой тип drive
E>Кто будет обрабатывать все запросы от Partition Manager?
драйвер шины
E>disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
E>Reference: WDK\src\storage\class\disk\

Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>Здравствуйте, eagersh, Вы писали:

E>>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает.
SS>А что это за запросы? partmgr это просто вехний фильтр диска, который мониторит изменения в таблице разделов, с тем чтобы вовремя нотифицировать pnp о создании/удалении раздела.

А я и не спорю.Изначально спор был о том что disk.sys будет
делать всю работу.Это не так.Надо bus driver который будет создавать Virtual Disk. Virtual Disk также будет создавать PDO для каждой partion.

E>>Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
SS>драйвер, лежащий ниже в стеке — это scsi(stor)-port. Касательно ioctl, котрые он должен обрабатывать см. ntddscsi.h

Ulin который создал пост писал что он не создает Virtual SCSI mini-port. Он выбрал схему legacy Virtual Disk. При этой схеме
the driver будет получать большое количество IOCTL запросов при инициализации,например DISK_GEOMETRY. Некоторые запросы можно пропустить но в большинстве случае надо их правильно обработать.



E>>Reference: WDK\src\storage\class\disk\
SS>кстати, в WDK тяжело читать disk.sys, т.к. его функциональность теперь несколько размазана. Чисто в образовательных целях я бы рекомендовал изучать по исходникам из c:\WINDDK\3790.1830\src\storage\class\disk\

К сожелению это почти единственный source где можно посмотреть
какие запросы получает any disk driver. Хотя disk.sys не показывает как эти IOCTL обрабатывать, но это лучше чем ничего.
3790.1830 build is very old. The latest is WDK 7100.0.0.

Здравствуйте, Ulin, Вы писали:

U>Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.
А как вы создаете ваш диск?

Здравствуйте, eagersh, Вы писали:

U>>Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.
E>А как вы создаете ваш диск?

Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.

Здравствуйте, Ulin, Вы писали:

E>>А как вы создаете ваш диск?

U>Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.
А какой нижний интерфейс? Если network то можно использовать еще и iSCSI. Но я сним мало знаком и что нибудь дельное посоветовать не могу.

Здравствуйте, eagersh, Вы писали:

U>>Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.
E>А какой нижний интерфейс? Если network то можно использовать еще и iSCSI. Но я сним мало знаком и что нибудь дельное посоветовать не могу.

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

Насколько я понял, покопавшись еще немного в этой теме, получив от bus'а PDO для очередного замонтированного диска, мне достаточно создать такой FDO, к которому PnP подключит сверху storage class driver (disk.sys). Где-то еще выше станет PartitionManager. Соответственно, disk.sys начнет выполнять всю грязную работу по распознаванию партишенов, посылая моему девайсу некоторые IOCTL (вроде GET_DISK_GEOMETRY, но не GET_DRIVE_LAYOUT), и пачку запросов на чтение (я так понимаю, уже в виде SRB, а не как IRP). Соответственно, моей основной заботой с этого момента станет обработка read/write. Поправьте меня, плиз, если я где-то в этой общей схеме не прав.

В общем, теперь возникает вопрос, как собственно заставить PnP manager'а прицепить ко мне наверх disk.sys. Просмотр msdn пока ничего не дает на эту тему. Этот момент (именно касательно disk.sys, или в виде какого-то шаблона, из которого можно вывести мой случай) вообще где-то документирован?

Все, что я пока нашел, это один пост на osronline, из которого я понял, что мой PDO должен иметь некий специфический HardwareId (GenDisk вроде бы). А подключаемый в стек новый девайс должен иметь тип MASS_STORAGE