Hello everybody,
I am going to start with storage stack. Hence, i need some advise.
Basically i need to take a backup of original contents of the disk block when it is getting modified and store it somewhere for later recovery. I have few questions:
- How to put a disk filter at a location where there is a concept of partitions?
- How to put a disk filter at a location where there is no concept of partition ( may be somewhere below mount manager concept)?
- Should i issue File writes to my backup file and handle the recursive I/O or should i allocate all space to my backup file in the beginning ( in a contiguous manner) and then use the sectors allocated to this file and issue writes to those sectors?
Thanks,
Tushar A.
Device objects for partitions are created by DISK.SYS, so that the concept of partitions applies only to those who are above DISK.SYS on the stack. Please note PartMgr.sys attaches itself to the disk, rather than partition, objects - device objects for partitions end up as standalone devices. Therefore, in order to filter a partition, you have to filter disk’s FDO, rather than attaching yourself to a partition object…
In other words, answers to your questions 1 and 2 stand as “write respectively upper or lower
filter for DISK’s FDO”.
In order to answer the third question, all I have to do is to remind you that you don’t know the locking model that FSD uses. Therefore, if FSD does disk IO and receives a recursive call, theoretically you may deadlock ( I already don’t mention the fact that all file IO can be done only at PASSIVE_LEVEL)
Anton Bassov
To further complicate matters, the op needs to decide what it is he is
‘copy on writing’: volume data, partition data, or disk data.
Replication can be done at any of these levels.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Tuesday, September 11, 2007 3:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Disk based copy on write
Device objects for partitions are created by DISK.SYS, so that the
concept of partitions applies only to those who are above DISK.SYS on
the stack. Please note PartMgr.sys attaches itself to the disk, rather
than partition, objects - device objects for partitions end up as
standalone devices. Therefore, in order to filter a partition, you have
to filter disk’s FDO, rather than attaching yourself to a partition
object…
In other words, answers to your questions 1 and 2 stand as “write
respectively upper or lower
filter for DISK’s FDO”.
In order to answer the third question, all I have to do is to remind you
that you don’t know the locking model that FSD uses. Therefore, if FSD
does disk IO and receives a recursive call, theoretically you may
deadlock ( I already don’t mention the fact that all file IO can be done
only at PASSIVE_LEVEL)
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars 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
Thank you for the replies.
Which is a better approach and way for “copy before writing”: volume data, partition data, or disk data?
What are the advantages/ limitations of using one over the others?
Thanks and regards,
Tushar A.
It can also be done at the file data level with a file system filter. The
disk level is the easiest.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
To further complicate matters, the op needs to decide what it is he is
‘copy on writing’: volume data, partition data, or disk data.
Replication can be done at any of these levels.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Tuesday, September 11, 2007 3:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Disk based copy on write
Device objects for partitions are created by DISK.SYS, so that the
concept of partitions applies only to those who are above DISK.SYS on
the stack. Please note PartMgr.sys attaches itself to the disk, rather
than partition, objects - device objects for partitions end up as
standalone devices. Therefore, in order to filter a partition, you have
to filter disk’s FDO, rather than attaching yourself to a partition
object…
In other words, answers to your questions 1 and 2 stand as “write
respectively upper or lower
filter for DISK’s FDO”.
In order to answer the third question, all I have to do is to remind you
that you don’t know the locking model that FSD uses. Therefore, if FSD
does disk IO and receives a recursive call, theoretically you may
deadlock ( I already don’t mention the fact that all file IO can be done
only at PASSIVE_LEVEL)
Anton Bassov
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars 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
I WANT to do it in the storage stack and not the File system stack.
In that case, which is a better approach and way for “copy before writing”: volume data,
partition data, or disk data?
What are the advantages/ limitations of using one over the others?
> To further complicate matters, the op needs to decide what it is he is
‘copy on writing’: volume data, partition data, or disk data.
Good observation, Mark…
Once FtDisk.sys communicates with PartMgr.sys via the propriatary interface, rather than by sending IRPs to it, attaching yourself above PartMrg.sys on the stack will, apparently, be not that much usefull for you if you want to filter a partition, although it will work just fine if you are interested in the raw disk( i.e. you want to filter the requests to the device opened in the form \.\PhysicalDriveX). If you want to filter a volume … well, this is a totally different stack that has nothing to do with the physical storage - then you have to filter requests to FtDisk.sys, rather than to DISK.SYS (I assume a basic, rather than dynamic, disk)
Anton Bassov