Dear All,
I have a question about data coherency, I learn that Isolation Filter have its own cache and its cache stay together with the system’s cache in the OS.
When a PagingIO(Write) occurerd towards a FileObject created by Isolation Filter and finished its operation, the Isolation Filter’s cache is correct, and obviously the cache owned by the System is out-of-date, how can I or my Isolation Filter tell the System that its cache is out-of-date, should I (or my Isolation Filter) call CcPurgeCacheSection towards FileObject created by System? I think it’s not a good way to call Cc* Functions towards FileObject created by System, but is there any other ways to do so?
I do need your help now…
> I learn that Isolation Filter have its own cache and its cache stay
together with the system’s cache in the OS.
Not the Isolate filter uses the system’s cache instead of the file system
using the system cache. The only reason to own the SOP (and hence use the
system cache is to allow you to call the cc Functions that a Filesystem
can).
When a PagingIO(Write) occurerd towards a FileObject created by Isolation
Filter and finished
its operation, the Isolation Filter’s cache is correct, and obviously the
cache owned by the
System is out-of-date,
No it isn’t. There is no distinction the isolation filters cache is the
system cache.
It might be out of date with respect to the file systems cache, but that is
why you are there to stop the file system from setting up a system cache.
If you need multiple viewss, set them up and own them both, then you can
manage them.
should I (or my Isolation Filter) call CcPurgeCacheSection towards
FileObject
Only on file objects in which FileObject->SectioObjectPointers points to
addresses that you maintain. If you don’t you will cause instabiliity and
you will deadlock the system.
Of course (as is the rule for all minifilters) it may appear to work, but it
won’t be stable. It may even get to the customers before you discover this.
I think it’s not a good way to call Cc* Functions towards FileObject
created by System
s/System/Underlying FSD/ but yes its very bad,
I do need your help now…
Never allow the filesystem to set up caching on the file. Intercept and
handle each and every file operation which may result in this happening.
Use multiple SOPs if you need to. Check constantly that the SOP for the
lower file object hasn’t been initialized.
Thanks, rod.
Your answer sure do me a great favor!
There is one thing I still not very clear:
If I created multiple SOPs in my Isolation Filter, I do could call Cc* Funtions towards any FileObject(on condition that my Isolation Filter maintains their SOPs), but the data cache coherency problem still exists, when and where should I tell some of the SOPs that their cached data is out-of-date? How could I tell them their cached data is out-of-date? CcFlushCache doesn’t make any sense, right? So it means I could only call CcPurgeCacheSection towards the out-of-date SOPs?
>operation, the Isolation Filter’s cache is correct, and obviously the cache owned by the System is
Just open all files in the FSD below you in noncached mode.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> If I created multiple SOPs in my Isolation Filter, I do could call Cc*
Funtions
towards any FileObject(on condition that my Isolation Filter maintains
their
SOPs), but the data cache coherency problem still exists, when and where
should I tell some of the SOPs that their cached data is out-of-date?
If in doubt, read the FAT code. The analog you need to think about here is
the non cached path. FAT accepting a non-cached write is sort of like you
accepting a cached write into another SOP. Equally for the read path.
There is one further twist. In nearly all cases you get warning that a
paging operation will happen so you can anticipate what to do. The twist is
pagefaults on a section. In that case you may need to react by flushing
another SOP and this can get very fraught.