Hello
I am trying to convert 2 logical drive into one, if it is possible to make filter driver(FD) for Volume Manager(VM). (or the best driver to fit in)
Assuming I have Drive X and Drive Y then I want to make it just a drive Z visible to the volume manager.
Main purpose of the FD is to reroute the IO operations to Drive Y if ever Driver X will Fail.
Drive X is the Primary and the Driver is the Secondary. Secondary drive is the back up(Mirror) of the primary.
We just also want to hide the Drive Y to the Volume manager.
base on the Device Stack below:
I/O Subsystem
File System
Volume Snapshot
Volume Manager
Partition Manager
Class
Port | Miniport
Disk Subsystem
?s
- Converting of 2 logical drive as 1 in Volume Manager possible?
2.Where do the best place of my FD to make it into 1 logical drive?
- Does Microsoft Allow this kind of filter driver?
- Does this community accepts MPIO Inquiries?
4.1. We are implementing MPIO from multiple devices via FC, does making of 2 logical
drive into one possible in MPIO DSM?
xxxxx@gmail.com wrote:
Hello
I am trying to convert 2 logical drive into one, if it is possible to make filter driver(FD) for Volume Manager(VM). (or the best driver to fit in)
Assuming I have Drive X and Drive Y then I want to make it just a drive Z visible to the volume manager.
Main purpose of the FD is to reroute the IO operations to Drive Y if ever Driver X will Fail.
Drive X is the Primary and the Driver is the Secondary. Secondary drive is the back up(Mirror) of the primary.
We just also want to hide the Drive Y to the Volume manager.
What you want to accomplish can be done but not at the file system
filter driver level, which is what this list is for. You should send
this post to the NTDev list where you will have more feedback.
In general, this is going to be quite a bit of work. We have done this
implementation in the FC environment and it took quite a bit of design
and work.
To answer your questions:
- Converting of 2 logical drive as 1 in Volume Manager possible?
You will need to filter the volumes and you will need to process
requests to each of the drives, create a single upper device and report
it as the single volume. Basically hiding the two underlying volumes
from the system.
2.Where do the best place of my FD to make it into 1 logical drive?
You will create a volume filter driver which will filter the volumes you
want to combine, hiding them from the system, and then create a single
instance to handle all the requests as if it were a single volume.
- Does Microsoft Allow this kind of filter driver?
Yes
- Does this community accepts MPIO Inquiries?
Yes, well more on the NTDev list.
4.1. We are implementing MPIO from multiple devices via FC, does making of 2 logical
drive into one possible in MPIO DSM?
You can do it, lots of work but possible.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Thank you very much for that helpful information, Mr Pete…
I am going to start making a filter driver for this…
Can anyone give me a hint or a link where can i start making this filter driver…?
Is there a sample filter driver nearest to this kind of situation?
From the storage stack, where do I can possibly insert my volume filter driver to make that 2 drives into 1? Is it a filter below volume manager? or is it a upper volume filter driver…
xxxxx@gmail.com wrote:
Thank you very much for that helpful information, Mr Pete…
I am going to start making a filter driver for this…
Can anyone give me a hint or a link where can i start making this filter driver…?
Is there a sample filter driver nearest to this kind of situation?
From the storage stack, where do I can possibly insert my volume filter driver to make that 2 drives into 1? Is it a filter below volume manager? or is it a upper volume filter driver…
You can get an upper volume filter started by checking out the DiskPerf
sample in the WDK. I would recommend starting there to get the framework
of the volume filter in place.
As for something near to the situation you are trying to implement, you
probably won’t find anything, at least not for free. You are talking 3-4
months of effort if you know how to start the design, probably another
2-3 months to figure out where to start if you don’t know. And this does
not include the MPIO stuff. I’d start pinging Microsoft to get the MPIO
documentation since that will take some time. Of course you could build
it without the Microsoft stuff but it will take longer.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
That would be a good start…
Thank you for that Mr. Pete…
Its a bit long journey for me…
Previously i had tried the maintenance for the mouse filter driver…
It is a bit different, but a good experience to begin for the next driver development…
Now I am trying to understand the file system or storage related drivers…
maybe i ask some questions sometimes…later…
Hello
Even though it needs a lot of work…
In making 2 volumes into 1, is working with MPIO DSM more complicated compare to the making of upper volume filter?
or which do you think is less hastle for a beginner…
btw, we are now working with MPIO DSM to monitor and implement multipathing, load balancing,
path management, et cetera.
Do you think, it is a good idea to just integrate the combining of two volume to make it One in DSM?
Do you think this can affect the performance of the MPIO?
for safety, which of the two would be the best way of making 2 volume into 1?
Normally I wouldn’t pick you up on loose terminology, but it’s quite
critical in this case.
Are you really working with volumes or are you working with disks
? The difference for where and how a solution is implemented
requires a proper understanding of the differences between the two.
For instance, MPIO works on disks and only disks, it is installed at
a very low level in the storage stack. Volumes are comparatively
high in the storage stack.
You need to think about this and re-word your questions more
precisely to get proper advice.
Also, this thread would be better off on ntdev.
Mark.
At 08:17 11/06/2009, xxxxx@gmail.com wrote:
Hello
Even though it needs a lot of work…
In making 2 volumes into 1, is working with MPIO DSM more
complicated compare to the making of upper volume filter?
or which do you think is less hastle for a beginner…
btw, we are now working with MPIO DSM to monitor and implement
multipathing, load balancing,
path management, et cetera.
Do you think, it is a good idea to just integrate the combining of
two volume to make it One in DSM?
Do you think this can affect the performance of the MPIO?
for safety, which of the two would be the best way of making 2
volume into 1?
NTFSD is sponsored by OSR
I am very sorry for the loose terminology…
moushiwakegozaimasen…
What i mean is disks…
Then MPIO is the way to do this and a DSM is a lot less work than a
disk or volume filter higher up the stack.
Mark.
At 09:50 11/06/2009, xxxxx@gmail.com wrote:
I am very sorry for the loose terminology…
moushiwakegozaimasen…
What i mean is disks…
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Mark S. Edwards wrote:
Then MPIO is the way to do this and a DSM is a lot less work than a disk
or volume filter higher up the stack.
In addition, you need to become a Microsoft MPIO partner, they release
source for the DSM under their agreement. At least they have in the
past. It would provide a good starting point for your implementation.
Pete
Mark.
At 09:50 11/06/2009, xxxxx@gmail.com wrote:
> I am very sorry for the loose terminology…
> moushiwakegozaimasen…
>
> What i mean is disks…
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Thanks a lot for that information,
we already obtain the MPIO from microsoft,
we trying to understand it now…
later on, maybe we’ll open some questions…
I have a little concern regarding the exported MPIO routines.
DsmpParseDeviceID - this routine returns the Device Identifier(saved as serialnumber in DSM)
//
// This will parse out the ‘best’ identifier and return
// a NULL-terminated ascii string.
//
the weird thing is: the original serial number of the device is 64bits: 50 00 BC 25 7F FF A0 00
but the returned string from DsmpParseDeviceID is : 50 0 BC 25 7F FF A0 0
this is a bug i think…00 was become 0…
FYI: we are using MPIO 1.17.xxxx we are not sure if this was already fix in 1.22 version of MPIO
Is MPIO really untouchable? uneditable?
In this case, Parsing of such string implementation must be open to us, I guess.
Next thing is
How do I refresh the device manager through commands or by calling an API…
Is there an API to refresh the device listed in the device manager?
Or another way of calling the PnP Manager that there is a new hardware changes?
because our scenario is that: there is a RAID connected to the host with only 2 LUNs, when I created a new LUN, the PnP Manager didnt notice that there is a new LUN, so we need to scan the hardware changes via device Manager window.
Any idea?