IRP_MJ_WRITE, IRP_PAGING_IO and IRP_SYNCHRONOUS_PAGING_IO

NTFSD
1

Hi Respected All

Paging writes always have IRP_NOCACHE and IRP_PAGING_IO bits set;

when the IRP_SYNCHRONOUS_PAGING_IO flag is set/not set in the paging writes?

Thanks in advance
Andrew

2

> when the IRP_SYNCHRONOUS_PAGING_IO flag is set/not set in the paging writes?

Set on synchronous flush call, not set with lazy writer.

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

3

Hmm, what I noticed is that writing to a buffered file produces synchronous paging writes; copying data into a view of a memory mapped file produces non-synchronous paging writes.

Is not the lazy writer engaged in both cases?

4

On 02/24/2014 11:40 AM, xxxxx@hotmail.com wrote:

Hmm, what I noticed is that writing to a buffered file produces synchronous paging writes; copying data into a view of a memory mapped file produces non-synchronous paging writes.

Is not the lazy writer engaged in both cases?

The mapped page writer writes asynchronously, and in response to changes
via mapped views. The lazy writer writes synchronously, and in response
to buffered writes. Because the two share pages, it is possible to see
each write data that might be expected to be written by the other.

Here, if only a mapped view is involved (no buffered IO) there will be
no shared cache map and no lazy writer, so the writes must be written
out via the mapped page writer, and will be written async.

Note there is no strong reason for this behavior, and code should be
robust to async paging writes no matter where they originate from.

  • M
5

Ok, this explains my traces, thank you

Is it a bad idea to send incoming asynchronous paging writes synchronously down the stack?

6

This is a very important point: (1) this is certainly behavior that is subject to change - and will when performance dictates that this be the case; and (2) there may be other components in the system that generate paging I/O and change the behavior pattern.

Note that either type of paging I/O (synchronous or not) can be posted. The distinction is that the IRP_SYNCHRONOUS_PAGING_IO bit is your hint that the caller is going to block and wait for the paging operation, so posting it is not in and of itself useful. For the mapped page writer thread, posting the I/O permits it to move on to sending even more I/O operations which can yield better performance in some situations (high latency network for example, or real rotating disk drives that perform queue management to optimize writes to minimize track-to-track seeks).

IRP_PAGING_IO also impacts the way the I/O Manager treats the IRP: it does not use an APC to get back to the original thread context (it sets the event in the IRP instead) and the MDL used in the IRP is not torn down (it belongs to the caller). It’s easy for me to envision components that would desire this behavior as well.

Tony
OSR

7

Did not you mean IRP_SYNCHRONOUS_PAGING_IO in the very last sentence?