There are other conditions that may make a request synchronous in
addition to just having a synchronous file object. In fact, some of
these conditions override FO_SYNCHRONOUS_IO. My GUESS here is that you
are blocking on asynchronous paging I/O when you shouldn’t be. For those
classes of I/O that can be either synch or asynch (such as read/write),
you should be relying on the value of IoIsOperationSynchronous().
Exactly what it means for an I/O request to be synchronous is a fuzzy
concept that’s never been explained adequately by Microsoft. The best
resource we have here is, of course FastFat. Nagar’s book also does a
good job of covering the concept. Basically, if a request is synchronous
(either ‘inherently’ or because IoIsOperationSynchronous() returns
TRUE), it is OK for you to block or not block and to pend or not pend as
you see fit. Otherwise, you must make every effort not to block and to
pend lower I/O whenever possible. Fastfat sometimes violates these
guidelines (as in FatPostStackOverflowRead), but it tries real hard not to.
Tom Hansen wrote:
My turn to ask for advice:
We have a file system filter that can induce high latency into i/o
requests. Delays of 1 to 30 seconds are normal for some i/o, depending
on file size, file location etc. In general, this latency occurs while
processing IRP_MJ_READ, since getting a file’s data is the most
expensive operation. In the case where the delay will occur, we also
disallow fast i/o reads on the file, including the MDL read (which is
used by SFU).The IRP_MJ_READ request sees this delay in one of two ways. The normal
case just defers the IRP and services it on a work queue. The callers
IRP is returned with STATUS_PENDING. In the case of a synchronous IRP
(FO_SYNCHRONOUS_IO), the request stalls in the caller’s thread and is
dispatched to the FSD after the delay is incurred. I believe that
deferring an IRP on a synchronous file object is not the best behavior,
so I added this synchronous handling in hopes of fixing a problem I was
seeing with SFU 3.0 and its NFS server. However, the problem still
exists.
>
The problem is the NFS server seems to temporarily deadlock local UDP
traffic on the Windows 2000 server when it has a number of pending
requests. This number increases due to the relative delays in the i/o
requests. The problem is categorized by local “ping” timeouts during a
“ping localhost -n 9999” command execution. Since local IP is used by
other services, this deadlock of local UDP causes a cascading meltdown
of services on the Windows 2000 server - including increased latency of
the read requests which require local IP traffic to be serviced.As a test case, I imposed a 20 second delay on all synchronous reads in
FILESPY and reproduced the same problem. CIFS and other file i/o
continues to work (at a very slow pace), but SFU 3.0’s NFS server causes
this UDP timeout.Any experience in this area would be appreciated.
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
- Nick Ryan (MVP for DDK)