The I/O Manager manages all input and output for the operating system. A large part of the I/O Manager's role is to manage communications between drivers. The I/O Manager supports all file system drivers, hardware device drivers, and network drivers and provides an appropriate environment for each them. The I/O manager includes a formal, uniform interface that all types of drivers can call. This enables the I/O Manager to communicate with all drivers in the same way, without any knowledge of how the devices they control actually work.
The Windows NT I/O model uses a layered architecture that allows separate drivers to implement each logically distinct layer of I/O processing. For example, drivers in the lowest layer manipulate the computer's physical devices. Other drivers are then layered on top of the device drivers. These higher-level drivers do not know any details about the physical devices. With the help of the I/O Manager, higher-level drivers simply pass logical I/O requests down to the device drivers, which access the physical devices on their behalf. The Windows NT installable file systems and network redirectors are examples of high-level drivers that work in this way.
This scheme allows easy replacement of file system drivers and device drivers. It allows multiple file systems and devices to be active at the same time while being addressed through a formal interface.
Drivers communicate with each other using data structures called I/O Request Packets (IRPs). The drivers pass I/O request packets to the I/O Manager which delivers them to the target drivers using the drivers' standard services.
Windows NT 4.0 uses asynchronous I/O whenever possible to optimize application performance. When an application initiates an I/O operation, the application can continue processing while the I/O request is fulfilled. This differs from synchronous I/O, in which an application must stop processing until an I/O operation is complete.
Asynchronous I/O is efficient. Because most I/O devices are much slower than processors, an application can do a lot of work while the I/O operation is in progress. However, the application now needs to determine when I/O operations are complete. Some applications dedicate a wait thread to watch for the I/O. Others include an application procedure call (APC) that the I/O manager calls when the asynchronous I/O operation is complete. Other applications use synchronization objects, such as an event or the file handle, that the I/O system sets to the signaled state when the I/O operation is complete.
Windows NT 4.0 Workstation and Server now use Look-Aside Lists to help manage the amount of the nonpaged pool memory used by I/O Request Packets (IRPs). Look-Aside Lists replace the I/O zone used as the IRP memory management strategy for in Windows NT 3.51 and earlier versions. However, zones, which preallocate a fixed amount of physical memory, are still supported and used in other Windows NT drivers.
Look-Aside Lists keep track of the current number of entries freed from the nonpaged pool and an allowed maximum number of them. Space for the entries is allocated as needed from the Look-Aside List and counted against the maximum. If processes needs more than the maximum number of entries, space for them is allocated from the nonpaged pool, but the space is returned to the pool when the memory is released, not to the Look-Aside List. The maximum number of entries is based on the amount of physical memory in the system and whether it is a workstation or a server. For a given amount of physical memory, the maximum number of entries for servers is higher.
The I/O Manager processes requests from the I/O queue in order of priority, not in the order received. When an environment subsystem issues an asynchronous I/O request, the I/O Manager returns to the environment subsystem immediately after putting the request in a queue, without waiting for the device driver to complete its operations. Meanwhile, a separate I/O Manager thread administers the queue. When each I/O request is finished, the I/O Manager notifies the process that requested the I/O.
Figure 5.4 I/O Queueing
The I/O architecture includes a single Cache Manager that handles caching for the entire I/O system. Caching is a method used by a file system to improve performance. Instead of reading and writing directly to the disk, frequently used files are temporarily stored in a cache in memory, and reads and writes to those files are performed in memory.Cache Manager uses a file-mapping model that is closely integrated with Windows NT Virtual Memory Manager. Cache Manager provides caching services to all file systems and network components under the control of the I/O Manager. Cache Manager can dynamically increase and decrease the size of the cache as the amount of available physical memory varies. When a process opens a file that already resides in the cache, Cache Manager simply copies data from the cache to the process's virtual address space, and vice versa, as reads and writes are performed.
Cache Manager offers services such as lazy write and lazy commit, which can improve overall file system performance. Lazy write lets you record changes in the file structure cache, which is quicker than recording them on disk. Then later, when demand on the processors is low, Cache Manager writes the changes to the disk. Lazy commit is similar to lazy write: Instead of immediately marking a transaction as successfully completed, the system caches the committed information and later writes it to the file system log as a background process.
The I/O Manager routes communication to file system drivers. Windows NT 4.0 enables multiple NTFS (Windows NT File System) and FAT (File Allocation Table) systems to coexist in different logical partitions of the same physical device.
Note
Windows NT 4.0 does not support High Performance File System (HPFS), the file system designed for OS/2 1.x operating systems. Support for this file system ends with this release.
The I/O Manager treats file system drivers as just another device driver, routing messages for certain volumes to the appropriate software driver for that device adapter. When the I/O Manager cannot determine the file system for a volume, it forwards messages to the RAW default file system, which attempts to interpret requests and determine the appropriate low-level device driver before logging an error.
NTFS, the file system designed for Windows NT, supports many features, including file system security, Unicode, recoverability, long filenames, and POSIX. FAT, which is a simpler file system, supports long filenames, but not file system security. FAT is supported for backward compatibility with MS-DOS and Windows 3.x.
Windows NT 4.0 also supports Compact Disc Filing System (CDFS), an ISO9660-compliant file system for CD-ROM devices.
The Windows NT I/O architecture not only supports traditional file systems but has implemented its network redirector and server as file system drivers. The I/O Manager sees no difference between accessing files stored on a remote networked computer and accessing those stored locally on a hard disk. In addition, redirectors and servers can be loaded and unloaded dynamically, just like any other driver, and multiple redirectors and servers can coexist on the same computer.
For more information about supported file systems, see Chapter 18, "Choosing a File System." For more information about supported redirectors and servers, see Chapter 1, "Windows NT Networking Architecture," in the Windows NT Server Networking Guide.
Hardware device drivers are also components of the I/O architecture. Windows NT-compatible hardware device drivers—such as mouse drivers and disk drivers—are written in the C, C++, or Assembler programming language, are 32-bit addressable, and can be used with multiprocessor computers.
Device drivers access the hardware registers of the peripheral devices through entry points in Windows NT Executive dynamic link libraries. A set of these routines exists for every platform that Windows NT supports; because the routine names are the same for all platforms, the source code of Windows NT device drivers is portable across different processor types.
Designers of device drivers are encouraged to create separate drivers for different devices, rather than monolithic drivers, and the design of I/O Manager makes it easy to do so. This allows more flexibility to customize device configurations on the computer and to layer device drivers and other drivers.
For example, the Intel 8042 processor is an interface device: the keyboard and mouse communicate with the i8042 driver as well as with their own respective drivers. Three separate drivers are used — for the i8042, for the keyboard, and for the mouse — rather than one large monolithic driver. This makes it easier to change one component (exchanging the mouse for a different pointing device, for example).
A third type of driver implemented as a component in the I/O architecture is the network device driver. Windows NT includes integrated networking capabilities and support for distributed applications. Networking is supported by a series of network drivers.
Redirectors and servers are implemented as file system drivers and run at or below a provider interface layer where NetBIOS and Windows Sockets reside.
Transport protocol drivers communicate with redirectors and servers through a layer called the Transport Driver Interface (TDI). Windows NT includes a number of transports that communicate with the redirector:
Note
DLC, unlike the other protocols in Windows NT (NetBEUI, NWLink IPX/SPX, TCP/IP), is not designed to be a primary protocol for use between personal computers. DLC only provides applications with direct access to the data link layer, and thus is not used by the Windows NT redirector.
Figure 5.5 Networking Components in Windows NT
At the bottom of the networking architecture is the network adapter card device driver. Windows NT currently supports device drivers written to the Network Device Interface Specification (NDIS) version 3.0. NDIS allows for a flexible environment of data exchange between transport protocols and network adapters. NDIS 3.0 allows a single computer to have several network adapter cards installed in it. In turn, each network adapter card can support multiple transport protocols for access to multiple types of network servers.
For more information about network device drivers, see Chapter 1, "Windows NT Networking Architecture," in the Windows NT Server Networking Guide.