Hi. I have a questing regarding a filebacked virtual storport miniport driver.
For a read-only device I have a situation where I cannot answer a read request, yet. So I answer the request with SRB_STATUS_BUSY for a retry. At this point I would like to serve the next request in queue. However, I get the same request back after some delay and the queue is not processed further. Is there a way to resubmit the request to the tail of the SRB queue?
I saw some discussion here, where it was said to answer SRB_STATUS_BUSY followed by asking for the next request to the port driver. How can this be achieved?
What exactly do you mean by “I cannot answer a read request”? Consider not reporting the media present until you can answer all read requests. Or if the device needs longer timeouts in general then extend them.
Hello Rourke. In my case the requested data is not available, yet, but will be at a later time, which I cannot predict. So I want this request to be rescheduled. I looked a little more into the busy states and found aside the SRB_STATUS_BUSY also the SCSISTAT_BUSY. When both together are set in the SRB Response, it seems that the SRB queue continues and the next requests are passed on, as I intended. So SRB_STATUS_BUSY seems to put the request to the head of the queue. The combination seems to put the request back to the tail of the queue.