Don’t forget that some devices do better when they know the full set of
active IRPs, because they can re-order them. I believe even some disk
hardware controllers will reorder requests to reduce seek time. So you may
even be slowing down the total throughput, without benefiting the
“privileged” apps at all.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eric Thiebaut-George
Sent: Wednesday, August 17, 2005 8:41 AM
To: Windows File Systems Devs Interest List
Subject: SPAM-LOW: Re: [ntfsd] Disk I/O priority
> 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
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com