Hi Tom,
thank you for the I/O trace! Indeed FreeDOS XCOPY also suffers from using a non-aligned buffer. For COPY, the person to tune the code would be Jeremy at the moment. About your COPY C:\kernel.sys C:\BLA test: Let me summarize the LBA trace: Sectors 466 to 469 are read one by one, probably to scan the directory. Those will be merged when a cache with read-ahead is active, such as LBACACHE with TICKLE, or simply UHDD. Then, 1 FAT sector is read and both copies are written (read modify write). For reading the source file, as you say, the access is split to avoid DMA boundaries, which can be avoided by letting COPY (or XCOPY) use aligned buffers. Depending on the hardware, you could cross boundaries without ill effects, but it can also happen that the BIOS (or UDMA driver) will just split the I/O for you, so aligned buffers are still the BEST speed solution. It surprises me that the first sector AFTER the end of the source file is also read, sector 1760 to 5d0:4, is this the BLA target directory metadata itself? For writing the target file, the DMA boundary is hit again. However, the target also is split into four fragments in the cluster chain for unknown reasons. The kernel COULD try to find a consecutive chain IF it would know early enough how large the file WILL be, but COPY probably will NOT have told the kernel. A workaround MIGHT be to first grow the target file to target size by seeking to and writing a last byte, before starting to incrementally copy the contents. Next, the 5d0:4 buffer is filled once more, now with the contents of the first sector AFTER the target file? Both FAT copies are written again (probably buffered, so they are not read again immediately, luckily) before the "sector AFTER the target file" is updated using the (probably edited?) 5d0:4 buffer contents. Finally, sector 469 is written, probably a directory sector, without having to re-read old contents again, so this probably uses buffered data. Regarding whether transfers have to be split at track boundaries on CHS: I would not rely on this to work for floppy disks, but the BIOS might just do it for you transparently anyway. For fixed disks, geometries rarely have anything to do with reality anyway, so I agree that splitting I/O based on fixed disk CHS is a pretty useless attempt to be polite to those :-) Again, the kernel cannot rely on I/O being immune to DMA boundary crossing. Even where it works, it can still have a performance penalty. As there is no large I/O buffer "owned" by the kernel, it is easier for apps to properly align their buffers than to let the kernel do that. Of course, with modern systems, a kernel MIGHT allocate a large I/O buffer in XMS and lock it to a linear addr, but that should not happen by default, I think. Thanks again for the I/O tracing :-) Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
