Article Information InstantDoc ID: 8303 April 2000, page 51 Related Article Inside Storage Management, Part 1 Print this article Email this article Reader Comments Comment on this article Related Topics Internals and Architecture Storage Management Windows 2000

I began this two-part series with a look at Windows NT 4.0's storage management architecture. I reviewed that architecture's reliance on DOS-style partitioning, its storage-driver architecture, and its use of NT device layering to implement enhancements such as software-based fault tolerance and performance monitoring. NT 4.0 storage management has two significant limitations: an upper limit of 26 volumes and a requirement to reboot the system whenever you change advanced storage settings. To be accessible, an NT 4.0 volume needs a drive letter in the A to Z range, which is where the 26-volume limit originates. Whenever you create a volume set, mirrored volume, stripe set, or stripe set with parity, you change the advanced storage configuration, and NT requires you to reboot for the new settings to take effect.

Windows 2000's (Win2K's) storage architecture has changed dramatically from NT 4.0, and the biggest changes are the removal of the two limitations I've just described. Along the way, Win2K has picked up a handful of other new storage-management features, such as Hierarchical Storage Management (HSM) capability. Delving into the details of Win2K's storage architecture will show you how Win2K has changed and improved NT 4.0's storage architecture.

To understand these improvements, you need to be familiar with the concepts I covered in part 1, including device objects and Object Manager symbolic links. I rely on the same terminology I used in part 1: A disk is a physical storage device that hardware divides into discretely addressable chunks called sectors, a partition is a contiguous group of sectors that the system can assign to volumes, and a volume is a collection of one or more partitions that a file system manages as one object.

Basic Disks vs. Dynamic Disks
Win2K introduces the concept of Basic and Dynamic disks. Basic disks are disks that rely on the DOS-style partitioning scheme that I described in part 1. In a sense, Basic disks are NT legacy disks. Dynamic disks are new to Win2K and implement a partitioning scheme that I describe later in this article. The difference between Basic and Dynamic disks lies in their support for advanced (multipartition) volumes. The Registry stores advanced-volume configuration information for Basic disks; storage of advanced-volume configuration information for Dynamic disks is on-disk. Storing advanced-volume configuration on-disk ties the Dynamic disk to the storage it describes, so losing advanced volume configuration data is harder and moving disks with advanced volumes between systems is easier.

Win2K manages all disks as Basic disks unless you manually create Dynamic disks or convert existing Basic disks (with enough free space) to Dynamic disks. To encourage administrators to use Dynamic disks, Microsoft has imposed some usage limitations on Basic disks. For example, you can create new advanced volumes only on Dynamic disks (if you upgrade an NT 4.0 system, Win2K will support existing advanced volumes). Another limitation is that Win2K lets you dynamically grow NTFS volumes only on Dynamic disks. A disadvantage to Dynamic disks is that the partitioning format they use is proprietary and incompatible with other OSs, including all other versions of Windows. Thus, you can't access Dynamic disks in a dual-boot environment. For several reasons, including the fact that laptop disks typically don't move easily between computers, Win2K uses only Basic disks on laptops.

Basic Disks
Although the way Win2K partitions Basic disks hasn't changed from the way NT 4.0 partitions disks, the way Win2K's device drivers manage Basic disks has changed. As they did in NT 4.0, storage devices in Win2K follow the class-port-miniport model. Also as in NT 4.0, Microsoft supplies disk.sys, a class driver that implements functionality common to disks. Microsoft provides a handful of disk port drivers for Win2K. For example, scsiport.sys is the port driver for disks on SCSI buses, and pciidex.sys is a port driver for IDE-based systems. Win2K 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, one driver—atapi.sys—combines port and miniport functionality. Most Win2K installations include one or more of the drivers I've mentioned.

Before I outline disk management in Win2K, let me review NT 4.0 disk management. In NT 4.0, the Disk class driver creates a device object with a name in the form \Device\HarddiskX\Partition0 to represent a physical disk; a number that uniquely identifies the disk replaces X. When the class driver detects a disk, the driver uses the I/O Manager function IoReadPartitionTable to scan the disk's partition table. For each partition it identifies, the class driver creates a device object under the disk's PartitionY Harddisk directory (Y is a number that identifies the partition). The I/O Manager function IoAssignDriveLetters creates symbolic links under the Object Manager's \?? subdirectory for each partition device object, and file systems mount the partition device objects as the system and applications access the partitions.

For Basic disks in Win2K, the Disk class driver still creates device objects that represent disks and partitions; however, the objects' naming and role are different than in NT 4.0. Device objects that represent disks have names of the form \Device\HarddiskX\DRX; the number that identifies the disk replaces both Xs. The class driver still uses IoReadPartitionTable to scan disks, but the partition device objects have more descriptive names. An example partition object name is \Device\Harddisk0\DP(1)0x7e00-0x7ff50c00+2. This name identifies the first partition on the first disk on a system. The two hexadecimal numbers (0x7e00 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 are familiar with NT 4.0 naming conventions, the Disk class driver creates symbolic links with NT 4.0-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 Win32 symbolic links in Win2K that represent physical drives that it created in NT 4.0. Thus, for example, the link \??\PhysicalDrive0 references \Device\Harddisk0\DR0. Screen 1 shows the WinObj utility viewing the contents of a Harddisk directory for a Basic disk. (You can download a copy of WinObj from http://sysinternals.com/winobj.htm.) You can see the physical disk and partition device objects in the right-hand pane.

In NT 4.0, the partition device objects that the Disk class driver creates have assigned drive letters and are mounted by file systems. Win2K does things differently. In Win2K, the FtDisk driver creates disk device objects that represent volumes on Basic disks. Win2K assigns drive letters to the volumes, which file systems mount. FtDisk is present in NT 4.0 only when you have at least one advanced volume; in Win2K, FtDisk plays an integral role in managing all Basic disk volumes, including volumes that aren't advanced. FtDisk uses the Basic disk configuration information that the Registry value HKEY_LOCAL_MACHINE\SYSTEM\Disk stores to determine what Basic volumes, advanced and otherwise, a system includes. For each volume, FtDisk creates a symbolic link of the form \Device\HarddiskVolumeX, where X is a number (starting with 1) that identifies the volume. The link refers to the partition device object that corresponds to the volume or to the first partition device object of a multipartition volume.

An interesting aspect of Win2K's version of FtDisk is that Win2K's FtDisk leverages Win2K's PnP subsystem with the aid of the Partition Manager (partmgr.sys) driver to determine what Basic disk partitions exist. Partition Manager registers with the PnP subsystem so that Win2K can inform Partition Manager whenever the Disk class driver creates a partition device object. Partition Manager informs FtDisk about new partition objects through a private interface and creates filter device objects that Partition Manager attaches to the objects. The existence of the filter objects prompts Win2K to inform Partition Manager whenever a partition device object is deleted so that Partition Manager can update FtDisk. The Disk class driver deletes a partition device object when you delete a partition in the Disk Management Microsoft Management Console (MMC) snap-in.

Win2K Basic volume drive-letter assignment, a process I'll describe shortly, creates drive-letter symbolic links under \?? that point to the volume device objects that FtDisk creates. When the system or an application accesses a volume for the first time, Win2K performs a mount operation that is identical to NT 4.0's mount process. Just as in NT 4.0, FtDisk intercepts I/O request packets (IRPs) that the system aims at multipartition volumes and handles them appropriately. For example, FtDisk splits read requests aimed at mirrored drives and services requests aimed at stripe sets by using derivative IRPs that FtDisk routes to specific partitions of the set. If the system directs an IRP to a nonadvanced volume, FtDisk simply forwards the request to the Disk class driver.

Dynamic Disks
As I've stated, Dynamic disks are Win2K's favored disk format and are necessary for creating new advanced volumes. Win2K's Logical Disk Manager (LDM) subsystem, which consists of user-mode and device-driver components, oversees Dynamic disks. Microsoft licenses LDM from VERITAS Software, which originally developed LDM technology for UNIX systems. Working closely with Microsoft, VERITAS ported its LDM to Win2K to provide Win2K with more robust partitioning and advanced volume capabilities. A major difference between LDM's partitioning and DOS-style partitioning is that LDM maintains one unified database that stores partitioning information for all the Dynamic disks on a system—including advanced volume configuration. LDM's UNIX version incorporates disk groups, in which all the Dynamic disks that the system assigns to a disk group share a common database. VERITAS' commercial volume management software for Win2K also includes disk groups, but Win2K's LDM implementation includes only one disk group.

The LDM database resides in a 1MB reserved space at the end of each Dynamic disk. The need for this space is why Win2K requires free space at the end of Basic disks before you can convert them to Dynamic disks. Although Dynamic disks' partitioning data resides in the LDM database, LDM implements a DOS-style partition table so that legacy disk-management utilities, including those that run under Win2K and under other OSs in dual-boot environments, don't mistakenly believe a Dynamic disk is unpartitioned. LDM also creates a DOS-style partition table so that Win2K's boot code can find the system and boot volumes, even if the volumes are on Dynamic disks (NT Loader—NTLDR—for example, knows nothing about LDM partitioning). If a disk contains the system or boot volumes, partitions describe the location of those volumes. Otherwise, one partition begins at the first cylinder of the disk (typically 63 sectors into the disk) and extends to the beginning of the LDM database. In the region this place-holding partition encompasses, LDM creates partitions that the LDM database organizes. Figure 1 illustrates this Dynamic disk layout.

The LDM database consists of four regions, which Figure 2 shows: a header sector that LDM calls the Private Header, a table of contents area, a database records area, and a transactional log area. The Private Header sector resides 1MB before the end of a Dynamic disk and anchors the database. You'll quickly notice as you spend time with Win2K that the OS uses GUIDs to identify just about everything, and disks are no exception. LDM assigns each Dynamic disk a GUID, and the Private Header sector notes the GUID of the Dynamic disk on which the sector resides (hence the Private Header's designation as information that is private to the disk). The Private Header also stores the name of the disk group, which is the name of the computer concatenated with Dg0 (i.e., DesktopDg0 if the computer's name is Desktop), and a pointer to the beginning of the database table of contents. For reliability, LDM keeps a copy of the Private Header in the disk's last sector.

The database table of contents is 16 sectors in size and contains information regarding the database's layout. LDM starts the database record area immediately after the table of contents, with a sector that serves as the database record header. This sector stores information about the database record area, including the number of records it contains, the name and GUID of the disk group the database relates to, and a sequence number identifier that LDM uses for the next entry it creates in the database. Sectors following the database record header contain 128-byte fixed-size records that store entries that describe the disk group's partitions and volumes.

A database entry can be one of four types: partition, disk, component, and volume. LDM uses the database entry types to identify three levels that describe volumes. LDM connects entries with internal object identifiers. At the lowest level, partition entries describe contiguous regions on a disk; identifiers stored in a partition entry link the entry to a component and disk entry. A disk entry represents a Dynamic disk that is part of the disk group and includes the disk's GUID. A component entry serves as a connector between one or more partition entries and the volume entry the partitions are associated with. A volume entry stores the GUID of the volume, the volume's total size, state, and a drive-letter hint. Disk entries that are larger than a database record span multiple records; partition, component, and volume entries rarely span multiple records.

LDM requires three entries to describe a simple volume: a partition entry, a component entry, and a volume entry. Figure 3 depicts the contents of a simple LDM database that defines one 200MB volume that consists of one partition. The partition entry describes the area on a disk that the system assigned to the volume, the component entry connects the partition entry with the volume entry, and the volume entry contains the GUID that Win2K uses internally to identify the volume. Advanced volumes require more than three entries. For example, a stripe set consists of at least two partition entries, a component entry, and a volume entry. The only volume type that has more than one component entry is a mirror; mirrors have two component entries, each of which represents one-half of the mirror. LDM uses two component entries for mirrors so that when you break a mirror, LDM can split it at the component level, creating two volumes with one component entry each. Because a simple volume requires three entries and the 1MB database contains space for approximately 8000 entries, the effective upper limit on the number of volumes you can create on a Win2K system is approximately 2500.

The final area of the LDM database is the transactional log area, which consists of a few sectors for storing backup database information as the information is modified. This setup safeguards the database in case of a crash or power failure because LDM can use the log to bring the database back to a consistent state.