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

Dynamic Disk Management
The MMC plugin DLL \winnt\system32\dmconfig.dll (DMConfig) creates and changes the contents of the LDM database. When you launch the Disk Management MMC snap-in, DMConfig loads into memory and reads the LDM database from each of the disks. If DMConfig detects a database from another computer's disk group, it notes that the volumes on the disk are foreign and lets you import them into the current computer's database if you want to use them. As you change the configuration of Dynamic disks, DMConfig updates an in-memory copy of the database that it passes to DMIO, the dmio.sys device driver. DMIO is the Dynamic disk equivalent of FtDisk, so it controls access to the on-disk database and creates device objects that represent the volumes on Dynamic disks.

DMIO doesn't know how to interpret the database it oversees. DMConfig and another device driver, dmboot.sys (DMBoot), are responsible for interpreting the database. DMConfig knows how to read and how to update the database; DMBoot knows only how to read the database. DMBoot loads during the boot process if another LDM driver, dmload.sys (DMLoad), determines that at least one Dynamic disk is present on the system. DMLoad makes this determination by asking DMIO, and if at least one Dynamic disk is present, DMLoad starts DMBoot, which scans the LDM database. DMBoot informs DMIO of the composition of each volume it encounters so that DMIO can create device objects to represent the volumes. DMBoot unloads from memory immediately after it finishes its scan. Because DMIO has no database interpretation logic, it is relatively small. Its small size is beneficial because DMIO is always loaded.

DMIO creates a device object for each Dynamic disk volume with a name in the form \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolumeX, where X is an identifier that DMIO assigns to the volume. In addition, DMIO creates another device object that represents raw (unstructured) I/O to a volume named \Device\HarddiskDmVolumes\PhysicalDmVolumes\RawVolumeX. Screen 2 shows the device objects that DMIO created on a system that consists of two Dynamic disk volumes. DMIO also creates numerous symbolic links in the Object Manager namespace for each volume, starting with one link in the form \Device\HarddiskDmVolumes\ComputerNameDg0\VolumeY for each volume. DMIO replaces ComputerName with the name of the computer and replaces Y with a volume identifier (different from the internal identifier that DMIO assigns to the device objects). These links refer to the block-device objects under the PhysicalDmVolumes directory.

DMIO's IRP management is virtually identical to FtDisk's because DMIO keeps track of the partitions that constitute a volume and the type of volume a device object represents. However, because the Disk class driver is aware only of DOS-style partitions, DMIO must perform the simple partition-to-disk translations that FtDisk lets the Disk class driver handle. When the system or an application performs a file-system-related operation for a Dynamic volume, the file-system driver managing the data on the volume forwards an IRP to the DMIO device object that represents the volume. If the IRP's target is a simple volume, DMIO adjusts the IRP's partition-relative offset to a disk-relative offset and hands the IRP to the Disk class driver. However, if the IRP is aimed at an advanced volume, DMIO might create additional IRPs or perform more complex offset and length adjustments. For example, if DMIO receives an IRP that designates a write operation to a mirrored volume's device object, DMIO sends an IRP to the Disk class driver's physical disk device objects for the disks on which both halves of the mirror reside.

One type of advanced volume that is present in Win2K is a volume set, which is similar to NT 4.0's volume set but can be extended without rebooting. New support in NTFS for extending the size of a volume, including resizing metadata files, makes this extension possible. DMIO also fully supports the creation of advanced volumes such as mirrors and stripe sets without requiring a reboot.

Reparse Points
I've highlighted Win2K's freedom from drive letters as one of the compelling features of the OS's new storage management architecture. A new mechanism, mount points, lets you link volumes through directories on NTFS volumes, which makes volumes with no drive-letter assignment accessible. For example, an NTFS directory that you've named C:\Projects could mount another volume (NTFS or FAT) that contains your project directories and files. If your project volume had a file you named \CurrentProject\Description.txt, you could access the file through the path C:\Projects\CurrentProject\Description.txt. What makes mount points possible is reparse point technology.

A reparse point is a block of arbitrary data with some fixed header data that Win2K associates with an NTFS file or directory. An application or the system defines the format and behavior of reparse points, including the value of the unique reparse point tag that identifies the application's or system's reparse points and the size and meaning of the data portion of a reparse point (the data portion can be as large as 16KB). Reparse points store their unique tag in a fixed segment. Any application that implements a reparse point must supply a file-system filter driver to watch for reparse-related return codes for file operations that execute on NTFS volumes, and the driver must take appropriate action when it detects the codes. NTFS returns a reparse status code whenever it processes a file operation and encounters a file or directory with an associated reparse point.

The Win2K NTFS file-system driver, the I/O Manager, and the Object Manager all partly implement reparse point functionality. The Object Manager initiates pathname-parsing operations by using the I/O Manager to interface with file-system drivers. Therefore, the Object Manager must retry operations for which the I/O Manager returns a reparse status code. The I/O Manager implements pathname modification that mount points and other reparse points might require, and the NTFS file-system driver must associate and identify reparse point data with files and directories. You can therefore think of the I/O Manager as the reparse point file-system filter driver for many Microsoft-defined reparse points.

An example of a reparse point application is an HSM system that uses reparse points to designate files that an administrator moves to offline tape storage. When a user tries to access an offline file, the HSM filter driver detects the reparse status code that NTFS returns, communicates with a user-mode service to retrieve the file from offline storage, deletes the reparse point from the file, and lets the file operation retry after the service retrieves the file. This process describes exactly how Win2K's Remote Storage Manager (RSM) filter driver, rsfilter.sys, uses reparse points.

If the I/O Manager receives a reparse status code from NTFS and the file or directory for which NTFS returned the code isn't associated with one of a handful of built-in Win2K reparse points, then no filter driver claimed the reparse point. The I/O Manager then returns an error to the Object Manager that propagates as a File cannot be accessed by the system error to the application making the file or directory access.

Junctions and Mount Points
Microsoft decided not to implement a symbolic link feature for files in NT because many Windows programs won't behave properly when using such a feature. For example, when deleting a file that is a symbolic link, a Windows program would inadvertently delete the target of the link, rather than the link itself.

Virtually every UNIX OS uses symbolic links, in which accessing a file or directory symbolic link resolves to another file or directory. NT has always supported symbolic links in the Registry, and NT makes extensive use of symbolic links in the Object Manager's namespace. However, until Win2K, no NT file system has supported symbolic links. Win2K introduces directory symbolic links, which Microsoft calls NTFS junctions. A junction is a Microsoft-defined reparse point that you can associate with an empty NTFS directory. The data that the reparse point stores is the name of another directory somewhere on the system. When you access a path that crosses a junction, NTFS returns a reparse status code to the I/O Manager for the directory associated with the junction, and the I/O Manager recognizes the reparse point as a junction. The I/O Manager retrieves the directory name that the junction's reparse data specifies and invokes an internal function, IopDoNameTransmogrify. This function alters the pathname that the original request specified and returns a reparse status code to the Object Manager. Upon seeing the reparse status code, the Object Manager reissues the request with the redirected pathname, and NTFS performs the new lookup.

Win2K doesn't include any tools for making junctions. You can use linkd, a Windows 2000 Resource Kit program, to create junctions, or you can download Junction, a linkd clone that I wrote, from http://sysinternals.com/misc.htm.

Mount points are similar to junctions—they even share the same reparse tag—but the data that mount points store is a volume name (i.e., \??\Volume{X}) instead of a directory. When you use the Disk Manager MMC snap-in to assign or remove path assignments for volumes, you're creating mount points. You can also use the built-in command-line tool mountvol to create and display mount points.

The Mount Manager
Drive-letter assignment is another aspect of storage management that changed in Win2K. NT 4.0 stores drive-letter assignments in HKEY_LOCAL_MACHINE\SYSTEM\Disk, and the NT I/O Manager executes the IoAssignDriveLetters function during the boot. IoAssignDriveLetters initiates an assignment process that creates drive-letter symbolic links in the \?? Object Manager directory and honors any assignments you've made from Disk Administrator.

IoAssignDriveLetters in Win2K works much as it does in NT 4.0, but the function assigns drive letters only for volumes on Basic disks because only those volumes rely on the DOS-style partitioning that NT 4.0 uses. A new driver in Win2K, the Mount Manager (mountmgr.sys), assigns drive letters for Dynamic disk volumes and for Basic disk volumes you create after the system has started. Win2K stores all drive-letter assignments under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. If you look under that key, you'll see values with names such as \??\Volume{X} (where X is a GUID) and values such as \??\C:. Every volume has a volume name entry, but a volume need not have an assigned drive letter. Screen 3 shows the contents of an example Mount Manager Registry key.

The data that the Registry stores in values for Basic disk volume drive letters and volume names is the NT 4.0-style disk signature and the starting offset of the first partition associated with the volume. The data that the Registry stores in values for Dynamic disk volumes includes the volume's DMIO internal GUID. When the Mount Manager initializes during the boot process, it registers with the Win2K PnP subsystem so that it receives notification whenever either FtDisk or DMIO creates a volume. When the Mount Manager receives such a notification, it determines the new volume's GUID or disk signature, then asks either FtDisk or DMIO (whichever created the volume) for a suggested drive-letter assignment. FtDisk queries the NT 4.0 HKEY_LOCAL_MACHINE\SYSTEM\Disk key (in case the system is an NT 4.0 upgrade that had previous drive-letter assignments), and DMIO looks at the drive-letter hint in the volume's database entry. If no suggested drive-letter assignment exists for the volume, the Mount Manager uses the volume GUID or signature as a guide and looks in its internal database, which reflects the contents of the Registry key. Then, the Mount Manager determines whether its internal database contains the drive-letter assignment. If not, the Mount Manager uses the first unassigned drive letter (if one exists), defines a new assignment, creates a symbolic link for the assignment (e.g., \??\D), and updates the MountedDevices Registry key. At the same time, the Mount Manager creates a volume symbolic link (i.e., \??\Volume{X}) that defines a new volume GUID, if the volume doesn't already have one. This GUID is different from the volume GUIDs that DMIO uses internally.

The Mount Manager also maintains the Mount Manager Remote Database on every NTFS volume, in which the Mount Manager records any mount points defined for that volume. The database file, :$MountMgrRemoteDatabase, resides in the NTFS root directory. Mount points move when a disk moves from one system to another and in dual-boot environments (i.e., when booting between multiple Win2K installations) because of the Mount Manager Remote Database's existence. NTFS also keeps track of mount points in the NTFS metadata file \$Extend\$Reparse. NTFS stores mount-point information in the metadata file so that Win2K can easily enumerate the mount points defined for a volume when a Win32 application, such as the Disk Manager, requests mount-point definitions.

Dynamic Disks
Mount points, HSM, on-disk storage of disk configuration, and junctions are powerful features that make Win2K a compelling upgrade from NT 4.0. The LDM and Dynamic disks, with their ability to support the creation of advanced volumes and dynamic growth of existing volumes without reboots, bring Win2K on par with advanced UNIX systems for enterprise storage management.