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@svn.reactos.org Sent: Tuesday, August 26, 2014 6:41 AM To: ros-diffs@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/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;
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@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