Supporting both read/write access and memory mapped file access to the same data, requires either a high cost, (and hence low performance) cache consistency scheme or the scheme used by NT – where all data is stored in the virtual memory system. Such systems are extremely efficient and boost both the actual and perceived performance of the system.Ī second reason for this integration is Windows NT’s support for memory-mapped files. For example, like most modern operating systems, Windows NT integrates file system caching with the virtual memory system – using the system memory as a giant cache for file system information. The rationale for providing Fast I/O seems to be one of convenience – many I/O operations are repeatedly performed against the same data. In this article we will provide the rationale for fast I/O, a brief description of the various fast I/O calls, and conclude with some suggestions on how to use this interface to improve performance for your project. Of course the most frustrating aspect of fast I/O for Windows NT® is the total lack of available documentation – even the file system development kit does not provide a description of how fast I/O works or how to use it. We will describe these restrictions later in this article. For example, both the read and write fast I/O entry points are only called when information about the particular file is being maintained by the cache manager in Windows NT. This approach to I/O is used by some file system drivers, such as NTFS, HPFS, FAT, and CDFS as well as the AFD transport driver which is used by WinSock.Īny driver can register a set of fast I/O entry points but their use is often extremely limited – requiring that just the right conditions be met before a particular fast I/O entry point will even be called. Because of this, the NT team introduced the concept of fast I/O. In that instance, the overhead associated with creating an IRP can dominate the cost of the entire operation – slowing the system down in performance critical areas. While this approach is very general and extensible – allowing for the cleanly layered Windows NT device architecture, there is a fair amount of overhead involved for operations where the request can be satisfied quickly. The standard dogma for Windows NT kernel mode development is that NT uses the I/O Request Packet (IRP) as the basis of communications with drivers – the advantage of the I/O Request packet is that it encapsulates the context needed for a particular operation and allows abstraction of the driver away from many of the details common to drivers. The NT Insider, Vol 3, Issue 1, Feb 1996 | Published: 15-Feb-96| Modified: 31-Oct-02
0 kommentar(er)
