MiniFilter driver cache faster.

Hi all,
I am working on an encryption mini-filter driver, where encryption happens during pagingIO only , the cache contains plain data.
In some performance testing I found that cached write to Filter driver cache is Faster than without having any filter driver.
I am trying to understand Why NTFS fsd cache write is slower that Filter driver cache write.
Please help me to understand the behaviour.

Thanks in advance,
Maneesh

Is your filter driver integrating with CM/MM, meaning do you all
CcCopyRead/Write() from your filter?

How are you determining the performance?

Pete

On 11/10/2014 11:10 AM, xxxxx@gmail.com wrote:

Hi all,
I am working on an encryption mini-filter driver, where encryption happens during pagingIO only , the cache contains plain data.
In some performance testing I found that cached write to Filter driver cache is Faster than without having any filter driver.
I am trying to understand Why NTFS fsd cache write is slower that Filter driver cache write.
Please help me to understand the behaviour.

Thanks in advance,
Maneesh


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Yes. It does call CcCopyRead/Write()
also support ccMDL read/Write. as appropriate.

Test utility is iozone fileop test program
That uses the Unix like Open/close/Read/Write calls using Cygwin on windows.
The performance of each operation is measured by taking timestamp difference between before and after each operations.

test run is with filter driver and Without any filter driver.
is there any difference to the approach with FSD and Filter driver with respect to cached reads.

There are lots of differences including locking but I would think the
big impact, at least during the initial phases of the test and depending
on how big your data set is, for latter portions would be how you are
getting data from the underlying disk to satisfy the in-page operations
to the system cache. Are you seeing a difference in 100’s of IOPS per
second? Are you rebooting between test runs? NTFS is a big file system
but I wouldn’t expect there to be a huge difference in read processing
unless you are somehow increasing the performance of the in-page processing.

Pete

On 11/11/2014 5:20 AM, xxxxx@gmail.com wrote:

Yes. It does call CcCopyRead/Write()
also support ccMDL read/Write. as appropriate.

Test utility is iozone fileop test program
That uses the Unix like Open/close/Read/Write calls using Cygwin on windows.
The performance of each operation is measured by taking timestamp difference between before and after each operations.

test run is with filter driver and Without any filter driver.
is there any difference to the approach with FSD and Filter driver with respect to cached reads.


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Thank you Peter for your time and patience to listen my problem.
My concern is more with Write call only.
To add mode details from the Test.
every time new file created and write file called and close handle.
Timestamps is taken before and after every operations.
test repeated for 8000 different and distinct files with 25k size.
Average is calculated in terms of Operations per second.

For My filter driver Write would be calling CcCopyWrite along with some
size expansions and locking FCB for CC write.
For write, Paging would take place but will not block Write function return
and calculating time stamp etc.

On Tue, Nov 11, 2014 at 10:01 PM, Peter Scott
wrote:

>
> There are lots of differences including locking but I would think the big
> impact, at least during the initial phases of the test and depending on how
> big your data set is, for latter portions would be how you are getting data
> from the underlying disk to satisfy the in-page operations to the system
> cache. Are you seeing a difference in 100’s of IOPS per second? Are you
> rebooting between test runs? NTFS is a big file system but I wouldn’t
> expect there to be a huge difference in read processing unless you are
> somehow increasing the performance of the in-page processing.
>
> Pete
>
>
> On 11/11/2014 5:20 AM, xxxxx@gmail.com wrote:
>
>> Yes. It does call CcCopyRead/Write()
>> also support ccMDL read/Write. as appropriate.
>>
>>
>> Test utility is iozone fileop test program
>> That uses the Unix like Open/close/Read/Write calls using Cygwin on
>> windows.
>> The performance of each operation is measured by taking timestamp
>> difference between before and after each operations.
>>
>> test run is with filter driver and Without any filter driver.
>> is there any difference to the approach with FSD and Filter driver with
>> respect to cached reads.
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>


मनीष आनंद सामरिया
Maneesh Anand.Samria

So are you saying that for the paging write, you do not send it to the
lower file system but instead complete it within your filter driver?

Pete

On 11/11/2014 10:57 AM, Maneesh Anand Samria wrote:

Thank you Peter for your time and patience to listen my problem.
My concern is more with Write call only.
To add mode details from the Test.
every time new file created and write file called and close handle.
Timestamps is taken before and after every operations.
test repeated for 8000 different and distinct files with 25k size.
Average is calculated in terms of Operations per second.

For My filter driver Write would be calling CcCopyWrite along with
some size expansions and locking FCB for CC write.
For write, Paging would take place but will not block Write function
return and calculating time stamp etc.

On Tue, Nov 11, 2014 at 10:01 PM, Peter Scott
> wrote:
>
>
> There are lots of differences including locking but I would think
> the big impact, at least during the initial phases of the test and
> depending on how big your data set is, for latter portions would
> be how you are getting data from the underlying disk to satisfy
> the in-page operations to the system cache. Are you seeing a
> difference in 100’s of IOPS per second? Are you rebooting between
> test runs? NTFS is a big file system but I wouldn’t expect there
> to be a huge difference in read processing unless you are somehow
> increasing the performance of the in-page processing.
>
> Pete
>
>
> On 11/11/2014 5:20 AM, xxxxx@gmail.com mailto:xxxxx
> wrote:
>
> Yes. It does call CcCopyRead/Write()
> also support ccMDL read/Write. as appropriate.
>
>
> Test utility is iozone fileop test program
> That uses the Unix like Open/close/Read/Write calls using
> Cygwin on windows.
> The performance of each operation is measured by taking
> timestamp difference between before and after each operations.
>
> test run is with filter driver and Without any filter driver.
> is there any difference to the approach with FSD and Filter
> driver with respect to cached reads.
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com http:
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>
>
>
>
> –
> मनीष आनंद सामरिया
> Maneesh Anand.Samria
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file
> system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295</http:></mailto:xxxxx>

Sorry for confusion .
Paging write is sent to lower file system but it doesn’t block the thread
that called cached write. it works in background rt?
there-fore that cost (of paging write or cache flush) doesn’t add to cost
of Write function at user application.
its designed similar to FastFat sample.

On Tue, Nov 11, 2014 at 11:32 PM, Peter Scott
wrote:

>
> So are you saying that for the paging write, you do not send it to the
> lower file system but instead complete it within your filter driver?
>
> Pete
>
>
> On 11/11/2014 10:57 AM, Maneesh Anand Samria wrote:
>
> Thank you Peter for your time and patience to listen my problem.
> My concern is more with Write call only.
> To add mode details from the Test.
> every time new file created and write file called and close handle.
> Timestamps is taken before and after every operations.
> test repeated for 8000 different and distinct files with 25k size.
> Average is calculated in terms of Operations per second.
>
> For My filter driver Write would be calling CcCopyWrite along with some
> size expansions and locking FCB for CC write.
> For write, Paging would take place but will not block Write function
> return and calculating time stamp etc.
>
>
>
>
> On Tue, Nov 11, 2014 at 10:01 PM, Peter Scott
> wrote:
>
>>
>> There are lots of differences including locking but I would think the big
>> impact, at least during the initial phases of the test and depending on how
>> big your data set is, for latter portions would be how you are getting data
>> from the underlying disk to satisfy the in-page operations to the system
>> cache. Are you seeing a difference in 100’s of IOPS per second? Are you
>> rebooting between test runs? NTFS is a big file system but I wouldn’t
>> expect there to be a huge difference in read processing unless you are
>> somehow increasing the performance of the in-page processing.
>>
>> Pete
>>
>>
>> On 11/11/2014 5:20 AM, xxxxx@gmail.com wrote:
>>
>>> Yes. It does call CcCopyRead/Write()
>>> also support ccMDL read/Write. as appropriate.
>>>
>>>
>>> Test utility is iozone fileop test program
>>> That uses the Unix like Open/close/Read/Write calls using Cygwin on
>>> windows.
>>> The performance of each operation is measured by taking timestamp
>>> difference between before and after each operations.
>>>
>>> test run is with filter driver and Without any filter driver.
>>> is there any difference to the approach with FSD and Filter driver with
>>> respect to cached reads.
>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> OSR is hiring!! Info at http://www.osr.com/careers
>>>
>>> For our schedule of debugging and file system 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
>>>
>>
>> –
>> Kernel Drivers
>> Windows File System and Device Driver Consulting
>> www.KernelDrivers.com
>> 866.263.9295
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>
>
>
> –
> मनीष आनंद सामरिया
> Maneesh Anand.Samria
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> 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
>
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consultingwww.KernelDrivers.com
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>


मनीष आनंद सामरिया
Maneesh Anand.Samria

It depends, if the file was opened for write-through then yes, the
paging write will block. Is it possible you are performing cached IO
even though the caller is requesting non-cached IO?

You are somehow effecting the IO pathways to make the calls with your
filter ‘faster’ than without.

Pete

On 11/11/2014 9:02 PM, Maneesh Anand Samria wrote:

Sorry for confusion .
Paging write is sent to lower file system but it doesn’t block the
thread that called cached write. it works in background rt?
there-fore that cost (of paging write or cache flush) doesn’t add to
cost of Write function at user application.
its designed similar to FastFat sample.

On Tue, Nov 11, 2014 at 11:32 PM, Peter Scott
> wrote:
>
>
> So are you saying that for the paging write, you do not send it to
> the lower file system but instead complete it within your filter
> driver?
>
> Pete
>
>
> On 11/11/2014 10:57 AM, Maneesh Anand Samria wrote:
>> Thank you Peter for your time and patience to listen my problem.
>> My concern is more with Write call only.
>> To add mode details from the Test.
>> every time new file created and write file called and close handle.
>> Timestamps is taken before and after every operations.
>> test repeated for 8000 different and distinct files with 25k size.
>> Average is calculated in terms of Operations per second.
>>
>> For My filter driver Write would be calling CcCopyWrite along
>> with some size expansions and locking FCB for CC write.
>> For write, Paging would take place but will not block Write
>> function return and calculating time stamp etc.
>>
>>
>>
>>
>> On Tue, Nov 11, 2014 at 10:01 PM, Peter Scott
>> > wrote:
>>
>>
>> There are lots of differences including locking but I would
>> think the big impact, at least during the initial phases of
>> the test and depending on how big your data set is, for
>> latter portions would be how you are getting data from the
>> underlying disk to satisfy the in-page operations to the
>> system cache. Are you seeing a difference in 100’s of IOPS
>> per second? Are you rebooting between test runs? NTFS is a
>> big file system but I wouldn’t expect there to be a huge
>> difference in read processing unless you are somehow
>> increasing the performance of the in-page processing.
>>
>> Pete
>>
>>
>> On 11/11/2014 5:20 AM, xxxxx@gmail.com
>> mailto:xxxxx wrote:
>>
>> Yes. It does call CcCopyRead/Write()
>> also support ccMDL read/Write. as appropriate.
>>
>>
>> Test utility is iozone fileop test program
>> That uses the Unix like Open/close/Read/Write calls
>> using Cygwin on windows.
>> The performance of each operation is measured by taking
>> timestamp difference between before and after each
>> operations.
>>
>> test run is with filter driver and Without any filter driver.
>> is there any difference to the approach with FSD and
>> Filter driver with respect to cached reads.
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>>
>> –
>> Kernel Drivers
>> Windows File System and Device Driver Consulting
>> www.KernelDrivers.com http:
>> 866.263.9295
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>>
>>
>>
>> –
>> मनीष आनंद सामरिया
>> Maneesh Anand.Samria
>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>> http://www.osr.com/careers For our schedule of debugging and file
>> system 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
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com http:
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>
>
>
>
> –
> मनीष आनंद सामरिया
> Maneesh Anand.Samria
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file
> system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295</http:></http:></mailto:xxxxx>

Sorry for delayed reply …

On Wed, Nov 12, 2014 at 7:57 PM, Peter Scott
wrote:

>
> It depends, if the file was opened for write-through then yes, the paging
> write will block.
>
Its not write through , it is a typical cached write implemented using
CCCopyWrite , paging write will happen when cache is flushed

> Is it possible you are performing cached IO even though the caller is
> requesting non-cached IO?
>
> No , I double checked it , its honouring the flags properly.

You are somehow effecting the IO pathways to make the calls with your
> filter ‘faster’ than without.
>
> Pete
>

Not yet understand the cause of this being ‘Faster’, any lock or resource
for which, it is supposed to wait but not waiting.

Btw Thank you Pete for your time and help.
Regards,
Maneesh Anand