Hi All,
I have a upper volume filter driver to capture the write changes of the volume and create a bitmap out of it. The bitmap is used to track the block changes for
incremental. It is working fine in the lab, but in the some remote installations, the incremental chages when restored is giving CHKDSk errors. After digging deep
i came to know I have not handled the following IOCTL_DISK_COPY_DATA,FSCTL_MOVE_FILE,IRP_MJ_FILESYSTEM_CONTROL.
Could the above be the reason for the CHKDSK error and what are the implications of not handling the above IOCTL. Also for tracking block changes properly, is there
any other IOCTL or IRP’s I need to handle from the driver.
Thanks in Advance 
Mani,
this is a complex driver to get right, there are a lot of gotchas and
hidden secrets, there are also a lot of rules to be followed to co exist
with other components. I am not discouraging you, only letting you know
what all you should expect.
Now, I don’t know your particular implementation of this CBT (change block
tracking) driver, but when we developed it, we did have to handle
IOCTL_DISK_COPY_DATA.
Chkdsk errors can be caused by a multitude of problems in the driver, one
simple way to check whether *not* handling IOCTL_DISK_COPY_DATA is indeed
the cause of your particular failure, would be to handle this IOCTL and
fail it in your driver. This is make the Defrag application to perform
Defrag with more primitive operations like READ and WRITE.
Let us know the results of your experiments, so that we can try to help you
further with the debugging…
On Wed, May 22, 2013 at 5:23 PM, wrote:
> Hi All,
>
> I have a upper volume filter driver to capture the write changes of the
> volume and create a bitmap out of it. The bitmap is used to track the block
> changes for
> incremental. It is working fine in the lab, but in the some remote
> installations, the incremental chages when restored is giving CHKDSk
> errors. After digging deep
> i came to know I have not handled the following
> IOCTL_DISK_COPY_DATA,FSCTL_MOVE_FILE,IRP_MJ_FILESYSTEM_CONTROL.
>
> Could the above be the reason for the CHKDSK error and what are the
> implications of not handling the above IOCTL. Also for tracking block
> changes properly, is there
> any other IOCTL or IRP’s I need to handle from the driver.
>
> Thanks in Advance
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
- ab
whether this IOCTL have to be handled also IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES.
Thanks for the Reply
That IOCTL is the only published IOCTL of volsnap. It depends on what you
are doing, I have seen CBT upper filters being designed completely ignoring
this IOCTL, and I have seen others honouring its presence and taking action.
Both designs have proven to be working.
On Wed, May 22, 2013 at 7:48 PM, wrote:
> whether this IOCTL have to be handled also
> IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES.
>
> Thanks for the Reply
>
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
- ab
The IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES won’t actually generate any
additional writes that you have to care about as an upper filter. But if
Volsnap is configured in persistent snapshot mode with diff area files on
your volume that you are trying to track, then volsnap will generate it’s
own IRPs that only lower volume filters will see. Also, do you care about
writes going via scsi pass through ioctls (
http://msdn.microsoft.com/en-us/library/windows/hardware/ff560519(v=vs.85).aspx
)?
On Wed, May 22, 2013 at 9:39 AM, A B wrote:
> That IOCTL is the only published IOCTL of volsnap. It depends on what you
> are doing, I have seen CBT upper filters being designed completely ignoring
> this IOCTL, and I have seen others honouring its presence and taking action.
>
> Both designs have proven to be working.
>
>
> On Wed, May 22, 2013 at 7:48 PM, wrote:
>
>> whether this IOCTL have to be handled also
>> IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES.
>>
>> Thanks for the Reply
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
>
>
> –
>
> - ab
> — NTDEV is sponsored by OSR OSR is HIRING!! See
> http://www.osr.com/careers 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
>