returning status_pending from a paging io write

NTFSD
1

Hi All,

I have spent a long time searching this list archive to attempt to find the answer to my question. It has been answered to varying degrees already. However, it seems various advice conflicts or unclear to me so I’m going to ask again in regards to my specific application.

My current model takes all write requests that are marked with IRP_NOCACHE and attempts to process them assynhroneously. Actually, I process the part of actual write to the network server synchroneously, but I post the IRP completion to another thread.
I store the original IRP in an internal queue that will be processed by a dedicated worker thread. Before completing the irp, the worker thread will verify that the actual write was comitted to disk on the server, and if not, it will reschedule the irp to process the write again.

  1. I know that it is not safe to post the paging writes that were issued by CM Write behind thread, since it can result in a dead-lock because these threads pre-acquire resources, and do not release them till the IRP is completed. This will be an issue if I have to reschedule the IRP.

  2. Also I know that it is not safe to pend paging IOs because they are usually at APC IRQL. Pending an IO at APC IRQL will block the special kernel APC that is needed to complete the IO and the IO will again deadlock.

  3. I am pretty sure it will be “safe” with the MPW writer since it will continually write data as I return status_pending from the original dispatch.

  4. In your opinion, what would be the safest way to satisfy paging io requests for writes issued by CM Write behind threads? As I see it, the method that I’m using is not safe: returning status pending, then eventually complete in a worker thread. I guess I could block within the original paging io request until the worker thread signals that the the irp can be completed (or re-processed again), but I am afraid this will be “BAD” for performance. Perhaps another way to do it is to threat all IRPs like the IRP_NOCACHE flag is set.

-Ilya.

2

>1) I know that it is not safe to post the paging writes that were issued by CM Write behind thread, since it can result in a dead-lock because these threads pre-acquire resources, and do not release them till the IRP is completed. This will be an issue if I have to reschedule the IRP.

It is true for filters, FSDs can post these requests in a worker thread, see answer for 4)

  1. Also I know that it is not safe to pend paging IOs because they are usually at APC IRQL. Pending an IO at APC IRQL will block the special kernel APC that is needed to complete the IO and the IO will again deadlock.

IoCompleteRequest doesn’t use any APC to complete synchronous paging IO. If you issue an IRP at APC_LEVEL you must set a completion routine that sets an event( if needed ) in a signal state, calls IoFreeIrp and returns STATUS_MORE_PROCESSING_REQUIRED and this is your responsibility to free MDLs.

  1. I am pretty sure it will be “safe” with the MPW writer since it will continually write data as I return status_pending from the original dispatch.

Correct for both Mapped and Modify Page Writers in case of FSD, incorrect for filters( top level irp is not NULL! ).

  1. In your opinion, what would be the safest way to satisfy paging io requests for writes issued by CM Write behind threads? As I see it, the method that I’m using is not safe: returning status pending, then eventually complete in a worker thread. I guess I could block within the original paging io request until the worker thread signals that the the irp can be completed (or re-processed again), but I am afraid this will be “BAD” for performance. Perhaps another way to do it is to threat all IRPs like the IRP_NOCACHE flag is set.

It is safe if you correctly acquire resources in your FSD’s callbacks, write dispatch routine and worker thread, but it is not safe for filters to post a request with the preacquired resources( i.e. when the top level IRP value is not NULL ) to a worker thread.
Cache Manager’s read ahead and write behind subsystem has a relatively low bandwidth due to a synchronous Memory Manager’s API and a limited number of worker threads, if you don’t call the Cache Manager in your worker thread you should not deadlock the system but might reduce applications responsiveness.

–
Slava Imameyev, xxxxx@hotmail.com
wrote in message news:xxxxx@ntfsd…
Hi All,

I have spent a long time searching this list archive to attempt to find the answer to my question. It has been answered to varying degrees already. However, it seems various advice conflicts or unclear to me so I’m going to ask again in regards to my specific application.

My current model takes all write requests that are marked with IRP_NOCACHE and attempts to process them assynhroneously. Actually, I process the part of actual write to the network server synchroneously, but I post the IRP completion to another thread.
I store the original IRP in an internal queue that will be processed by a dedicated worker thread. Before completing the irp, the worker thread will verify that the actual write was comitted to disk on the server, and if not, it will reschedule the irp to process the write again.

1) I know that it is not safe to post the paging writes that were issued by CM Write behind thread, since it can result in a dead-lock because these threads pre-acquire resources, and do not release them till the IRP is completed. This will be an issue if I have to reschedule the IRP.
2) Also I know that it is not safe to pend paging IOs because they are usually at APC IRQL. Pending an IO at APC IRQL will block the special kernel APC that is needed to complete the IO and the IO will again deadlock.

3) I am pretty sure it will be “safe” with the MPW writer since it will continually write data as I return status_pending from the original dispatch.
4) In your opinion, what would be the safest way to satisfy paging io requests for writes issued by CM Write behind threads? As I see it, the method that I’m using is not safe: returning status pending, then eventually complete in a worker thread. I guess I could block within the original paging io request until the worker thread signals that the the irp can be completed (or re-processed again), but I am afraid this will be “BAD” for performance. Perhaps another way to do it is to threat all IRPs like the IRP_NOCACHE flag is set.

-Ilya.