Why serialize the Read/Write Irps?

Andrei_B · January 12, 2004, 8:49pm

Hi all,

I’m studying the source code for the FileDisk driver (that lets one mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

OSR_Community_User · January 12, 2004, 8:57pm

Process context for doing IO on the file is one of the two reasons for
using a thread. It would be possible to use completion ports or some
similar mechanism to parallel the IO. Have you done a performance
comparison with a real volume? I suspect the numbers are very close.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Belogortseff
Sent: Monday, January 12, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Why serialize the Read/Write Irps?

Hi all,

I’m studying the source code for the FileDisk driver (that lets one
mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process
and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and
queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Andrei_B · January 13, 2004, 12:19am

> Process context for doing IO on the file is one of the two reasons for

using a thread.

Thank you, but I don’t understand. What can be wrong with the process
(thread?) context that can be fixed by queuing an Irp for processing by a
different thread? Could you please explain and/or give an example? Thanks a
lot!

Andrei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Belogortseff
Sent: Monday, January 12, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Why serialize the Read/Write Irps?

Hi all,

I’m studying the source code for the FileDisk driver (that lets one
mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process
and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and
queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

OSR_Community_User · January 13, 2004, 12:31am

> ----------

From: xxxxx@winability.com[SMTP:xxxxx@winability.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, January 13, 2004 6:16 AM
To: xxxxx@lists.osr.com
Subject: Re: [ntfsd] Why serialize the Read/Write Irps?

> Process context for doing IO on the file is one of the two reasons for
> using a thread.

Thank you, but I don’t understand. What can be wrong with the process
(thread?) context that can be fixed by queuing an Irp for processing by a
different thread?

File handle. IRPs for disk driver are called in arbitrary thread context and
file handle can’t be used (handle tables belong to processes). The
“different thread” is system thread and handle is valid there. Check how is
file opened.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

OSR_Community_User · January 13, 2004, 10:56am

The disk driver can receive requests at a raised IRQL in the process context
that is not the same context that the request was sent down in. The cache
manager is also a case where the thread sending down the request is not the
process needed to do the file IO.

It is like this: file disk type drivers use a file to store the disk
sectors. The file must be opened to get a handle. The process that the
handle was opened in is the only process that can use the handle. If the
cache manager sends down a request to write some data to the disk, you will
probably not be in the context of the same process that you opened the file
in; unless you open and close the file each time

The point here is that you need to make sure you are in a known process
context and at PASSIVE_LEVEL to access the file via the file handle. It is
easier to just put the request in a queue to a thread and let the thread
process the requests.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei Belogortseff
Sent: Monday, January 12, 2004 9:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why serialize the Read/Write Irps?

Process context for doing IO on the file is one of the two reasons for
using a thread.

Thank you, but I don’t understand. What can be wrong with the process
(thread?) context that can be fixed by queuing an Irp for processing by a
different thread? Could you please explain and/or give an example? Thanks a
lot!

Andrei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Belogortseff
Sent: Monday, January 12, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Why serialize the Read/Write Irps?

Hi all,

I’m studying the source code for the FileDisk driver (that lets one
mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process
and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and
queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 13, 2004, 11:09am

Hi,

if the driver is going to run only in 2k+ versions, kernel only handles can
be used to avoid the context problems. Then only in case of raised IRQLs you
will require to schedule the request to a separate thread.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Tuesday, January 13, 2004 9:25 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Why serialize the Read/Write Irps?

The disk driver can receive requests at a raised IRQL in the process context
that is not the same context that the request was sent down in. The cache
manager is also a case where the thread sending down the request is not the
process needed to do the file IO.

It is like this: file disk type drivers use a file to store the disk
sectors. The file must be opened to get a handle. The process that the
handle was opened in is the only process that can use the handle. If the
cache manager sends down a request to write some data to the disk, you will
probably not be in the context of the same process that you opened the file
in; unless you open and close the file each time

The point here is that you need to make sure you are in a known process
context and at PASSIVE_LEVEL to access the file via the file handle. It is
easier to just put the request in a queue to a thread and let the thread
process the requests.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei Belogortseff
Sent: Monday, January 12, 2004 9:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why serialize the Read/Write Irps?

Process context for doing IO on the file is one of the two reasons for
using a thread.

Thank you, but I don’t understand. What can be wrong with the process
(thread?) context that can be fixed by queuing an Irp for processing by a
different thread? Could you please explain and/or give an example? Thanks a
lot!

Andrei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Belogortseff
Sent: Monday, January 12, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Why serialize the Read/Write Irps?

Hi all,

I’m studying the source code for the FileDisk driver (that lets one
mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process
and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and
queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 13, 2004, 11:13am

its win2k and above…
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Kiran Joshi
Sent: Tuesday, January 13, 2004 9:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Why serialize the Read/Write Irps?

Hi,

if the driver is going to run only in 2k+ versions, kernel only handles can
be used to avoid the context problems. Then only in case of raised IRQLs you
will require to schedule the request to a separate thread.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Tuesday, January 13, 2004 9:25 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Why serialize the Read/Write Irps?

The disk driver can receive requests at a raised IRQL in the process context
that is not the same context that the request was sent down in. The cache
manager is also a case where the thread sending down the request is not the
process needed to do the file IO.

It is like this: file disk type drivers use a file to store the disk
sectors. The file must be opened to get a handle. The process that the
handle was opened in is the only process that can use the handle. If the
cache manager sends down a request to write some data to the disk, you will
probably not be in the context of the same process that you opened the file
in; unless you open and close the file each time

The point here is that you need to make sure you are in a known process
context and at PASSIVE_LEVEL to access the file via the file handle. It is
easier to just put the request in a queue to a thread and let the thread
process the requests.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei Belogortseff
Sent: Monday, January 12, 2004 9:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Why serialize the Read/Write Irps?

Process context for doing IO on the file is one of the two reasons for
using a thread.

Thank you, but I don’t understand. What can be wrong with the process
(thread?) context that can be fixed by queuing an Irp for processing by a
different thread? Could you please explain and/or give an example? Thanks a
lot!

Andrei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Belogortseff
Sent: Monday, January 12, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Why serialize the Read/Write Irps?

Hi all,

I’m studying the source code for the FileDisk driver (that lets one
mount a
file as a virtual disk) and see that when it gets IRP_MJ_READ or
IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
and returns STATUS_PENDING. Then the device thread wakes up to process
and
complete the IRPs.

Is there a reason for queuing the IRPs rather than processing them right
away? Well, one reason I can see is that if we’ve received an Irp at an
elevated level, we would not want to process it at that level, and
queuing
the Irp lets us postpone the processing until the IRQL level is reduced.
Are there any other reasons for not processing the Irps right away?

If there are no other reasons, then I’m thinking about the following
algorithm (in pseudo code):

OnIrpReceived( Irp )
{
if ( there are other pending Irps in the device queue )
{
// add this Irp to the queue as well,
// to make sure the Irps are processed in the order they are
received

add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else if ( IRQL level is higher than it is safe to process it
(PASSIVE_LEVEL?) )
{
add the Irp to the queue for future processing;
return STATUS_PENDING;
}
else
{
// at this point the IRQL level is low enough,
// and there are no other pending Irps in the queue

process the Irp right now;
complete the Irp;
}
}

Thank you in advance for any advice.

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 13, 2004, 3:00pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Kiran Joshi
Sent: Tuesday, January 13, 2004 9:39 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Why serialize the Read/Write Irps?

if the driver is going to run only in 2k+ versions, kernel only handles
can
be used to avoid the context problems. Then only in case of raised IRQLs
you
will require to schedule the request to a separate thread.

Yes, but for IRQL problem you need separate thread and if it is already
implemented, it is easier to process all requests there. I don’t believe
performance gain would be signifficant enough (if any). I’d be interested if
anybody measures performance of both solutions.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

Andrei_B · January 13, 2004, 6:27pm

From: “Vodicka, Michal” <michal.vodicka>
> File handle. IRPs for disk driver are called in arbitrary thread context
and
> file handle can’t be used (handle tables belong to processes). The
> “different thread” is system thread and handle is valid there. Check how
is
> file opened.

That makes sense, thank you all who replied!

With the best wishes,

Andrei Belogortseff
WinAbility(r) Software Corp. [http://www.winability.com/]
“Useful Windows Utilities and Security Software”</michal.vodicka>

Alexei_Jelvis-2 · January 13, 2004, 11:00pm

Alternative approach is to create an IRP to perform IO instead of using
ZwReadFile/ZWriteFile.
If the IRP is built using IoBuiltAsynchronousFsRequest then you it is safe
to perform IO in the same thread. In this case the only reason to queue
request to another thread is lack of stack space.

Alexei.

“Jamey Kirby” wrote in message news:xxxxx@ntfsd…
> Process context for doing IO on the file is one of the two reasons for
> using a thread. It would be possible to use completion ports or some
> similar mechanism to parallel the IO. Have you done a performance
> comparison with a real volume? I suspect the numbers are very close.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
> Belogortseff
> Sent: Monday, January 12, 2004 5:46 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Why serialize the Read/Write Irps?
>
> Hi all,
>
> I’m studying the source code for the FileDisk driver (that lets one
> mount a
> file as a virtual disk) and see that when it gets IRP_MJ_READ or
> IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
> and returns STATUS_PENDING. Then the device thread wakes up to process
> and
> complete the IRPs.
>
> Is there a reason for queuing the IRPs rather than processing them right
> away? Well, one reason I can see is that if we’ve received an Irp at an
> elevated level, we would not want to process it at that level, and
> queuing
> the Irp lets us postpone the processing until the IRQL level is reduced.
> Are there any other reasons for not processing the Irps right away?
>
> If there are no other reasons, then I’m thinking about the following
> algorithm (in pseudo code):
>
> OnIrpReceived( Irp )
> {
> if ( there are other pending Irps in the device queue )
> {
> // add this Irp to the queue as well,
> // to make sure the Irps are processed in the order they are
> received
>
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else if ( IRQL level is higher than it is safe to process it
> (PASSIVE_LEVEL?) )
> {
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else
> {
> // at this point the IRQL level is low enough,
> // and there are no other pending Irps in the queue
>
> process the Irp right now;
> complete the Irp;
> }
> }
>
> Thank you in advance for any advice.
>
> Andrei Belogortseff
> WinAbility(r) Software Corp. [http://www.winability.com/]
> “Useful Windows Utilities and Security Software”
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OSR_Community_User · January 14, 2004, 10:27am

And probably not a very elegant solution unless you feel you will gain
significant performance; which I doubt.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Tuesday, January 13, 2004 8:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Alternative approach is to create an IRP to perform IO instead of using
ZwReadFile/ZWriteFile.
If the IRP is built using IoBuiltAsynchronousFsRequest then you it is safe
to perform IO in the same thread. In this case the only reason to queue
request to another thread is lack of stack space.

Alexei.

“Jamey Kirby” wrote in message news:xxxxx@ntfsd…
> Process context for doing IO on the file is one of the two reasons for
> using a thread. It would be possible to use completion ports or some
> similar mechanism to parallel the IO. Have you done a performance
> comparison with a real volume? I suspect the numbers are very close.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
> Belogortseff
> Sent: Monday, January 12, 2004 5:46 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Why serialize the Read/Write Irps?
>
> Hi all,
>
> I’m studying the source code for the FileDisk driver (that lets one
> mount a
> file as a virtual disk) and see that when it gets IRP_MJ_READ or
> IRP_MJ_WRITE, it adds them to the processing queue of the device thread,
> and returns STATUS_PENDING. Then the device thread wakes up to process
> and
> complete the IRPs.
>
> Is there a reason for queuing the IRPs rather than processing them right
> away? Well, one reason I can see is that if we’ve received an Irp at an
> elevated level, we would not want to process it at that level, and
> queuing
> the Irp lets us postpone the processing until the IRQL level is reduced.
> Are there any other reasons for not processing the Irps right away?
>
> If there are no other reasons, then I’m thinking about the following
> algorithm (in pseudo code):
>
> OnIrpReceived( Irp )
> {
> if ( there are other pending Irps in the device queue )
> {
> // add this Irp to the queue as well,
> // to make sure the Irps are processed in the order they are
> received
>
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else if ( IRQL level is higher than it is safe to process it
> (PASSIVE_LEVEL?) )
> {
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else
> {
> // at this point the IRQL level is low enough,
> // and there are no other pending Irps in the queue
>
> process the Irp right now;
> complete the Irp;
> }
> }
>
> Thank you in advance for any advice.
>
> Andrei Belogortseff
> WinAbility(r) Software Corp. [http://www.winability.com/]
> “Useful Windows Utilities and Security Software”
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Vladimir_Chtchetkine · January 14, 2004, 10:52am

Well, since those IRPs are going through the file system stack, I would
expect a high probability BSOD 0x0A since FS stack doesn’t really expect
IRPs at elevated IRQL…

-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@rogers.com]
Sent: Tuesday, January 13, 2004 8:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Alternative approach is to create an IRP to perform IO instead of using
ZwReadFile/ZWriteFile.
If the IRP is built using IoBuiltAsynchronousFsRequest then you it is
safe
to perform IO in the same thread. In this case the only reason to queue
request to another thread is lack of stack space.

Alexei.

“Jamey Kirby” wrote in message
news:xxxxx@ntfsd…
> Process context for doing IO on the file is one of the two reasons for
> using a thread. It would be possible to use completion ports or some
> similar mechanism to parallel the IO. Have you done a performance
> comparison with a real volume? I suspect the numbers are very close.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
> Belogortseff
> Sent: Monday, January 12, 2004 5:46 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Why serialize the Read/Write Irps?
>
> Hi all,
>
> I’m studying the source code for the FileDisk driver (that lets one
> mount a
> file as a virtual disk) and see that when it gets IRP_MJ_READ or
> IRP_MJ_WRITE, it adds them to the processing queue of the device
thread,
> and returns STATUS_PENDING. Then the device thread wakes up to process
> and
> complete the IRPs.
>
> Is there a reason for queuing the IRPs rather than processing them
right
> away? Well, one reason I can see is that if we’ve received an Irp at
an
> elevated level, we would not want to process it at that level, and
> queuing
> the Irp lets us postpone the processing until the IRQL level is
reduced.
> Are there any other reasons for not processing the Irps right away?
>
> If there are no other reasons, then I’m thinking about the following
> algorithm (in pseudo code):
>
> OnIrpReceived( Irp )
> {
> if ( there are other pending Irps in the device queue )
> {
> // add this Irp to the queue as well,
> // to make sure the Irps are processed in the order they are
> received
>
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else if ( IRQL level is higher than it is safe to process it
> (PASSIVE_LEVEL?) )
> {
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else
> {
> // at this point the IRQL level is low enough,
> // and there are no other pending Irps in the queue
>
> process the Irp right now;
> complete the Irp;
> }
> }
>
> Thank you in advance for any advice.
>
> Andrei Belogortseff
> WinAbility(r) Software Corp. [http://www.winability.com/]
> “Useful Windows Utilities and Security Software”
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Alexei_Jelvis-2 · January 14, 2004, 8:13pm

Read/Write IRP are coming into a class driver from file system. File system
doesn’t originate IRP on dispatch level, the only elevated IRQL possible is
APC level. File system can handle IRP at APC level just fine.
I actually implemented this approach in a similar driver.
I don’t see why this solution is not elegant. You don’t need to maintain any
queue at all. Just create an IRP, send it down and in it’s completion
routine complete the original IRP.

Alexei.

“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Well, since those IRPs are going through the file system stack, I would
expect a high probability BSOD 0x0A since FS stack doesn’t really expect
IRPs at elevated IRQL…

-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@rogers.com]
Sent: Tuesday, January 13, 2004 8:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Alternative approach is to create an IRP to perform IO instead of using
ZwReadFile/ZWriteFile.
If the IRP is built using IoBuiltAsynchronousFsRequest then you it is
safe
to perform IO in the same thread. In this case the only reason to queue
request to another thread is lack of stack space.

Alexei.

“Jamey Kirby” wrote in message
news:xxxxx@ntfsd…
> Process context for doing IO on the file is one of the two reasons for
> using a thread. It would be possible to use completion ports or some
> similar mechanism to parallel the IO. Have you done a performance
> comparison with a real volume? I suspect the numbers are very close.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
> Belogortseff
> Sent: Monday, January 12, 2004 5:46 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Why serialize the Read/Write Irps?
>
> Hi all,
>
> I’m studying the source code for the FileDisk driver (that lets one
> mount a
> file as a virtual disk) and see that when it gets IRP_MJ_READ or
> IRP_MJ_WRITE, it adds them to the processing queue of the device
thread,
> and returns STATUS_PENDING. Then the device thread wakes up to process
> and
> complete the IRPs.
>
> Is there a reason for queuing the IRPs rather than processing them
right
> away? Well, one reason I can see is that if we’ve received an Irp at
an
> elevated level, we would not want to process it at that level, and
> queuing
> the Irp lets us postpone the processing until the IRQL level is
reduced.
> Are there any other reasons for not processing the Irps right away?
>
> If there are no other reasons, then I’m thinking about the following
> algorithm (in pseudo code):
>
> OnIrpReceived( Irp )
> {
> if ( there are other pending Irps in the device queue )
> {
> // add this Irp to the queue as well,
> // to make sure the Irps are processed in the order they are
> received
>
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else if ( IRQL level is higher than it is safe to process it
> (PASSIVE_LEVEL?) )
> {
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else
> {
> // at this point the IRQL level is low enough,
> // and there are no other pending Irps in the queue
>
> process the Irp right now;
> complete the Irp;
> }
> }
>
> Thank you in advance for any advice.
>
> Andrei Belogortseff
> WinAbility(r) Software Corp. [http://www.winability.com/]
> “Useful Windows Utilities and Security Software”
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 15, 2004, 1:58am

Hello,

This might not hold true if some volume level filter driver is sitting on
top of your volume and he is doing IO at DISPATCH_LEVEL for some reasons. I
have seen couple of volume level filters who actually do the IO at DISPATCH
level.

One more possibility is in the following scenario:

Fs sends Read/Write IRP to the volume and queues a completion routine for
the same.
The lower most driver completes the IRP from a DPC.
Fs’s completion routine is invoked at dispatch and from that completion
routine itself, fs sends another Read/Write IRP down.
Underlying drivers dispatch routines are invoked at DISPATCH_LEVEL.

So I think the safe (or rather correct) approach is, if your driver sits
below fs anywhere in the stack, be ready to handle requests at DISPATCH, and
that’s what the file driver is doing.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alexei Jelvis
Sent: Thursday, January 15, 2004 6:43 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Read/Write IRP are coming into a class driver from file system. File system
doesn’t originate IRP on dispatch level, the only elevated IRQL possible is
APC level. File system can handle IRP at APC level just fine.
I actually implemented this approach in a similar driver.
I don’t see why this solution is not elegant. You don’t need to maintain any
queue at all. Just create an IRP, send it down and in it’s completion
routine complete the original IRP.

Alexei.

“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Well, since those IRPs are going through the file system stack, I would
expect a high probability BSOD 0x0A since FS stack doesn’t really expect
IRPs at elevated IRQL…

-----Original Message-----
From: Alexei Jelvis [mailto:xxxxx@rogers.com]
Sent: Tuesday, January 13, 2004 8:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Alternative approach is to create an IRP to perform IO instead of using
ZwReadFile/ZWriteFile.
If the IRP is built using IoBuiltAsynchronousFsRequest then you it is
safe
to perform IO in the same thread. In this case the only reason to queue
request to another thread is lack of stack space.

Alexei.

“Jamey Kirby” wrote in message
news:xxxxx@ntfsd…
> Process context for doing IO on the file is one of the two reasons for
> using a thread. It would be possible to use completion ports or some
> similar mechanism to parallel the IO. Have you done a performance
> comparison with a real volume? I suspect the numbers are very close.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
> Belogortseff
> Sent: Monday, January 12, 2004 5:46 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Why serialize the Read/Write Irps?
>
> Hi all,
>
> I’m studying the source code for the FileDisk driver (that lets one
> mount a
> file as a virtual disk) and see that when it gets IRP_MJ_READ or
> IRP_MJ_WRITE, it adds them to the processing queue of the device
thread,
> and returns STATUS_PENDING. Then the device thread wakes up to process
> and
> complete the IRPs.
>
> Is there a reason for queuing the IRPs rather than processing them
right
> away? Well, one reason I can see is that if we’ve received an Irp at
an
> elevated level, we would not want to process it at that level, and
> queuing
> the Irp lets us postpone the processing until the IRQL level is
reduced.
> Are there any other reasons for not processing the Irps right away?
>
> If there are no other reasons, then I’m thinking about the following
> algorithm (in pseudo code):
>
> OnIrpReceived( Irp )
> {
> if ( there are other pending Irps in the device queue )
> {
> // add this Irp to the queue as well,
> // to make sure the Irps are processed in the order they are
> received
>
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else if ( IRQL level is higher than it is safe to process it
> (PASSIVE_LEVEL?) )
> {
> add the Irp to the queue for future processing;
> return STATUS_PENDING;
> }
> else
> {
> // at this point the IRQL level is low enough,
> // and there are no other pending Irps in the queue
>
> process the Irp right now;
> complete the Irp;
> }
> }
>
> Thank you in advance for any advice.
>
> Andrei Belogortseff
> WinAbility(r) Software Corp. [http://www.winability.com/]
> “Useful Windows Utilities and Security Software”
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Nick_Ryan · January 15, 2004, 2:21am

Alexei is right here, and MSDN guarantees it:

"The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.

The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out)."

If a filesystem calls down another read/write IRP from a completion
routine, then that is a bug. FastFat certainly does not do this.

Kiran Joshi wrote:

Hello,

This might not hold true if some volume level filter driver is sitting on
top of your volume and he is doing IO at DISPATCH_LEVEL for some reasons. I
have seen couple of volume level filters who actually do the IO at DISPATCH
level.

One more possibility is in the following scenario:

Fs sends Read/Write IRP to the volume and queues a completion routine for
the same.

The lower most driver completes the IRP from a DPC.

Fs’s completion routine is invoked at dispatch and from that completion
routine itself, fs sends another Read/Write IRP down.

Underlying drivers dispatch routines are invoked at DISPATCH_LEVEL.

So I think the safe (or rather correct) approach is, if your driver sits
below fs anywhere in the stack, be ready to handle requests at DISPATCH, and
that’s what the file driver is doing.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alexei Jelvis
Sent: Thursday, January 15, 2004 6:43 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Read/Write IRP are coming into a class driver from file system. File system
doesn’t originate IRP on dispatch level, the only elevated IRQL possible is
APC level. File system can handle IRP at APC level just fine.
I actually implemented this approach in a similar driver.
I don’t see why this solution is not elegant. You don’t need to maintain any
queue at all. Just create an IRP, send it down and in it’s completion
routine complete the original IRP.

Alexei.

“Vladimir Chtchetkine” wrote in message
> news:xxxxx@ntfsd…
> Well, since those IRPs are going through the file system stack, I would
> expect a high probability BSOD 0x0A since FS stack doesn’t really expect
> IRPs at elevated IRQL…
>
> -----Original Message-----
> From: Alexei Jelvis [mailto:xxxxx@rogers.com]
> Sent: Tuesday, January 13, 2004 8:00 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Why serialize the Read/Write Irps?
>
> Alternative approach is to create an IRP to perform IO instead of using
> ZwReadFile/ZWriteFile.
> If the IRP is built using IoBuiltAsynchronousFsRequest then you it is
> safe
> to perform IO in the same thread. In this case the only reason to queue
> request to another thread is lack of stack space.
>
> Alexei.
>
> “Jamey Kirby” wrote in message
> news:xxxxx@ntfsd…
>
>>Process context for doing IO on the file is one of the two reasons for
>>using a thread. It would be possible to use completion ports or some
>>similar mechanism to parallel the IO. Have you done a performance
>>comparison with a real volume? I suspect the numbers are very close.
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
>>Belogortseff
>>Sent: Monday, January 12, 2004 5:46 PM
>>To: Windows File Systems Devs Interest List
>>Subject: [ntfsd] Why serialize the Read/Write Irps?
>>
>>Hi all,
>>
>>I’m studying the source code for the FileDisk driver (that lets one
>>mount a
>>file as a virtual disk) and see that when it gets IRP_MJ_READ or
>>IRP_MJ_WRITE, it adds them to the processing queue of the device
>
> thread,
>
>>and returns STATUS_PENDING. Then the device thread wakes up to process
>>and
>>complete the IRPs.
>>
>>Is there a reason for queuing the IRPs rather than processing them
>
> right
>
>>away? Well, one reason I can see is that if we’ve received an Irp at
>
> an
>
>>elevated level, we would not want to process it at that level, and
>>queuing
>>the Irp lets us postpone the processing until the IRQL level is
>
> reduced.
>
>>Are there any other reasons for not processing the Irps right away?
>>
>>If there are no other reasons, then I’m thinking about the following
>>algorithm (in pseudo code):
>>
>>OnIrpReceived( Irp )
>>{
>> if ( there are other pending Irps in the device queue )
>> {
>> // add this Irp to the queue as well,
>> // to make sure the Irps are processed in the order they are
>>received
>>
>> add the Irp to the queue for future processing;
>> return STATUS_PENDING;
>> }
>> else if ( IRQL level is higher than it is safe to process it
>>(PASSIVE_LEVEL?) )
>> {
>> add the Irp to the queue for future processing;
>> return STATUS_PENDING;
>> }
>> else
>> {
>> // at this point the IRQL level is low enough,
>> // and there are no other pending Irps in the queue
>>
>> process the Irp right now;
>> complete the Irp;
>> }
>>}
>>
>>Thank you in advance for any advice.
>>
>> Andrei Belogortseff
>> WinAbility(r) Software Corp. [http://www.winability.com/]
>> “Useful Windows Utilities and Security Software”
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

–
Nick Ryan
(Microsoft Windows MVP for DDK)

OSR_Community_User · January 15, 2004, 4:39am

Hello,

I am not sure whether I got it correctly but does this mean that non of the
read/write dispatch routines in the complete storage stack will ever be
invoked at IRQL > APC?
And if some driver in the storage stack sends down read/write IRPs from
completion routine then its a bug.

May be I am wrong here, but what I understood form the MSDN documentation is
that the code and data for the lowest and the intermediate drivers should
always be resident if those lie in the paging-io path, since those might be
paged out while doing an in-page operation resulting into a bugcheck.

Somewhere in IFS following is also mentioned:
Restrictions on Pageable Code in Storage Drivers
To prevent deadlock, no part of a storage driver that is used to service
read or write requests should have pageable code, nor should it ever attempt
to access pageable memory. This is because the driver’s DispatchRead and
DispatchWrite routines can be called at IRQL > PASSIVE_LEVEL, and the
in-paging I/O that services a page fault takes place at IRQL = APC_LEVEL.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nick Ryan
Sent: Thursday, January 15, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Alexei is right here, and MSDN guarantees it:

"The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.

The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out)."

If a filesystem calls down another read/write IRP from a completion
routine, then that is a bug. FastFat certainly does not do this.

Kiran Joshi wrote:

Hello,

This might not hold true if some volume level filter driver is sitting on
top of your volume and he is doing IO at DISPATCH_LEVEL for some reasons.
I
have seen couple of volume level filters who actually do the IO at
DISPATCH
level.

One more possibility is in the following scenario:

Fs sends Read/Write IRP to the volume and queues a completion routine
for
the same.

The lower most driver completes the IRP from a DPC.

Fs’s completion routine is invoked at dispatch and from that completion
routine itself, fs sends another Read/Write IRP down.

Underlying drivers dispatch routines are invoked at DISPATCH_LEVEL.

So I think the safe (or rather correct) approach is, if your driver sits
below fs anywhere in the stack, be ready to handle requests at DISPATCH,
and
that’s what the file driver is doing.

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alexei Jelvis
Sent: Thursday, January 15, 2004 6:43 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Why serialize the Read/Write Irps?

Read/Write IRP are coming into a class driver from file system. File
system
doesn’t originate IRP on dispatch level, the only elevated IRQL possible
is
APC level. File system can handle IRP at APC level just fine.
I actually implemented this approach in a similar driver.
I don’t see why this solution is not elegant. You don’t need to maintain
any
queue at all. Just create an IRP, send it down and in it’s completion
routine complete the original IRP.

Alexei.

“Vladimir Chtchetkine” wrote in message
> news:xxxxx@ntfsd…
> Well, since those IRPs are going through the file system stack, I would
> expect a high probability BSOD 0x0A since FS stack doesn’t really expect
> IRPs at elevated IRQL…
>
> -----Original Message-----
> From: Alexei Jelvis [mailto:xxxxx@rogers.com]
> Sent: Tuesday, January 13, 2004 8:00 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Why serialize the Read/Write Irps?
>
> Alternative approach is to create an IRP to perform IO instead of using
> ZwReadFile/ZWriteFile.
> If the IRP is built using IoBuiltAsynchronousFsRequest then you it is
> safe
> to perform IO in the same thread. In this case the only reason to queue
> request to another thread is lack of stack space.
>
> Alexei.
>
> “Jamey Kirby” wrote in message
> news:xxxxx@ntfsd…
>
>>Process context for doing IO on the file is one of the two reasons for
>>using a thread. It would be possible to use completion ports or some
>>similar mechanism to parallel the IO. Have you done a performance
>>comparison with a real volume? I suspect the numbers are very close.
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
>>Belogortseff
>>Sent: Monday, January 12, 2004 5:46 PM
>>To: Windows File Systems Devs Interest List
>>Subject: [ntfsd] Why serialize the Read/Write Irps?
>>
>>Hi all,
>>
>>I’m studying the source code for the FileDisk driver (that lets one
>>mount a
>>file as a virtual disk) and see that when it gets IRP_MJ_READ or
>>IRP_MJ_WRITE, it adds them to the processing queue of the device
>
> thread,
>
>>and returns STATUS_PENDING. Then the device thread wakes up to process
>>and
>>complete the IRPs.
>>
>>Is there a reason for queuing the IRPs rather than processing them
>
> right
>
>>away? Well, one reason I can see is that if we’ve received an Irp at
>
> an
>
>>elevated level, we would not want to process it at that level, and
>>queuing
>>the Irp lets us postpone the processing until the IRQL level is
>
> reduced.
>
>>Are there any other reasons for not processing the Irps right away?
>>
>>If there are no other reasons, then I’m thinking about the following
>>algorithm (in pseudo code):
>>
>>OnIrpReceived( Irp )
>>{
>> if ( there are other pending Irps in the device queue )
>> {
>> // add this Irp to the queue as well,
>> // to make sure the Irps are processed in the order they are
>>received
>>
>> add the Irp to the queue for future processing;
>> return STATUS_PENDING;
>> }
>> else if ( IRQL level is higher than it is safe to process it
>>(PASSIVE_LEVEL?) )
>> {
>> add the Irp to the queue for future processing;
>> return STATUS_PENDING;
>> }
>> else
>> {
>> // at this point the IRQL level is low enough,
>> // and there are no other pending Irps in the queue
>>
>> process the Irp right now;
>> complete the Irp;
>> }
>>}
>>
>>Thank you in advance for any advice.
>>
>> Andrei Belogortseff
>> WinAbility(r) Software Corp. [http://www.winability.com/]
>> “Useful Windows Utilities and Security Software”
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

–
Nick Ryan
(Microsoft Windows MVP for DDK)

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 15, 2004, 11:14am

> And if some driver in the storage stack sends down read/write IRPs from

completion routine then its a bug.

Storage (disk) stack works fine on DISPATCH_LEVEL. Not so with the filesystems.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Nick_Ryan · January 15, 2004, 11:30am

Looks like we got a DDK docs bug then.

Maxim S. Shatskih wrote:

>And if some driver in the storage stack sends down read/write IRPs from
>completion routine then its a bug.

Storage (disk) stack works fine on DISPATCH_LEVEL. Not so with the filesystems.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

–
Nick Ryan
(Microsoft Windows MVP for DDK)