Delayed IRP_MJ_WRITE notification in minifilter

Hi,

In my minifilter driver it may pass half an hour until I get the IRP_MJ_WRITE callback of a write to a memory mapped file that haven’t been flushed to disk before closing the handle.

I assume this is the normal behavior the cache manager does and when paging i/o writes are actually saved into disk.

Altough it may degrade o.s. performance, how can I force the write? Can I call an API to, for e.g., flush pending writes each 5 minutes?

Thanks,
Mauro.

If the file is memory mapped, the cache manager does not flush it. Only the modified page writer thread would write it back - and it’s goal isn’t to prevent user data loss, it’s goal is to ensure lots of clean pages it can steal if needed. So if you have lots of memory and modest activity I could see it taking a while before the memory manager tries to flush the page back.

You can ask the file system to flush the file. Other than that, there’s no way for YOU to flush the file.

Note: it is never safe in a file system filter driver to call the Cache Manager or Memory Manager on a file object that is not owned by that file system filter driver. So you might think it’s “ok” to call CcFlushCache* it is not - you cannot obtain the necessary file system locks and by calling it directly you create a latent deadlock. These types of deadlocks don’t usually show up in your own testing - but rest assured they will show up at your customer site.

So I will say again: DO NOT CALL Cc or Mm functions from a file system filter unless your FS filter owns the cache for those file objects (even when you own the cache, getting the locking deadlock free is challenging.)

Tony
OSR