Coherency of mmap and noncached writes

I remember that in the FSDs it was once a usual practice:

  • if a cache map exists for an FCB, then any noncached writes to this FCB are executed as cached write+flush.

Thus the coherency of in-memory file pages and the on-disk data is maintained.

Now imagine that there is no cache map (the FCB was never open cached), but there are mapped views.

Then the noncached write arrives.

Will the in-memory pages be updated (or flushed and discarded) with the data from the noncached write?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> Will the in-memory pages be updated (or flushed and discarded) with the

data from the noncached write?

ISTR that until quite recently this was impossible since you couldn’t get
back from the PFN to the PTE or the file, but that in a recent release
(which might be as ;long ago as Win7) that changed…

>> Will the in-memory pages be updated (or flushed and discarded) with the

> data from the noncached write?

ISTR that until quite recently this was impossible since you couldn’t get
back from the PFN to the PTE or the file

Why is the need in this? this is probably a must in a networking redir scenario to flush/purge the pages if oplock is broken, but why is it important in the local scenario?

You begin with Offset/Length tuple and the data.

If the file is mmaped, then it has MmCa, which has a collection of MmSt, and the ones exactly contain the prototype PTEs.

Just map these PPTEs one by one to some system PTE range, memcpy() the data there, updating it under the mapping application’s feet, and then proceed the usual noncached write.

This would be exactly the same as implementing the noncached write as Cc write followed by a flush, just without Cc involved, only Mm.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com