Strange behavior with FastIO

NTFSD
1

I am developing a file system driver. Under W2k I have observed that under
many circumstances, even if I set the IsFastIoPossible field to
FastIOIsNotPossible, my fast IO routine for read and write is still
called. The FastIo routine simply fails and than an IRP is generated, so
it is not really a big problem, but it seems that the IsFastIoPossible
field is being ignored.

Has anyone else seen this?

Don

2

Well Id say this is a small wonder , since NT uses something simialr to this
algo for system service based IO (ZwXxx or NtXxxx):

// Only relevant part , for synchronous IO

PDEVICE_OBJECT = IoGetRelatedDeviceObject(FileObject);
PFAST_IO_DISPACTH FastIoTable;
BOOLEAN FastIoPossible;
BOOLEAN Synchronous;

{
// Acquire File object lock
FastIoTable = DeviceObject->DriverObject->FastIoDispatch;
if (FileObject->PrivateCacheMap) // cache was intiated …
{

FastIoPossible = FastIoDispatch->FastIoWrite(A,B,Z);
if (FastIoPossible && STATUS_SUCCESS = IoStatus.Status )
{
// release file object lock
// signal waiters
// deref file object
return STATUS_SUCCESS;
}
}
Synchronous = TRUE;
}

/// proceed with IRP building
///

----- Original Message -----
From:
To: “File Systems Developers”
Sent: Wednesday, February 27, 2002 6:50 PM
Subject: [ntfsd] Strange behavior with FastIO

> I am developing a file system driver. Under W2k I have observed that under
> many circumstances, even if I set the IsFastIoPossible field to
> FastIOIsNotPossible, my fast IO routine for read and write is still
> called. The FastIo routine simply fails and than an IRP is generated, so
> it is not really a big problem, but it seems that the IsFastIoPossible
> field is being ignored.
>
> Has anyone else seen this?
>
> Don
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

3

Wouldn’t the algorithim that you have outlined result in FastIOWrite being
called regardless of the status of the IsFastIOPossible field in the
header of the fcb?

That is exactly what I am talking about. It appears that FastIOWrite is
called and then the IRP is build only if FastIOWrite failed. I thought
that the IsFastIOPossible field would stop FastIOWrite from ever being
called, even if cacheing has been initiated.

Don

4

Exactly , thats why I said “small wonder” As in I dont wonder at all.
IsFastIoPossible is used internaly by functions such as
FsRtlCopyRead - FsRtlCopyWrite and brothers.

----- Original Message -----
From:
To: “File Systems Developers”
Sent: Wednesday, February 27, 2002 9:41 PM
Subject: [ntfsd] Re: Strange behavior with FastIO

> Wouldn’t the algorithim that you have outlined result in FastIOWrite being
> called regardless of the status of the IsFastIOPossible field in the
> header of the fcb?
>
> That is exactly what I am talking about. It appears that FastIOWrite is
> called and then the IRP is build only if FastIOWrite failed. I thought
> that the IsFastIOPossible field would stop FastIOWrite from ever being
> called, even if cacheing has been initiated.
>
> Don
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

5

Oh. I thought you were being sarcastic when you were being serious. So my
observaton was correct.

Thanks for the info. It is good to know that I am not crazy.

Thanks,

Don

6

Thanks to Dan, who suggested that this is a bug in win2k, I reported it to
Microsoft. I just got off the phone with a guy there that says he’ll
escalate it up the CPR path so it get’s fixed in the next service pack.
My FSD crashed the system because I didn’t have a Fast I/O dispatch table
defined at all, and FsRtlAcquireFileForModWrite doesn’t check the
IsFastIOPossible flag. It then points to 0x3C off of null and blows up
the system.

7

As a further clarification, this function DOES NOT have to check
IsFastIOPossible flag at all. Its not madatory , not recomanded. All it
should do is to act acordigly and brach as required if
DeriverObject->FastIoDispatch == NULL .
IsFastIoPossible is used for other means.

Regards , Dan

----- Original Message -----
From: “Greg Pearce”
To: “File Systems Developers”
Sent: Wednesday, March 06, 2002 5:59 PM
Subject: [ntfsd] Re: Strange behavior with FastIO

> Thanks to Dan, who suggested that this is a bug in win2k, I reported it to
> Microsoft. I just got off the phone with a guy there that says he’ll
> escalate it up the CPR path so it get’s fixed in the next service pack.
> My FSD crashed the system because I didn’t have a Fast I/O dispatch table
> defined at all, and FsRtlAcquireFileForModWrite doesn’t check the
> IsFastIOPossible flag. It then points to 0x3C off of null and blows up
> the system.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>