Hi All,
I have posted this same request on few other groups but not able to get some
satisfactory answer and i recently got to know that this is the group to ask
the questions about the filesystem filter driver.
I want to reorder the IRPs in an upper filter driver to filesystem in order
to give the I/O priority to my process. i won’t cached read packets and the
IRP distribution done by the file system driver. So Is it possible to
reorder the IRPs while sitting over the filesystem filter driver and by
doing this can i be able to improve the disk I/O priority of my process (I
only want to do it for read requests without effecting the write requests).
I got some reply in other groups that i am attaching with this posting.
“Don Burn” wrote in message There is a disconnect
between what goes into the top of the FS and what comes out the bottom,
except under certain circumstances (such as non-buffered IO.) So there is
very little you can do below the FS to order IRPs by process. Generally you
will not have the original IRP at this level. Any encoding scheme from an
upper FS filter will miss 90% of the IRPs coming out of the bottom of the FS
driver.
With just an upper FS filter, independent IRPs show up at your upper filter
and you are going to queue them, it seems, rather than pass them down, so
that you can speculatively re-order them by process id.
I’d say you just took a carefully crafted multi-threaded IO model and
transformed it into a huge serialized clunker. But that is just me, I must
be misunderstanding something here. You will have your priority (sort of,
the FS driver will then proceed to do its own reordering,) and you will have
degraded performance.
Thanks in advance.
Don is basically right. In order to do what you’re doing, you’d have to
impose a synchronous I/O model on all I/O coming into the filesystems,
whether that I/O is specified to be synchronous or not. (I.e., block all
other filesytem I/O while yours is being processed). And if you do this,
you’ll have to worry about deadlocks due to hidden dependencies between
different I/O (such as if the volume you’re making requests against is a
virtual volume put up by a program like PGPdisk that is backed by
additional I/O to a file on another volume).
Fundamentally I don’t think that this is a good idea, even if it could
be done cleanly. If you have control over your computing environment,
just make sure that there aren’t any other processes out there doing
much of anything, and your process will by default receive the system’s
undivided attention. (If you’re trying to guarantee a maximum I/O
latency, forget it, you’ll need to use a different operating system). If
you don’t have control, then what makes you think the user wants your
process to unilaterally decide that SQLServer, ISS, et. al. deserve to
be pushed to the bottom of the queue?
vikram wrote:
Hi All,
I have posted this same request on few other groups but not able to get some
satisfactory answer and i recently got to know that this is the group to ask
the questions about the filesystem filter driver.
I want to reorder the IRPs in an upper filter driver to filesystem in order
to give the I/O priority to my process. i won’t cached read packets and the
IRP distribution done by the file system driver. So Is it possible to
reorder the IRPs while sitting over the filesystem filter driver and by
doing this can i be able to improve the disk I/O priority of my process (I
only want to do it for read requests without effecting the write requests).
I got some reply in other groups that i am attaching with this posting.
“Don Burn” wrote in message There is a disconnect
> between what goes into the top of the FS and what comes out the bottom,
> except under certain circumstances (such as non-buffered IO.) So there is
> very little you can do below the FS to order IRPs by process. Generally you
> will not have the original IRP at this level. Any encoding scheme from an
> upper FS filter will miss 90% of the IRPs coming out of the bottom of the FS
> driver.
>
> With just an upper FS filter, independent IRPs show up at your upper filter
> and you are going to queue them, it seems, rather than pass them down, so
> that you can speculatively re-order them by process id.
>
> I’d say you just took a carefully crafted multi-threaded IO model and
> transformed it into a huge serialized clunker. But that is just me, I must
> be misunderstanding something here. You will have your priority (sort of,
> the FS driver will then proceed to do its own reordering,) and you will have
> degraded performance.
>
> Thanks in advance.
>
>
>
–
Nick Ryan
(Microsoft Windows MVP for DDK)