Disk Drivers

 < Day Day Up > 

The device drivers involved in managing a particular storage device are collectively known as a storage stack. Figure 10-1 shows each type of driver that might be present in a stack and includes a brief description of their purpose. This chapter describes the behavior of device drivers below the file system layer in the stack. (The file system driver operation is described in Chapter 12.)

Figure 10-1. Windows storage stack


Ntldr

As you saw in Chapter 4, Ntldr is the Windows operating system file that conducts the first portion of the Windows boot process. Although Ntldr isn't technically part of the storage stack, it is involved with storage management because it includes support for accessing disk devices before the Windows I/O system is operational. Ntldr resides on the system volume; the boot-sector code on the system volume executes Ntldr. Ntldr reads the Boot.ini file from the system volume and presents the computer's boot choices to the user. The partition names that Boot.ini designates are in the form multi(0)disk(0)rdisk(0)partition(1). These names are Advanced RISC Computing (ARC) names because they're part of a standard partition-naming scheme that Alpha firmware and other RISC processors use. Ntldr translates the name of the Boot.ini boot entry that a user selects to the appropriate boot partition and then loads the Windows system files (starting with the registry, Ntoskrnl.exe, and the boot drivers) into memory to continue the boot process. In all cases, Ntldr uses the computer firmware to read the disk containing the system volume, but as described in Chapter 4, sometimes Ntldr relies on functions in a disk miniport driver to read from the boot volume's disk.

Disk Class, Port, and Miniport Drivers

During initialization, the Windows I/O manager starts the hard-disk storage drivers. Storage drivers in Windows follow a class/port/miniport architecture, in which Microsoft supplies a storage class driver that implements functionality common to all storage devices and a storage port driver that implements functionality common to a particular bus such as a Small Computer System Interface (SCSI) bus or an Integrated Device Electronics (IDE) system and OEMs supply miniport drivers that plug into the port driver to interface Windows to a particular implementation.

In the disk storage driver architecture, only class drivers conform to the standard Windows device driver interfaces. Miniport drivers use a port driver interface instead of the device driver interface, and the port driver simply implements a collection of device driver support routines that interface miniport drivers to Windows. This approach simplifies the role of miniport driver developers and, because Microsoft supplies operating system specific port drivers, gives miniport drivers binary portability between Microsoft Windows 98, Microsoft Windows Millennium Edition, and Windows.

Windows includes Disk (\Windows\System32\Drivers\Disk.sys), a class driver that implements functionality common to disks. Windows also provides a handful of disk port drivers. For example, Scsiport.sys is the port driver for disks on SCSI buses, and Atapi.sys is a port driver for IDE-based systems. Windows Server 2003 introduces the Storport.sys port driver as a replacement for Scsiport.sys. Storport.sys was designed to realize the high performance capabilities of hardware RAID and Fibre Channel adapters. The Storport model is similar to Scsiport, making it easy for vendors to migrate existing SCSI miniport drivers to Storport. Miniport drivers that developers write to use Storport take advantage of several of Storport's performance enhancing features, including support for the parallel execution of I/O initiation and completion on multiprocessor systems, more controllable I/O request-queue architecture, and execution of more code at lower IRQL to minimize the duration of hardware interrupt masking.

The Scsiport.sys and Atapi.sys drivers both implement a version of the disk scheduling algorithm known as C-LOOK. The drivers place disk I/O requests in lists sorted by the first sector (also known as the logical block number or LBN) at which an I/O request is directed. They use the KeInsertByKeyDeviceQueue and KeRemoveByKeyDeviceQueue functions (documented in the Windows DDK) representing I/O requests as items and using a request's starting sector as the key required by the functions. When servicing requests, the drivers proceeed through the list from lowest sector to highest. When they reach the end of the list the driver starts back at the beginning, since new requests might have been inserted in the meantime. If disk requests are spread throughout a disk this approach results in the disk head continuously moving from near the start of a disk torward the end. Storport.sys does not implement disk scheduling since it is commonly used for managing I/O's directed at storage arrays where there is no clearly-defined notion of a disk start and end.

Windows ships with several miniport drivers, including one Aha154x.sys for Adaptec's 1540 family of SCSI controllers. On systems that have at least one ATAPI-based IDE device, Pciidex.sys and Pciide.sys together provide miniport functionality. Most Windows installations include one or more of the drivers mentioned.

iSCSI Drivers

The development of iSCSI as a disk transport protocol integrates the SCSI protocol with TCP/ IP networking so that computers can communicate with block-storage devices, including disks, over IP networks. Storage area networking (SAN) is usually architected on Fibre Channel networking, but administrators can leverage iSCSI to create relatively inexpensive SANs from networking technology such as gigabit Ethernet to provide scalability, disaster protection, efficient backup, and data protection. Windows support for iSCSI comes in the form of the Microsoft iSCSI Software Initiator, which can be downloaded from the Microsoft Web site and which works on Windows 2000, Windows XP, and Windows Server 2003.

The Microsoft iSCSI Software Initiator includes several components:

  • Initiator This optional component, which consists of an iSCSI port driver (\Windows\System32\Drivers\Iscsiprt.sys) and miniport driver (\Windows\System32\Drivers\Msiscis.sys), uses the TCP/IP driver to implement software iSCSI over standard Ethernet adapters and TCP/IP offloaded network adapters.

  • Initiator service This service, implemented in \Windows\System32\Iscsiexe.exe, manages the discovery and security of all iSCSI initiators as well as session initiation and termination. iSCSI device discovery functionality is implemented in \Windows\System32\Iscsium.dll and conforms to the Internet Storage Name Service (iSNS) protocol.

  • Management applications These include Iscsicli.exe, a command-line tool for managing iSCSI device connections and security, and the corresponding Control Panel application.

Some vendors produce iSCSI adapters that offload the iSCSI protocol to hardware. The Initiator service works with these adapters, which must support iSNS, so that all iSCSI devices, including those discovered by the Initiator service and those discovered by iSCSI hardware, are recognized and managed through standard Windows interfaces.

Multipath I/O (MPIO) Drivers

Most disk devices have one path or series of adapters, cables, and switches between them and a computer. Servers requiring high levels of availability use multipathing solutions, where more than one set of connection hardware exists between the computer and a disk so that if a path fails the system can still access the disk via an alternate path. Without support of the operating system or disk drivers, however, a disk with two paths, for example, appears as two different disks. Windows includes multipath I/O support to manage multipath disks as a single disk that relies on third-party drivers called device-specific modules (DSMs) to manage details of the path management, such as load balancing policies that choose which path to route requests and error detection mechanisms to inform Windows when a path fails. MPIO support is available for Windows 2000 Server, Advanced Server, and Datacenter Server as well as Windows Server 2003 in the form of the Microsoft MPIO Driver Development Kit that hardware and software vendors can license.

In a Windows MPIO storage stack, shown in Figure 10-2, the Multipath Disk Driver Replacement (\Windows\System32\Drivers\Mpdev.sys) replaces the functionality of the standard Disk.sys class driver. Mpdev.sys is responsible for claiming ownership of device objects representing multipath disks so that it can ensure that only one device object is created to represent those disks and for locating the appropriate DSM to manage the paths to the device. The Multipath Bus Driver (\Windows\System32\Drivers\Mpio.sys) manages connections between the computer and the device, including power management for the device. Mpdev.sys informs Mpio.sys of the presence of the devices for it to manage. Finally, the Multipath Port Filter (\Windows\System32\Drivers\Mpsfltr.sys) layers on top of the port driver for a multipath disk to manage information passed up the device stack.

Figure 10-2. Windows MPIO storage stack


EXPERIMENT: Watching Physical Disk I/O

Diskmon from Sysinternals uses the disk class driver's Event Tracing for Windows (or ETW, which is described in Chapter 3) instrumentation to monitor I/O activity to physical disks and display it in a window. Diskmon updates once a second with new data. For each operation, Diskmon shows the time, duration, target disk number, type and offset, and length.




Disk Device Objects

The Windows disk class driver creates device objects that represent disks and partitions. Device objects that represent disks have names of the form \Device\ HarddiskX\DRX; the number that identifies the disk replaces both Xs. The disk class driver uses the I/O manager's IoReadPartitionTable function in Windows 2000 and IoReadParititionTableEx function in Windows XP and Windows Server 2003 to identify partitions and create device objects that represent them. As miniport drivers present the disks that they identify early in the boot process to the disk class driver, the disk class driver invokes the IoReadPartitionTable or IoReadPartitionTableEx function for each disk. These functions invoke sector-level disk I/O that the class, port, and miniport drivers provide to read a disk's MBR-style or GPT-style partition table (described later in this chapter) and construct an internal representation of the disk's hard partitioning. The disk class driver creates device objects to represent each primary partition (including logical drives within extended partitions) that the driver obtains from IoReadPartitionTable or IoReadPartitionTableEx. The following is a sample partition object name:

\Device\Harddisk0\DP(1)0x7e000-0x7ff50c00+2

This name identifies the first partition on a system's first disk. The first two hexadecimal numbers (0x7e000 and 0x7ff50c00) designate the start and length of the partition, and the last number is an internal identifier that the class driver assigns.

To maintain compatibility with applications that use the Windows NT 4 naming conventions, the disk class driver creates symbolic links with Windows NT 4 formatted names that refer to the device objects the driver created. For example, the Disk class driver creates the link \Device\Harddisk0\Partition0 to refer to \Device\Harddisk0\DR0, and \Device\Harddisk0\ Partition1 to refer to the first partition device object of the first disk. The class driver also creates the same symbolic links in Windows that represent physical drives that it created in Windows NT 4 systems. Thus, for example, the link \??\PhysicalDrive0 references \Device\Harddisk0\ DR0. Figure 10-3 shows the Winobj utility from Sysinternals displaying the contents of a Harddisk directory for a basic disk. You can see the physical disk and partition device objects in the right-hand pane.

Figure 10-3. Winobj showing a Harddisk directory of a basic disk


As you saw in Chapter 3, the Windows API is unaware of the Windows object manager namespace. Windows reserves two different namespace subdirectories to use, one of which is the \Global?? (\?? on Windows 2000) subdirectory. (The other is the \BaseNamedObjects subdirectory, which is covered in Chapter 3.) In this subdirectory, Windows makes available device objects that Windows applications interact with including COM and parallel ports as well as disks. Because disk objects actually reside in other subdirectories, Windows uses symbolic links to connect names under \Global?? with objects located elsewhere in the namespace. For each physical disk on a system, the I/O manager creates a \Global??\PhysicalDriveX link that points to \Device\HarddiskX\Partition0. (Numbers, starting from 0, replace X.) Windows applications that directly interact with the sectors on a disk open the disk by calling the Windows CreateFile function and specifying the name \\.\PhysicalDriveX (in which X is the disk number) as a parameter. The Windows application layer converts the name to \Global??\PhysicalDriveX before handing the name to the Windows object manager.

Partition Manager

The Partition Manager, \Windows\System32\Drivers\Partmgr.sys, is responsible for notifying the Plug and Play (PnP) manager of the existence of partitions so that volume manager drivers, described later in this chapter, can receive notification of the creation and deletion of partitions.

To become aware of partitions, Partition Manager acts as the function driver for disk device objects created by disk class drivers. When the system boots, it reads the partition tables of attached disks (by relying on the kernel's IoReadPartitionTable function on Windows 2000 and IoReadPartitionTableEx on Windows XP and Windows Server 2003) and reports their existence to the PnP manager. Volume manager device drivers receive the notification of partitions for disks that they manage and define volume objects when they account for all the partitions that make up the volumes. Because Partition Manager's device object's filter disk device objects, Partition Manager monitors I/O request packets (IRPs) related to partition table modification and can therefore update its internal partition map and notify the PnP manager of partition creations and deletions.

     < Day Day Up > 


    Microsoft Windows Internals
    Microsoft Windows Internals (4th Edition): Microsoft Windows Server 2003, Windows XP, and Windows 2000
    ISBN: 0735619174
    EAN: 2147483647
    Year: 2004
    Pages: 158

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net