Disk I/O priority

NTFSD
1

Hi,

I am trying to write a filter driver which will prioritize requests sent
to the disk. I’m only interested in actual disk hits and not cache hits
(and I’m not concerned with network, so that’s one thing off my back!).

Depending on the PID which generated the original request, I have to
decide which request should go straight to the underlying driver, and
which request should be delayed. I know that paging writes cannot be
delayed, but I believe I should be able to delay everything else?

I have already done an encryption filter over the last few years, so I
know some of the gotchas, but I’m wondering what type of filter I should
write:

* Above the disk driver
Pros:
easier to write, and I only get what I am interested in
Cons:
Can I actually get the PID of the original caller?

* Above the FS driver
Pros:
I should be able to get (most of the time?) the PID of the original
process. But what about antivirus softwares that post the requests and
perform the actual READs and WRITEs from another context?
Cons:
I have to deal with the cache manager…

Another possibility would be a combination: “tag” requests at the FS
level and do the actual delaying at the disk level. But can I get the
original request at the disk level?

So the main question is: Is there a way to “reliably” get the PID of the
original request? At what level? What’s the best way to get it? I don’t
need 100% accuracy, but I’d like to be close enough to have some effect
on disk I/O priority globally.

Thanks!

Eric

2

Eric,

I am trying to write a filter driver which will prioritize requests sent
to the disk. I’m only interested in actual disk hits and not cache hits
(and I’m not concerned with network, so that’s one thing off my back!).

you remind me of a similar project I was involved in a year and a half
back. Reading your mail, made me remember the problems we faced, they
were the same ones you had.

Well, all I can tell you is that we were attaching out driver to the
FS as a filter (below the FS level getting process information is
difficult)

Depending on the PID which generated the original request, I have to
decide which request should go straight to the underlying driver, and
which request should be delayed.

Well, that was exactly, what we were trying out, the *priviledged*
application got more IRPs through us, than the non priviledged ones.
How do you decide the threshold? The ratio of priviledged IRPs to non
proviledged ones. Also, blocking certain IRPs or delaying them makes
the syustem unstable. You will also have to take care of IRPs getting
cancelled because they got delayed (I am sure, with your experience
you know all this).

I know that paging writes cannot be
delayed

True.

I have already done an encryption filter over the last few years, so I
know some of the gotchas, but I’m wondering what type of filter I should
write:

Study Filemon’s code if you have it, I believe the older version is
still available ofr reference. It will give you a very good insight.

* Above the disk driver
Pros:
easier to write, and I only get what I am interested in
Cons:
Can I actually get the PID of the original caller?

Well, process specific information is stripped down at FS leve. There
might be a crooked way though, I am not aware of it. Writing a two
stage driver, attaching one at the FS level that passes the driver
attached to the disk the correct PIDs as IOCTLs…may be might work,
not sure.

* Above the FS driver
Pros:
I should be able to get (most of the time?) the PID of the original
process. But what about antivirus softwares that post the requests and
perform the actual READs and WRITEs from another context?
Cons:
I have to deal with the cache manager…

Cache manager is a real tough customer to deal with.

Another possibility would be a combination: “tag” requests at the FS
level and do the actual delaying at the disk level. But can I get the
original request at the disk level?

Yeah, may be.

_ Developer

3

Sorry, you it ain’t going to work. The original requestor is stripped out
at the file system level, and most I/O is going through the cache. I know
of a company that tried this, they wrote a file system filter and a disk
filter to try to handle this, with the file system filter record the regions
and the users and the disk filter “prioritizing” the writes. It took a lot
of work for them to get this working at all, at which point their
application had a 25% decrease in performance, after a lot of work they
reduced this to a 10% performance decrease.

I know about it because they had fired the engineering management, and
senior development staff for incompetance and interviewed me to be their new
CTO.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Eric Thiebaut-George” wrote in message
news:xxxxx@ntfsd…
> Hi,
>
> I am trying to write a filter driver which will prioritize requests sent
> to the disk. I’m only interested in actual disk hits and not cache hits
> (and I’m not concerned with network, so that’s one thing off my back!).
>
> Depending on the PID which generated the original request, I have to
> decide which request should go straight to the underlying driver, and
> which request should be delayed. I know that paging writes cannot be
> delayed, but I believe I should be able to delay everything else?
>
> I have already done an encryption filter over the last few years, so I
> know some of the gotchas, but I’m wondering what type of filter I should
> write:
>
> * Above the disk driver
> Pros:
> easier to write, and I only get what I am interested in
> Cons:
> Can I actually get the PID of the original caller?
>
> * Above the FS driver
> Pros:
> I should be able to get (most of the time?) the PID of the original
> process. But what about antivirus softwares that post the requests and
> perform the actual READs and WRITEs from another context?
> Cons:
> I have to deal with the cache manager…
>
> Another possibility would be a combination: “tag” requests at the FS
> level and do the actual delaying at the disk level. But can I get the
> original request at the disk level?
>
> So the main question is: Is there a way to “reliably” get the PID of the
> original request? At what level? What’s the best way to get it? I don’t
> need 100% accuracy, but I’d like to be close enough to have some effect
> on disk I/O priority globally.
>
> Thanks!
>
> Eric
>

4

> > Depending on the PID which generated the original request, I have to

> decide which request should go straight to the underlying driver, and
> which request should be delayed.

Well, that was exactly, what we were trying out, the *priviledged*
application got more IRPs through us, than the non priviledged ones.
How do you decide the threshold? The ratio of priviledged IRPs to non
proviledged ones. Also, blocking certain IRPs or delaying them makes
the syustem unstable. You will also have to take care of IRPs getting
cancelled because they got delayed (I am sure, with your experience
you know all this).

We haven’t completely figured out the algorithm yet, but at this stage
it’s more of a proof of concept…

Well, process specific information is stripped down at FS leve. There
might be a crooked way though, I am not aware of it. Writing a two
stage driver, attaching one at the FS level that passes the driver
attached to the disk the correct PIDs as IOCTLs…may be might work,
not sure.

That was pretty much what I was thinking. It does look messy but it
might
be a candidate if there is no other way…

Eric

5

Not very promissing ;-).

Actually, I could definitely live with 5 to 10% performance loss if
the whole system was more responsive (if my foreground applications
become more responsive, I don’t care if my background tasks finish
in 10 or 11 hours, anyway it could well be in the middle of the night).

Eric

On Wed, 17 Aug 2005 06:33:56 -0400, “Don Burn” said:
> Sorry, you it ain’t going to work. The original requestor is stripped
> out
> at the file system level, and most I/O is going through the cache. I
> know
> of a company that tried this, they wrote a file system filter and a disk
> filter to try to handle this, with the file system filter record the
> regions
> and the users and the disk filter “prioritizing” the writes. It took a
> lot
> of work for them to get this working at all, at which point their
> application had a 25% decrease in performance, after a lot of work they
> reduced this to a 10% performance decrease.
>
> I know about it because they had fired the engineering management, and
> senior development staff for incompetance and interviewed me to be their
> new
> CTO.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Eric Thiebaut-George” wrote in message
> news:xxxxx@ntfsd…
> > Hi,
> >
> > I am trying to write a filter driver which will prioritize requests sent
> > to the disk. I’m only interested in actual disk hits and not cache hits
> > (and I’m not concerned with network, so that’s one thing off my back!).
> >
> > Depending on the PID which generated the original request, I have to
> > decide which request should go straight to the underlying driver, and
> > which request should be delayed. I know that paging writes cannot be
> > delayed, but I believe I should be able to delay everything else?
> >
> > I have already done an encryption filter over the last few years, so I
> > know some of the gotchas, but I’m wondering what type of filter I should
> > write:
> >
> > * Above the disk driver
> > Pros:
> > easier to write, and I only get what I am interested in
> > Cons:
> > Can I actually get the PID of the original caller?
> >
> > * Above the FS driver
> > Pros:
> > I should be able to get (most of the time?) the PID of the original
> > process. But what about antivirus softwares that post the requests and
> > perform the actual READs and WRITEs from another context?
> > Cons:
> > I have to deal with the cache manager…
> >
> > Another possibility would be a combination: “tag” requests at the FS
> > level and do the actual delaying at the disk level. But can I get the
> > original request at the disk level?
> >
> > So the main question is: Is there a way to “reliably” get the PID of the
> > original request? At what level? What’s the best way to get it? I don’t
> > need 100% accuracy, but I’d like to be close enough to have some effect
> > on disk I/O priority globally.
> >
> > Thanks!
> >
> > Eric
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@dungorm.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Actually, the numbers were that their app lost 10% and the rest of the
applications had similar or worse performance. Basically, they spent a
number of man years, to produce something that just slowed down the system.

What is ironic I later heard they found someone really good at tuning a
system, and between tuning the system, and analyzing the application they
got a significant perfomance kick without touching the kernel.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Eric Thiebaut-George” wrote in message
news:xxxxx@ntfsd…
> Not very promissing ;-).
>
> Actually, I could definitely live with 5 to 10% performance loss if
> the whole system was more responsive (if my foreground applications
> become more responsive, I don’t care if my background tasks finish
> in 10 or 11 hours, anyway it could well be in the middle of the night).
>
> Eric
>
>
> On Wed, 17 Aug 2005 06:33:56 -0400, “Don Burn” said:
>> Sorry, you it ain’t going to work. The original requestor is stripped
>> out
>> at the file system level, and most I/O is going through the cache. I
>> know
>> of a company that tried this, they wrote a file system filter and a disk
>> filter to try to handle this, with the file system filter record the
>> regions
>> and the users and the disk filter “prioritizing” the writes. It took a
>> lot
>> of work for them to get this working at all, at which point their
>> application had a 25% decrease in performance, after a lot of work they
>> reduced this to a 10% performance decrease.
>>
>> I know about it because they had fired the engineering management, and
>> senior development staff for incompetance and interviewed me to be their
>> new
>> CTO.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> “Eric Thiebaut-George” wrote in message
>> news:xxxxx@ntfsd…
>> > Hi,
>> >
>> > I am trying to write a filter driver which will prioritize requests
>> > sent
>> > to the disk. I’m only interested in actual disk hits and not cache hits
>> > (and I’m not concerned with network, so that’s one thing off my back!).
>> >
>> > Depending on the PID which generated the original request, I have to
>> > decide which request should go straight to the underlying driver, and
>> > which request should be delayed. I know that paging writes cannot be
>> > delayed, but I believe I should be able to delay everything else?
>> >
>> > I have already done an encryption filter over the last few years, so I
>> > know some of the gotchas, but I’m wondering what type of filter I
>> > should
>> > write:
>> >
>> > * Above the disk driver
>> > Pros:
>> > easier to write, and I only get what I am interested in
>> > Cons:
>> > Can I actually get the PID of the original caller?
>> >
>> > * Above the FS driver
>> > Pros:
>> > I should be able to get (most of the time?) the PID of the original
>> > process. But what about antivirus softwares that post the requests and
>> > perform the actual READs and WRITEs from another context?
>> > Cons:
>> > I have to deal with the cache manager…
>> >
>> > Another possibility would be a combination: “tag” requests at the FS
>> > level and do the actual delaying at the disk level. But can I get the
>> > original request at the disk level?
>> >
>> > So the main question is: Is there a way to “reliably” get the PID of
>> > the
>> > original request? At what level? What’s the best way to get it? I don’t
>> > need 100% accuracy, but I’d like to be close enough to have some effect
>> > on disk I/O priority globally.
>> >
>> > Thanks!
>> >
>> > Eric
>> >
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@dungorm.co.uk
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

I agree with don, because in our project we also had the same output,
the systems performance degraded rather than increasing.

On 8/17/05, Don Burn wrote:
> Actually, the numbers were that their app lost 10% and the rest of the
> applications had similar or worse performance. Basically, they spent a
> number of man years, to produce something that just slowed down the system.
>
> What is ironic I later heard they found someone really good at tuning a
> system, and between tuning the system, and analyzing the application they
> got a significant perfomance kick without touching the kernel.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Eric Thiebaut-George” wrote in message
> news:xxxxx@ntfsd…
> > Not very promissing ;-).
> >
> > Actually, I could definitely live with 5 to 10% performance loss if
> > the whole system was more responsive (if my foreground applications
> > become more responsive, I don’t care if my background tasks finish
> > in 10 or 11 hours, anyway it could well be in the middle of the night).
> >
> > Eric
> >
> >
> > On Wed, 17 Aug 2005 06:33:56 -0400, “Don Burn” said:
> >> Sorry, you it ain’t going to work. The original requestor is stripped
> >> out
> >> at the file system level, and most I/O is going through the cache. I
> >> know
> >> of a company that tried this, they wrote a file system filter and a disk
> >> filter to try to handle this, with the file system filter record the
> >> regions
> >> and the users and the disk filter “prioritizing” the writes. It took a
> >> lot
> >> of work for them to get this working at all, at which point their
> >> application had a 25% decrease in performance, after a lot of work they
> >> reduced this to a 10% performance decrease.
> >>
> >> I know about it because they had fired the engineering management, and
> >> senior development staff for incompetance and interviewed me to be their
> >> new
> >> CTO.
> >>
> >>
> >> –
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >>
> >> “Eric Thiebaut-George” wrote in message
> >> news:xxxxx@ntfsd…
> >> > Hi,
> >> >
> >> > I am trying to write a filter driver which will prioritize requests
> >> > sent
> >> > to the disk. I’m only interested in actual disk hits and not cache hits
> >> > (and I’m not concerned with network, so that’s one thing off my back!).
> >> >
> >> > Depending on the PID which generated the original request, I have to
> >> > decide which request should go straight to the underlying driver, and
> >> > which request should be delayed. I know that paging writes cannot be
> >> > delayed, but I believe I should be able to delay everything else?
> >> >
> >> > I have already done an encryption filter over the last few years, so I
> >> > know some of the gotchas, but I’m wondering what type of filter I
> >> > should
> >> > write:
> >> >
> >> > * Above the disk driver
> >> > Pros:
> >> > easier to write, and I only get what I am interested in
> >> > Cons:
> >> > Can I actually get the PID of the original caller?
> >> >
> >> > * Above the FS driver
> >> > Pros:
> >> > I should be able to get (most of the time?) the PID of the original
> >> > process. But what about antivirus softwares that post the requests and
> >> > perform the actual READs and WRITEs from another context?
> >> > Cons:
> >> > I have to deal with the cache manager…
> >> >
> >> > Another possibility would be a combination: “tag” requests at the FS
> >> > level and do the actual delaying at the disk level. But can I get the
> >> > original request at the disk level?
> >> >
> >> > So the main question is: Is there a way to “reliably” get the PID of
> >> > the
> >> > original request? At what level? What’s the best way to get it? I don’t
> >> > need 100% accuracy, but I’d like to be close enough to have some effect
> >> > on disk I/O priority globally.
> >> >
> >> > Thanks!
> >> >
> >> > Eric
> >> >
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@dungorm.co.uk
> >> 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@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- Developer