Minifilter monitoring Fast IO writes

I have a minifilter which monitors activity on a (or part of a) file system.
It just logs any files updated - the filename, amount of data written and
the offset. Where possible it logs the writes to the cache (it only logs
writes from cache to disk for those files opened
FILE_NO_INTERMEDIATE_BUFFERING or memory mapped writes).

When a file is created (on a volume that is being monitored) using a second
machine writing to a network share then the filter log shows that the file
has been created and written - The filter caught the IRP_MJ_WRITEs with
FLTFL_CALLBACK_DATA_FAST_IO_OPERATION set in the callback flags. But the
amount of data recorded by these IRP_MJ_WRITE operations does not actually
match the amount of data in the file. A test with a 350Kb file logs 6 writes
of 4352 bytes each - Each one 60K further up the file than the previous.
(The file did not have any blocks zeroes in it).

If I use Ladislav Zezula’s FileSpy to monitor what is happening then it
shows the same thing - the 6 short writes to cache. Then it shows the
complete file being written from cache to device.

When I first started to read about fast i/o I fully expected to have to log
the writes as written from cache to device, just like memory mapped file - I
never expected minifilters to receive the data written to cache by fast i/o.

So should I expect to see writes to cache for all the data written? Or was
my original assumption correct after all? (or have I completely
misunderstood the whole thing?)

Many thanks,

Gareth

Hello, Gareth

I wonder if you are monitoring the FastIo MDL Write path?

Cheers, Lyndon

“Gareth Evans” wrote in message
news:xxxxx@ntfsd…
I have a minifilter which monitors activity on a (or part of a) file system.
It just logs any files updated - the filename, amount of data written and
the offset. Where possible it logs the writes to the cache (it only logs
writes from cache to disk for those files opened
FILE_NO_INTERMEDIATE_BUFFERING or memory mapped writes).

When a file is created (on a volume that is being monitored) using a second
machine writing to a network share then the filter log shows that the file
has been created and written - The filter caught the IRP_MJ_WRITEs with
FLTFL_CALLBACK_DATA_FAST_IO_OPERATION set in the callback flags. But the
amount of data recorded by these IRP_MJ_WRITE operations does not actually
match the amount of data in the file. A test with a 350Kb file logs 6 writes
of 4352 bytes each - Each one 60K further up the file than the previous.
(The file did not have any blocks zeroes in it).

If I use Ladislav Zezula’s FileSpy to monitor what is happening then it
shows the same thing - the 6 short writes to cache. Then it shows the
complete file being written from cache to device.

When I first started to read about fast i/o I fully expected to have to log
the writes as written from cache to device, just like memory mapped file - I
never expected minifilters to receive the data written to cache by fast i/o.

So should I expect to see writes to cache for all the data written? Or was
my original assumption correct after all? (or have I completely
misunderstood the whole thing?)

Many thanks,
Gareth

Lyndon,

> I wonder if you are monitoring the FastIo MDL Write path?

Quite possibly not - but when using FileSpy all Fast I/O requests were
selected on the ‘Fast I/O Filter’ tab as well as all IRPs on the ‘Legacy
IRPs filter’ tab. And it too only logged the ‘short’ writes. Is it not
monitoring the FastIo MDL path either?

Probably irrelevant but the machine running the filter (& FileSpy) is a
virtual machine (on VMWare) - The machine used to copy the file to its’
shared disk was the host.

Many thanks,
Gareth

It’s now Monday morning and things are so much clearer.
No, my filter wasn’t monitoring the MDL path. In particular it was ignoring
the IRP_MJ_MDL_WRITE_COMPLETE
And yes I should have found the answer by searching the archives.
Moral of the story. Don’t post questions on a Friday night (and don’t trust
yourself to type the right things into a search box either).
Regards,
Gareth

So are you sorted now?

“Gareth Evans” wrote in message
>news:xxxxx@ntfsd…
> It’s now Monday morning and things are so much clearer.
> No, my filter wasn’t monitoring the MDL path. In particular it was
> ignoring
> the IRP_MJ_MDL_WRITE_COMPLETE
> And yes I should have found the answer by searching the archives.
> Moral of the story. Don’t post questions on a Friday night (and don’t
> trust
> yourself to type the right things into a search box either).
> Regards,
> Gareth
>
>
>