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: tfaber(a)svn.reactos.org
Sent: ‎Tuesday‎, ‎August‎ ‎26‎, ‎2014 ‎6‎:‎41‎ ‎AM
To: ros-diffs(a)reactos.org
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/fastfa…
==============================================================================
--- 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, cameron.gutman(a)reactos.org 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