Section 6.2. Volumes and Volume Managers

   

---

6.2 Volumes and Volume Managers

As explained earlier in this chapter, volumes are an abstraction built on top of disk partitions. The disk partitions themselves may be soft partitions (existing on dynamic disks) or hard partitions (built on top of basic disks). Volumes are implemented in the Windows Server family by a device driver generically referred to as a volume manager . Volume managers and how they fit into the Windows storage stack were discussed in Chapter 1. This section concentrates on describing the functionality of volumes in the post-Windows 2000 world and relates that functionality to the three specific volume managers that are available for the Windows operating system in the post-Windows 2000 world:

• The FtDisk Manager that ships natively with Windows 2000 and Windows Server 2003. In Windows NT 4.0, the FtDisk driver was only optionally loaded because it dealt only with enhanced volume functionality such as fault tolerance. In Windows 2000, FtDisk is always loaded because it handles all volumes on basic disks.

• The Logical Disk Manager ( LDM ) that ships natively with Windows 2000 and Windows Server 2003.

• The VERITAS Logical Volume Manager ( LVM ) that is available from VERITAS as a commercial product and functionally is a superset of the Logical Disk Manager.

All of the volume managers listed here provide functionality that can be summarized as follows :

• Storage virtualization wherein a file system does not need to know which physical disk the file system is residing on. The volume manager also can concatenate multiple partitions from multiple disks into a single larger volume.

• Data protection by storing data redundantly (using some form of RAID; RAID is described in Chapter 9) or storing the data with a checksum.

• Performance by storing data in a way that it can be retrieved efficiently .

Table 6.1 summarizes the capabilities of the three major volume managers available for Windows 2000 and Windows Server 2003 products.

LDM and LVM are referred to as if they were a single entity, but each one is implemented as four different drivers, each with a varying amount of functionality. The idea is to reduce code size and complexity for normal runtime situations. In reality, LDM and LVM are implemented as four different drivers:

1. DMConfig is a driver that can read and update the LDM database. When any configuration changes are made, DMConfig reflects the change in a memory copy of the database. The corresponding driver for LVM is called VxConfig .

2. DMIO (dmio.sys) is the equivalent of FtDisk and implements the volume manager functionality for normal data read and write operations to the partitions. DMIO also creates the volume device objects. DMIO size is reduced because it does not have code to read or write the LDM database or interpret the LDM on disk format. The corresponding driver for LVM is called VxIO .

3 and 4. DMBoot (dmboot.sys) can only read the LDM database. DMBoot is loaded if a fourth driver, DMLoad (dmload.sys), determines that there are one or more dynamic disks present. Both of these are boot time “only drivers. The corresponding drivers for LVM are called VxBoot and VxLoad .

When a basic disk is converted to a dynamic disk, the old entities are transformed into new entities, as detailed in Table 6.2.

Windows 2000 introduced remarkable changes in the way volumes are managed. For example, Windows 2000 not only removes the limitation of 26 volumes, but also allows volumes to appear and disappear dynamically without requiring a system reboot. To implement these volume management changes, two new system components ”the Partition Manager and the Mount Manager ”were introduced. Sections 6.2.1 through 6.2.4 describe these two components , as well as the new volume management functionality.

Table 6.1. Volume Manager Capabilities

Feature	FtDisk Manager	Microsoft Logical Disk Manager ( LDM )	VERITAS Logical Volume Manager ( LVM )
Simple volumes (all partitions on single physical disk)	Yes	Yes	Yes
Spanned volumes (partitions that exist across multiple physical disks combined)	No	Yes	Yes
RAID 0 (striping)	Yes	Yes	Yes
RAID 1 (mirroring)	Yes	Yes	Yes
RAID 10	No	No	Yes
Maximum number of partitions that can be combined into a volume	32	32	256
Online volume creation	No	Yes	Yes
Online growth of simple and spanned volumes	No	Yes	Yes
Online growth of RAID volumes	No	No	Yes
Mirroring support	No	No	Yes, for up to 32-way mirroring
Clustering support	No	No	Yes
Multiple disk group support	No	No	Yes

Table 6.2. Windows NT 4.0 and Windows 2000 Volume Terminology

Old Entity in Windows NT 4.0	Equivalent New Entity in Windows 2000
System partition	Simple volume
Boot partition	Simple volume
Volume set	Spanned volume (a volume built out of up to 32 partitions that can exist on one or more physical disks)
Striped set	Striped volume (a RAID 0 volume built out of up to 32 partitions) [a]
Mirror set	Mirror volume (a RAID 1 volume built out of up to 32 partitions) [a]
Stripe set with parity	RAID 5 [a]

^[a] See Chapter 9 for a description of RAID, including RAID 0, RAID 1, and RAID 5.

6.2.1 Partition Manager

The Partition Manager is a driver newly introduced in Windows 2000 and also present in Windows XP and Windows Server 2003. The Partition Manager is an upper filter driver (filter drivers are described in Chapter 1) that registers with the Windows NT Plug and Play (PnP) subsystem requesting notifications for new device objects created by the disk class driver.

The Partition Manager communicates with the volume managers in general using a private interface, and it forwards notifications of device creation to the volume managers. When a volume manager finds that it has all disk partitions that collectively constitute a volume, it creates a device object representing the volume. The Partition Manager also notifies PnP of partition or device object destruction (e.g., when deleting a partition). The Partition Manager communicates with the volume managers to inform them about partitions that dynamically come and go. The functioning of the Partition Manager is further explored in Sections 6.2.3 and 6.2.4.

6.2.2 Mount Manager

The Mount Manager is a driver newly introduced in Windows 2000 and also present in Windows XP and Windows Server 2003. The Windows NT Mount Manager (mountggr.sys) offers functionality to provide storage management for volumes. This storage management functionality consists of

• Mounting volumes

• Dismounting volumes

• Keeping track of volume mount points and drive letters in a database file called :$MountMgrRemoteDatabase, which is present in the root directory of every NTFS volume

• Creating and destroying namespaces (and their associations) that make volumes visible to user mode applications

Not surprisingly, the Mount Manager depends on Plug and Play to be notified of events that signal volume arrival and removal. For volume mount operations, the Mount Manager consults the appropriate volume manager using the private interface. If the volume is on a basic disk, the volume manager will be FtDisk, which will consult the registry it maintains to suggest a drive letter. If the volume is on a dynamic disk, the volume manager will be LDM, which will consult the mount point information maintained in the LDM database on the dynamic disk.

The Mount Manager maintains a database of (unique) volume IDs that it has encountered before, as well as the path or drive letter on which the volume was previously mounted. When the Mount Manager is notified of the arrival of a volume and the volume manager fails to suggest a mount point, the Mount Manager consults this database and attempts to use the same drive letter or path that was used the last time the volume was mounted. If there is no entry for this volume in the Mount Manager database, or if the suggested mount point is already in use, the Mount Manager assigns the drive a new mount point. Upon device removal, the Mount Manager is also responsible for dismounting the volume. However, the entry is not deleted in the database.

The Mount Manager is responsible for assigning drive letters, as needed, for volumes on basic disks (but only for basic disks that arrive after the system has been started). The Mount Manager assigns drive letters, starting from the drive letter C:, in a prioritized fashion. Legacy fault-tolerant volume sets ^[3] have the highest priority, followed by a primary partition on a fixed disk, followed by removable disks (e.g., Jazz, USB), followed by CD-ROM disks. Once all of these have been taken care of, floppy disk volumes are assigned a drive letter starting with the drive letter A:. CD-ROM drive volumes are assigned a drive letter starting with the drive letter D:.

^[3] A drive letter assigned to a fault-tolerant volume set is stored on the volume set. When the fault-tolerant volume set is migrated , the drive letter is noted.

The Mount Manager stores the assigned drive letter in the registry, ensuring that it is "sticky" in the sense that if the system configuration is changed, each partition is assigned the same drive letter it previously had. The Mount Manager does not enforce drive letter protection for partitions that are offline. Thus if a partition is assigned a drive letter and is then taken offline, the same drive letter may be reassigned to a different partition that comes online for the first time. ^[4]

^[4] For the gory details, see Microsoft Knowledge Base article number 234048, titled "How Windows 2000 Assigns, Reserves, and Stores Drive Letters."

Mount Manager operations can be controlled from the command-line utility mountvol.exe. With Windows Server 2003, Mount Manager functionality has been updated so that an application may optionally refuse to mount volumes that have never been seen on a particular system before. This is a somewhat lame attempt to provide functionality equivalent to the UNIX mount table. The idea is to prevent accidental volume corruption when a volume is exposed to a Windows system by mistake.

6.2.3 Device Tree for Volumes on Basic Disks

Once we understand the abstraction and functionality provided by volumes, it is interesting to see how volumes are handled in the storage device I/O stack. This section presents details of the storage I/O stack for a volume on a basic disk, and Section 6.2.4 presents details of the storage I/O stack for a volume on a dynamic disk.

Chapter 1 discussed the device tree for a simple volume on basic disks where the volume is built on top of only a single (hard) partition. Note that FtDisk supports legacy volumes built out of multiple partitions. In reality, the code to support volumes built out of multiple partitions is in FtDisk. Starting with Windows 2000, the tools to build a nonsimple volume on basic disks have been withdrawn.

Consider Figure 6.3. Starting from the bottom right-hand corner, the PnP subsystem and PCI bus drivers cooperate to create the PDO (physical device object) and FDO (functional device object) for the PCI bus. Next the PCI bus driver enumerates devices on the PCI bus and creates a PDO for the SCSI adapter. The SCSIPort driver creates the FDO for the SCSI adapter. Next the SCSIPort driver creates a PDO for the one disk present in the system, and the disk class driver creates an FDO for that disk.

Figure 6.3. Device Object Tree for a Legacy Spanned Volume on a Basic Disk

The Partition Manager watches the IRPs go by and ensures that it is in the I/O path for IRP completion. When the Partition Manager sees a IRP_MN_QUERY_DEVICE_RELATIONSHIPS request being completed, it quietly removes all details of relevant (disk) devices discovered. In this case, that would be the device objects for the two partitions, Partition 0 and Partition 1, that were created by the disk.sys disk class driver. Hence the two device objects, Partition 0 and Partition 1, are never discovered by the PnP subsystem at all. That's why the device objects for Partition 0 and Partition 1 are shaded differently from the other device objects in Figure 6.3.

The Partition Manager passes details of the device objects it discovers (and "steals") to registered volume managers. When volume managers initialize, they register with the I/O subsystem. The Partition Manager calls each volume manager in turn , passing them information about the disk device objects it trapped in the IRP_MN_QUERY_DEVICE_RELATIONSHIPS request. The volume managers inspect the disk device objects "stolen" by the Partition Manager and either claim or reject ownership. The FtDisk manager claims ownership of all volumes not claimed by other volume managers.

In the example shown in Figure 6.3, the FtDisk driver claims ownership of these device objects. The FtDisk manager then inspects the volume configuration and determines that the volume has two underlying partitions, and it claims ownership of both the partitions. At this point the FtDisk driver creates a device object to represent the volume (called Volume V01 in Figure 6.3). The file system can then be mounted on this volume.

What is noteworthy here is that there are actually two separate device stacks. One stack represents the logical entity, the volume; the other stack encompasses the physical devices in the system, such as the PCI bus, the SCSI adapter, and the disk drive. The volume manager acts as a bridge between the two stacks.

In Figure 6.3, the FtDisk driver sends all IRPs that it understands directly to the disk class driver. Of course, the FtDisk driver also transforms volume-relative offsets to disk-relative offsets before it does so. In addition, IOCTLs that the FtDisk driver does not understand are sent to either Partition 0 or Partition 1 as appropriate.

6.2.4 Device Tree for Volumes on Dynamic Disks

It is worthwhile examining the device tree for volumes on dynamic disks because there are some subtle differences from volumes on basic disks. Figure 6.4 shows the device tree for volumes on dynamic disks.

Figure 6.4. Device Tree for a Volume on a Dynamic Disk

In the interest of keeping things simple and understandable, the volume considered here is a truly soft volume, existing on the dynamic disk. The dynamic disk does not have any operating system boot or system partitions. Thus the dynamic disk has a Master Boot Record (MBR) showing the whole disk to be a single partition. Of course, the LDM database exists on the last 1MB of space on the dynamic disk.

Figure 6.4 shows the two separate device trees that should by now be familiar: a physical device tree on the right and a logical device tree on the left, with the Logical Disk Manager spanning the gap between the two. Starting from the bottom right-hand corner of Figure 6.4, we have the PDO/FDO pair representing the PCI bus. Moving up from there, we have the PDO/FDO pair for the SCSI adapter. In this example, two dynamic disks are present. The next layer up shows the PDO/FDO pair for the two physical disks present in the system. The Partition Manager is layered over the two disk FDOs created by the disk class driver.

The Partition Manager registers a completion routine for all IRPs that it sees. In the completion routine, it pays special attention to the IRP_MN_QUERY_DEVICE_RELATIONSHIPS IRP and in particular watches for disk device objects being reported . The disk class driver, acting as a bus driver, creates a device object to represent the one partition representing each dynamic disk. The Partition Manager forwards information about these disk device objects to the registered volume managers in the system. In this example, the only volume manager shown is the LDM, which is loaded as a root-enumerated logical driver. In this case the LDM will claim responsibility for the disk device objects. Assume that the volume in question is constructed by concatenation of the two disks, to create a single large volume. The LDM inspects the volume configuration, and when it is satisfied that it has ownership of all underlying partition objects, it creates a device object representing the volume, called Volume V01 in this example.

The LDM directs I/O from the volume object to either disk, as appropriate. Note that the two partition objects ”Partition 0 for Disk 1 and Partition 0 for Disk 2 ”are never reported to PnP and hence are shown with no connections to other objects.

---

Top