When an application calls MapViewOfSection; is it possible for MM to bypass FS stack completely and read data directly from cache (assuming data is already there in cache).
From what I observed it looks to be THE case; and hence not even a cached read will be generated. Can there be any variance in this behavior?
Thanks
Aditya
To add what I am experimenting with:
Consider a container file (like ISO), now with a ISO litrate filter driver I can satisfy create & read on files inside ISO.
So for example if there is a file 1.exe inside container file at offset 10000, so I can simply do this calculation in create (for 1.exe), change it for the ISO file and pass it down.
Modify the offset in *cached* read. and things work fine for normal readfile calls. In fact it works on MapViewOfFile too if data is not cached.
BUT when it is cached MM does not ask FS stack, and hence byte offset in not manipulated, so obviously the caller will get unexpected data and things will fail.
Now my first question is, the behavior I stated is correct? Can there be any differences in it?
On 1/25/2011 3:01 AM, xxxxx@gmail.com wrote:
When an application calls MapViewOfSection; is it possible for MM to bypass FS stack completely and read data directly from cache (assuming data is already there in cache).
From what I observed it looks to be THE case; and hence not even a cached read will be generated. Can there be any variance in this behavior?
If the data is already in the system cache then a section has already
been allocated for the file. Hence when a user maps a view, the system
will use the same section and since the data is there, no reads will be
issued for the data.
Pete
Thanks
Aditya
NTFSD is sponsored by OSR
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
> When an application calls MapViewOfSection; is it possible for MM to bypass FS stack completely
and read data directly from cache (assuming data is already there in cache).
Surely yes.
But no guarantees though.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Instead, modify the offset in noncached reads, including paging ones.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> To add what I am experimenting with:
>
> Consider a container file (like ISO), now with a ISO litrate filter driver I can satisfy create & read on files inside ISO.
>
> So for example if there is a file 1.exe inside container file at offset 10000, so I can simply do this calculation in create (for 1.exe), change it for the ISO file and pass it down.
>
> Modify the offset in cached read. and things work fine for normal readfile calls. In fact it works on MapViewOfFile too if data is not cached.
>
> BUT when it is cached MM does not ask FS stack, and hence byte offset in not manipulated, so obviously the caller will get unexpected data and things will fail.
>
> Now my first question is, the behavior I stated is correct? Can there be any differences in it?
>
Thanks you for your time,
>Instead, modify the offset in noncached reads, including paging ones.
I do not think this will help me considering big picture. lets say there are two files inside ISO,
offset 1000 -> 1.txt & offset 2000 -> 2.txt
cahced read of 1.txt come for byte 0, let it go,
paged read for 1.txt will come for byte 0, adjust the offset to 0x1000
cahced read for 2.txt will come for byte 0, let it go
FS will check if this range is cached, and it will find that yes it is (the file object refers to same ISO file in both case)
So it will simply read data 1.txt data from cache and return it for 2.txt.
Isn’t it?
I think this is proper candidate for layered FSD. What do you guys think?
On 1/26/2011 9:37 AM, xxxxx@gmail.com wrote:
FS will check if this range is cached, and it will find that yes it is (the file object refers to same ISO file in both case)
So it will simply read data 1.txt data from cache and return it for 2.txt.
One option is to take over caching for these entries as well as create
processing to establish your own SOP structure with each file object.
I’ve implemented several file system container designs and going this
route is a ton of work but results in the cleanest implementation.
Isn’t it?
I think this is proper candidate for layered FSD. What do you guys think?
Right, layered FSD where you own each file object for 1.txt and 2.txt.
Pete
NTFSD is sponsored by OSR
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