A question about reserving SCSI disk(s)

I would like to reserve some SCSI disk(s) for the exclusive use of a certain KM component.

The very first idea that gets into my head is developing a lower filter for Partmgs.sys, with its filter device sitting in between PDO that is created by Disk.sys, and FDO that is created by Partmgr.sys.

It is understandable that Admin users have to specify that they want to reserve the target disk for our particular purpose, in the registry settings. It is also understandable that above mentioned registry settings have to ensure that, apart from the other things, the target disk is hidden from the volume manager, which means that no FS can be mounted on it. The way I understand it, setting the value at HKLM\System\CurrentControlSet\Enum\SCSI<device><instance>\Device Parameters\Partmgr to VDS_SP_OFFLINE is sufficient for this purpose (https://support.microsoft.com/en-us/help/2849097/how-to-set-the-partmgr-attributes-registry-value-using-powershell)

Our filter driver’s AddDevice() routine is going to check the target disk’s registry settings. If it sees that the disk in question is, indeed, reserved for our specific purpose, it is going to create, apart from the nameless device object that it attaches to the stack, its corresponding named standalone DO that is not a part of any stack. Once this DO is named, it is accessible to the “outside world”, but no one, apart from our above mentioned “owner” component, knows about it.

As a result, our above mentioned “owner” component is going to be be, for all practical purposes, the exclusive “owner” of the target disk, which, due to its VDS_SP_OFFLINE registry setting, is going to be hidden from the rest of the world by Partmgr.sys. However, once our “owner” component happens to be aware of the named DO, it is in a position to directly send its requests to our filter,effectively bypassing Partmgr.sys. In order to do so, all that it has to do is to send a request to the named DO, which, in turn, is going to send its requests to Disk.sys down its corresponding filter DO’s stack. Simple, ugh…

Otherwise, if AddDevice() routine finds out that the disk is question is not reserved for us, our filter driver is going to act just as a do-nothing pass-through filter that is devoid of any functionality and, by virtue of being a filter, is inaccessible to anyone, apart from its immediate neighbour above on the stack (because we are not going to create its corresponding standalone DO in this case ).

I just wonder if there may be any potential issues with this approach. To be honest, up to this point I don’t see any - once the target disk is hidden from the rest of the world by Partmgr.sys we are not going to get into any conflict with anyone, so that we are in a position to safely do what we want with it. What do you think, guys?

Anton Bassov

(MY you’ve gotten remarkably civil, thoughtful, and intelligent in the past week or two Mr Bassov… if it’s a new medicine or something, I say “stay with it!”)

So, you want to be able to write to this disk directly… using byte addressing but in sector modulus operations, and without a file system, yes? So, you WANT all the goodness of disk.sys, but nothing more?

A couple of thoughts:

  • Why not let the OS do its thing, and use unformatted drives via the raw file system?

  • You know, architecturally, there’s no way to say you want to be “above disk but below partmgr”… sure, the order of the Upper Filters key determines this, but that’s by implementation not by architecture.

  • Storage spaces presents a potential complicating factor, I think. He creates synthetic “disks” which are then claimed by disk. I dunno… maybe this is a good thing?

Aside from those few things, and the obvious fact that you’re going to be the one responsible for all the manual operations that the file system and MM might otherwise do (trim, flush) … that’s all I can think of.

Peter

(MY you’ve gotten remarkably civil, thoughtful, and intelligent in the past week or two Mr Bassov… if it’s a new medicine
or something, I say “stay with it!”)

Actually, there are 2 reasons for it:

  1. I had a temerity to use up my “lucky coin” that I had been earlier granted by “The Hanging Judge”, a couple of weeks ago
  2. On exactly the same “unlucky day” I had learned that “The Hanging Judge”'s clarity of judgment and impartiality of his verdict may be directly affected by the factors ranging from the quantity and type of food and beverages that he had consumed on any particular “judgment day” to neurotoxicity of the fumes that his dog produces upon any particular “discharge”, as well as precise timing and frequency of these “discharges”.

Taking into consideration the above and combining it with the “scary potential” of the new hosting platform, I think it is needless to say that I have to be really careful now.

In any case, it does not really matter in this context - once in this particular case it happens to be me who asks for help, I have to be polite and respectful no matter what and no matter how. Therefore, in this particular case I would be nice even if factors (1) and(2) did not apply.

Now let’s proceed to the technical side - it seems to be much more interesting than “trading barbs”, don’t you think…

Why not let the OS do its thing, and use unformatted drives via the raw file system?

Well, if you allow the volume with its corresponding drive letter to be mounted on the disk you already cannot claim the sole ownership of the target disk, can you. However, “the sole ownership” requirement is very important for this particular project. Therefore, the raw file system is not an option here…

You know, architecturally, there’s no way to say you want to be “above disk but below partmgr”… sure, the order of the
Upper Filters key determines this, but that’s by implementation not by architecture.

Please note that we are speaking about two drivers with a very well-defined PnP relationship to one another, with Disk.sys creating PDOs that Partmgr.sys attaches its FDOs to. Therefore, if your INF specifies that you want to be a lower filter for Partmgr.sys, the OS will ensure that you are below the FDO that Partmgr.sys creates, i.e. you will sit somewhere in between PDO and FDO that are created by respectively Disk.sys and Partmgr.sys. Am I wrong?

Storage spaces presents a potential complicating factor, I think. He creates synthetic “disks” which are then claimed by disk.
I dunno… maybe this is a good thing?

It is understandable that the disk may be set to offline mode for the multiple reasons and reserved by the various services like
Hyper-V,Windows Clustering, Storage Spaces, etc. However, unless the target disk happens to be SPECIFICALLY reserved for our purposes, our filter driver is not going to find all the registry settings and entries that are required for “claiming the sole ownership” (i.e. creating named control DOs). In such case it is going to act just as a do-nothing pass-through filter. Therefore, assuming the properly configured system, I don’t see any problem here whatsoever.

The only potential problem that I can see is an idiot Admin who assigns exactly the same disk “for the sole ownership” by the multiple services at once. If people hate their own data…well, there is no that much that can be done here anyway, don’t you think

Aside from those few things, and the obvious fact that you’re going to be the one responsible for all the manual operations that
the file system and MM might otherwise do (trim, flush) …

Sure…

What I am doing right now is just a feasibility study. The project in question is HUGE, and involves, at my current estimation, AT LEAST
5 Windows drivers, with FSD being just one of them (this is apart from the custom special-purpose OS kernel running as a guest inside Hyper-V). I hope by now you already understand why “the sole ownership” of certain disks is just a vital requirement here

Therefore, right now I am just considering the various possibilities at the architectural level, and evaluating the potential issues that may arise.

that’s all I can think of

I find it really encouraging - judging from your reply, the suggested approach does not seem that bad. However, let’s wait and see what the other guys say - I would like to hear as many “negative” comments as possible so that I can learn about all the potential issues and caveats that I may be unaware of…

Anton Bassov

Therefore, if your INF specifies that you want to be a lower filter for Partmgr.sys, the OS will ensure that you are below the FDO that Partmgr.sys creates, i.e. you will sit somewhere in between PDO and FDO that are created by respectively Disk.sys and Partmgr.sys. Am I wrong?

That is not correct. PartMgr is an upper filter of Disk, hence no architectural way to get yourself between Disk and PartMgr.

Any reason to not just mark the disk as hidden with IOCTL_DISK_SET_DISK_ATTRIBUTES? That disables the disk’s device interface so no one else can find it through PnP. For reference, this is what Storage Spaces does when you assign a disk to a pool.

If you also mark it offline then the partition PDOs are deleted as well, so no one is going to try to make a volume out of the disk either.

-scott

Any reason to not just mark the disk as hidden with IOCTL_DISK_SET_DISK_ATTRIBUTES? That disables the disk’s device interface
so no one else can find it through PnP. For reference, this is what Storage Spaces does when you assign a disk to a pool.

Thank you so much for your suggestion, Scott!! This one seems to be, indeed, promising. If I got it right, I have to specify DISK_ATTRIBUTE_OFFLINE with this IOCTL.
https://docs.microsoft.com/en-us/windows/desktop/api/winioctl/ns-winioctl-_set_disk_attributes

However, the question is “How can my KM component make any use of it if the disk’s device interface gets disabled”. I am going to investigate this issue further and post an update. Thank you so much!!!

PartMgr is an upper filter of Disk, hence no architectural way to get yourself between Disk and PartMgr.

Actually, I got it from the “Windows Internals,6th Edition” (Chapter 9, page 138)

[begin quote]

The partition manager, %SystemRoot%\System32\Drivers\Partmgr.sys, is responsible for discovering,
creating, deleting, and managing partitions. To become aware of partitions, the partition manager
acts as the function driver for disk device objects created by disk class drivers.

[end quote]

The very first thing that gets into my head is that Partmgr.sys may be presenting itself as a filter driver from PnP’s perspective. while acting as a function one in terms of its actual functionality

Anton Bassov

However, the question is “How can my KM component make any use of it if the disk’s device interface gets disabled”.

The hidden setting does not persist across reboots. The idea is once you discover during boot that the disk is yours you can mark it hidden.

the partition manager acts as the function driver for disk device objects created by disk class drivers.

I must say I don’t really love that description…PartMgr is a filter/bus driver, Disk is a function driver. But, whatever, as none of this matters if you go the hidden disk route.

The hidden setting does not persist across reboots. The idea is once you discover during boot that the disk is yours you can mark it hidden.

Thank you so much, Scott!!!

What I am trying to understand is how the whole thing actually works…

Let’s consider the following scenario. Let’s say some app or driver decides to send IOCTL_DISK_SET_DISK_ATTRIBUTES with DISK_ATTRIBUTE_OFFLINE attribute to /Device/HarddiskX PDO after the volumes and filesystems have been already mounted on its partitions. For the sake of the simplicity, let’s assume that the target disk has only one partition on it.

In my current understanding, more or less the following schematic sequence must be taking place

  1. Upon the receipt of this IOCTL, Disk.sys sends a a request to the top of /Device/HarddiskX 's device stack (i.e. the one that Partmgr.sys attaches its FDO to)
  2. When the request reaches Partmrg.sys, it calls IoInvalidateDeviceRelations() with DEVICE_OBJECT that corresponds to the partition on the target disk( i.e. /Device/HarddiskX /Partition0’s PDO) .
  3. In response to the above,PnP Manager triggers a PnP sequence that eventually unmounts the FS and volume that are mounted on the target partition, effectively ensuring that the partition in question is not used by anyone
  4. From now on the device that corresponds to the partition ( i.e. /Device/HarddiskX /Partition0) becomes, for all practical purposes,
    sort of no-existent - although it is still there, all the subsequent requests to it are completed with STATUS_NO_SUCH_DEVICE status by Partmgr.sys, so that it becomes inaccessible. Furthermore, once it is still there, no subsequent attempts to mount a volume on the target partition will be made until the reboot

To summarise, /Device/HarddiskX /Partition0 becomes inaccessible until the reboot, but /Device/HarddiskX is still available for use. If there were the additional partitions on the target disk, steps (2) to (4) would be repeated for them all.

Is my understanding correct? This is what my “How can my KM component make any use of it if the disk’s device interface gets disabled” question refers to - after all, my “special component” has to access the disk somehow…

Anton Bassov

To summarise, /Device/HarddiskX /Partition0 becomes inaccessible until the reboot, but /Device/HarddiskX is still available for use. If there were the additional partitions on the target disk, steps (2) to (4) would be repeated for them all.

Yes, I would say that summarizes the behavior.

This is what my “How can my KM component make any use of it if the disk’s device interface gets disabled” question refers to - after all, my “special component” has to access the disk somehow…

Sorry, not sure I understand the conclusion. The result is what you describe above: the partition devices are gone but that the disk remains accessible. You can’t discover the disk device via PnP anymore, but if you previously discovered the disk device through PnP and opened it you can continue to access it.

You can prototype this entirely in user mode with a small test utility to better categorize the behavior if you like. Once you mark the disk offline you’ll see any corresponding volumes disappear. If you then mark the disk as hidden you’ll also see the disk disappear (e.g. from DIsk Management). However, your application will still be able to talk to the disk using the opened HANDLE.

Sorry, not sure I understand the conclusion. The result is what you describe above: the partition devices are gone but that the
disk remains accessible. You can’t discover the disk device via PnP anymore, but if you previously discovered the disk
device through PnP and opened it you can continue to access it.

Well, I just was not sure if the end result that I was suggesting was correct. My main concern at the time was whether I could hide the disk after a volume had already been mounted on it, while still being in a position to use the disk device . Now I know that the whole thing is just straightforward.

Thank you so much for your suggestion, Scott!!!

Anton Bassov