Async handling of reads and writes in FSD

NTFSD
1

Hi all:

I’ve been running the IFSTEST supplied with the W2K IFS kit against my FSD,
and have become stumped by a few failures.

Several tests are failing because they expect a read or write to return
STATUS_SUCCESS, where I’m returning STATUS_PENDING. That is, I’m handling
the read (for example, with the AtomicSeekReadTest) asynchronously, by
posting it to a worker thread, whereas the test expects the read to complete
synchronously.

I’ve verified that if in fact I handle the reads synchronously, the test
passes. (I used a debugger to alter my control flow.)

I’m deciding whether or not to handle the read asynchronously based on the
return value from IoIsOperationSynchronous() called on the read IRP. If
this is FALSE, then I assume the request cannot block, so I post the request
and return STATUS_PENDING.

I’ve verified by looking at the NtReadFile() call, which results in my read
dispatch routine being called, that the test case is not sending an event
handle or an APC routine to be signaled or called when the operation
completes. That is, the test doesn’t seem to know how to handle a
STATUS_PENDING return from my dispatch routine.

I’m wondering now if the test is invalid. My own async read/write tests,
which wait on a handle, work fine. (I’m using the Win32 API for these
tests; the IFSTEST uses ntdll routines directly.) My guess is that NTFS and
FAT (for example) will be more aggressive than my FSD in attempting to
handle the read synchronously – they will only post the request if
something that they are waiting on would fail AND the request cannot block.

I on the other hand just unconditionally post the request if it cannot
block. This would mean that the test would fail on my FSD, but usually just
happen to pass on FAT (e.g.).

Any insights, especially into my method of determining if the IRP can block
or not, would be greatly appreciated.

Thanks,
Curt Wohlgemuth

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

I too have noticed this problem with IFSTEST for some time now. I had the
opportunity last Summer to talk to one of the IFSTEST developers and it was
indeed determined that the IFSTEST version available at that time did not
handle STATUS_PENDING very well. In fact, if I remember correctly, it should
have been specifying SYNCHRONOUS behavior in its calls to ZwCreateFile() so
it would not see STATUS_PENDING returned for its IO calls.

I have not tried any new versions since then. I suspect there is a newer
version available in the Whistler IFS Beta kit, but I have not tried that
one yet.

/ted

From:
xxxxx@omnishift.com[SMTP:xxxxx@omnishift.com]
Reply To: File Systems Developers
Sent: Friday, February 23, 2001 3:07 PM
To: File Systems Developers
Subject: [ntfsd] Async handling of reads and writes in FSD

Hi all:

I’ve been running the IFSTEST supplied with the W2K IFS kit against my
FSD, and have become stumped by a few failures.

Several tests are failing because they expect a read or write to return
STATUS_SUCCESS, where I’m returning STATUS_PENDING. That is, I’m handling
the read (for example, with the AtomicSeekReadTest) asynchronously, by
posting it to a worker thread, whereas the test expects the read to
complete synchronously.

I’ve verified that if in fact I handle the reads synchronously, the test
passes. (I used a debugger to alter my control flow.)

I’m deciding whether or not to handle the read asynchronously based on the
return value from IoIsOperationSynchronous() called on the read IRP. If
this is FALSE, then I assume the request cannot block, so I post the
request and return STATUS_PENDING.

I’ve verified by looking at the NtReadFile() call, which results in my
read dispatch routine being called, that the test case is not sending an
event handle or an APC routine to be signaled or called when the operation
completes. That is, the test doesn’t seem to know how to handle a
STATUS_PENDING return from my dispatch routine.

I’m wondering now if the test is invalid. My own async read/write tests,
which wait on a handle, work fine. (I’m using the Win32 API for these
tests; the IFSTEST uses ntdll routines directly.) My guess is that NTFS
and FAT (for example) will be more aggressive than my FSD in attempting to
handle the read synchronously – they will only post the request if
something that they are waiting on would fail AND the request cannot
block.

I on the other hand just unconditionally post the request if it cannot
block. This would mean that the test would fail on my FSD, but usually
just happen to pass on FAT (e.g.).

Any insights, especially into my method of determining if the IRP can
block or not, would be greatly appreciated.

Thanks,
Curt Wohlgemuth

You are currently subscribed to ntfsd as: xxxxx@livevault.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com