Re: [ros-dev] [ros-diffs] [tfaber] 63953: [FASTFAT] - Do not use direct I/O since it limits read/write operations to 64 MB CORE-8410 #resolve

This seems strange. I understand that NT 5.x has a limitation of 64 MB MDLs on x86, but direct I/O was designed for exactly this case of large I/O operations. Has anyone verified that 2k3 doesn’t do MDL chaining for direct I/O when the transfer is larger than a single MDL can hold?

Also aren’t there changes to the IRP dispatch routines required to cope with not having an Irp->MdlAddress pointer anymore?

Cameron

From: [e-mail]
Sent: ‎Tuesday‎, ‎August‎ ‎26‎, ‎2014 ‎6‎:‎41‎ ‎AM
To: [e-mail]

Author: tfaber
Date: Tue Aug 26 13:41:57 2014
New Revision: 63953

URL: http://svn.reactos.org/svn/reactos?rev=63953&view=rev
Log:
[FASTFAT]
- Do not use direct I/O since it limits read/write operations to 64 MB
CORE-8410 #resolve

Modified:
    trunk/reactos/drivers/filesystems/fastfat/fsctl.c

Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat...
==============================================================================
--- trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] Tue Aug 26 13:41:57 2014
@@ -442,8 +442,7 @@
         goto ByeBye;
     }

-    DeviceObject->Flags = DeviceObject->Flags | DO_DIRECT_IO;
-    DeviceExt = (PVOID) DeviceObject->DeviceExtension;
+    DeviceExt = DeviceObject->DeviceExtension;
     RtlZeroMemory(DeviceExt, ROUND_UP(sizeof(DEVICE_EXTENSION), sizeof(ULONG)) + sizeof(HASHENTRY*) * HashTableSize);
     DeviceExt->FcbHashTable = (HASHENTRY**)((ULONG_PTR)DeviceExt + ROUND_UP(sizeof(DEVICE_EXTENSION), sizeof(ULONG)));
     DeviceExt->HashTableSize = HashTableSize;

[Thomas Faber]

I've tracked down what happens on Windows in the debugger, and the
relevant device objects don't have DO_DIRECT_IO set.
The WDK sample FS drivers use neither I/O as well.

I'm not 100% sure but from what I saw this part of our I/O manager
implementation is identical to Windows's and there's no chaining
happening. However a test to prove that is certainly a good idea. I'll
have a look at adding that.

The fastfat code is already agnostic to the I/O type pretty much
everywhere, it simply uses SystemBuffer if MdlAddress is NULL. However
my verification here was really just "it still works" (since it
"should" simply lead to obvious crashes otherwise).
I'm pretty much just dragging fastfat along right now while fixing
other things, so if there are any bugs I'm introducing there, I'm happy
to hear about them. But "properly" fixing fastfat is rather far in the
future on my agenda, if at all. :\

Thanks,
Thomas

On 2014-08-27 20:12, [e-mail] wrote:
> This seems strange. I understand that NT 5.x has a limitation of 64 MB MDLs on x86, but direct I/O was designed for exactly this case of large I/O operations. Has anyone verified that 2k3 doesn’t do MDL chaining for direct I/O when the transfer is larger than a single MDL can hold?
>
> Also aren’t there changes to the IRP dispatch routines required to cope with not having an Irp->MdlAddress pointer anymore?
>
> Cameron