The Volume Namespace
Drive-letter assignment is an aspect of storage management that changed significantly from Windows NT 4 to Windows 2000. Even so, Windows 2000 includes support for migrating drive-letter assignments made in a Windows NT 4 installation that upgrades to Windows 2000. Windows NT 4 drive-letter assignments are stored in HKLM\SYSTEM\Disk. After the upgrade procedure reads and stores the information in Windows 2000-specific locations, the system no longer references the Disk key.
As part of drive-letter assignment for volumes on basic disks, the 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 made in Windows NT 4. IoAssignDriveLetters assigns drive letters only for volumes on basic disks identified in the Disk key because only those volumes rely on the MS-DOS-style partitioning that Windows NT 4 uses.
The Mount Manager
A new driver in Windows 2000, the Mount Manager (Mountmgr.sys), assigns drive letters for dynamic disk volumes and for basic disk volumes created after Windows 2000 is installed. Windows 2000 stores all drive-letter assignments under HKLM\SYSTEM\MountedDevices. If you look in the registry 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 doesn't necessarily have an assigned drive letter. Figure 10-12 shows the contents of an example Mount Manager registry key. Note that the MountedDevices key, like the Disk key in Windows NT 4, isn't included in a control set and so isn't protected by the last known good boot option. (See the section "Accepting the Boot and Last Known Good" in Chapter 5 for more information on control sets and the last known good boot option.)
Figure 10-12 Mounted devices listed in the Mount Manager's registry key
The data that the registry stores in values for basic disk volume drive letters and volume names is the Windows NT 4-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 Windows 2000 Plug and Play 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 and then asks either FtDisk or DMIO (whichever created the volume) for a suggested drive-letter assignment. FtDisk doesn't return suggestions (as it does during an upgrade from Windows NT 4 when it queries the Windows NT 4 HKLM\SYSTEM\Disk key), 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. The Mount Manager then determines whether its internal database contains the drive-letter assignment. If it doesn't, the Mount Manager uses the first unassigned drive letter (if one exists), defines a new assignment, creates a symbolic link for the assignment (for example, \??\D:), and updates the MountedDevices registry key. If there are no available drive letters, no drive letter assignment is made. At the same time, the Mount Manager creates a volume symbolic link (that is, \??\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 (that is, when booting between multiple Windows 2000 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 doesn't make any of its metadata files available for viewing by applications.) NTFS stores mount-point information in the metadata file so that Windows 2000 can easily enumerate the mount points defined for a volume when a Win32 application, such as Disk Management, requests mount-point definitions.
Mount Points
Mount points, a mechanism new to Windows 2000, let 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. (Reparse points are discussed in more detail in Chapter 12.)
A reparse point is a block of arbitrary data with some fixed header data that Windows 2000 associates with an NTFS file or directory. An application or the system defines the format and behavior of a reparse point, including the value of the unique reparse point tag that identifies reparse points belonging to the application or system and specifies the size and meaning of the data portion of a reparse point. (The data portion can be as large as 16 KB.) 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 Windows 2000 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 a Hierarchical Storage Management (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 is exactly how the Windows 2000 Remote Storage Services (RSS) 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 Windows 2000 reparse points, 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.
Mount points are reparse points that store a volume name ( \??\Volume{X}) as the reparse data. When you use the Disk Management 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.exe (\Winnt\System32\Mountvol.exe) to create and display mount points.
EXPERIMENT
Recursive Mount PointsThis experiment uses Filemon (available on the companion CD as \Sysint\Filemon.exe) to show the interesting behavior caused by a recursive mount point. A recursive mount point is a mount point that links to the same volume it's on. Performing a recursive directory listing on a recursive mount point produces file access traces that clearly demonstrate how NTFS treats mount points.
To create and view a mount point, perform the following steps:
- Open a Command Prompt or Windows Explorer window and create a directory on an NTFS drive named \Recurse.
- In the Disk Management MMC snap-in, right-click on the volume and select Change Drive Letter And Path.
- When the Add/Remove dialog box appears, enter the path to the directory you created (for example, I:\Recurse).
- Start Filemon, and in the Drives menu, uncheck all the volumes except the one on which you created the mount point.
Now you're ready to generate a recursive mount-point trace. Open a Command Prompt and execute the command dir /s I:\Recurse. If you look at all the file accesses that reference Recurse in the Filemon's trace of the subsequent file operations, you'll notice that the Command Prompt first accesses I:\Recurse, then I:\Recurse\Recurse, and so on, recursing deeper and deeper.
The application attempts to perform a directory listing at each level of the recursion, but whenever it encounters the mount point it digs into it to try another directory listing. NTFS returns a reparse status code, which tells the object manager to back up one level and try again. Finally, when it gets back to the root directory, the application examines the file or directory that it had found deep in the mount-point recursion. The application never receives a reparse code because of the object manager-directed retry activity. The object manager processes the reparse codes as it receives them from NTFS when it performs directory lookups.
Filemon presents request types as their native IRP type, so a directory or file open appears as an IRP_MJ_CREATE request. A file or directory close is IRP_MJ_CLOSE, and a directory query is an IRP_MJ_DIRECTORY_CONTROL request with FileBothDirectoryInfo in Filemon's Other column.
To prevent buffer overflows and infinite loops, both Command Prompt and Windows Explorer halt their recursion when the directory depth reaches 32 or the pathname exceeds 256 characters, whichever comes first.
Volume Mounting
Because Windows 2000 assigns a drive letter to a partition doesn't mean that the partition contains data that has been organized in a file system format that Windows 2000 recognizes. The volume-recognition process consists of a file system claiming ownership for a partition; the process takes place the first time the kernel, a device driver, or an application accesses a file or directory on a partition. After a file system driver signals its responsibility for a partition, the I/O manager directs all IRPs aimed at the partition to the owning driver. Mount operations in Windows 2000 consist of three components: file system driver registration, volume parameter blocks (VPBs), and mount requests.
The I/O manager oversees the mount process and is aware of available file system drivers because all file system drivers register with the I/O manager when they initialize. The I/O manager provides the IoRegisterFileSystem function to local disk (rather than network) file system drivers for this registration. When a file system driver registers, the I/O manager stores a reference to the driver in a list that the I/O manager uses during mount operations.
Every device object contains a VPB data structure, but the I/O manager treats VPBs as meaningful only for partition device objects. A VPB serves as the link between a partition device object and the device object that a file system driver creates to represent a mounted file system instance for that partition. If a VPB's file system reference is empty, no file system has mounted the partition. The I/O manager checks a partition device object's VPB whenever an open API that specifies a filename or directory name on a partition device object executes.
For example, if the mount manager assigns drive letter D to the second partition on a system, it creates a \??\D: symbolic link that resolves to the device object \Device\HarddiskVolume2. A Win32 application that attempts to open the \Temp\Test.txt file on the D drive specifies the name D:\Temp\Test.txt, which the Win32 subsystem converts to \??\D:\Temp\Test.txt before invoking NtCreateFile, the kernel's file-open routine. NtCreateFile uses the object manager to parse the name, and the object manager encounters the \Device\HarddiskVolume2 device object with the path \Temp\Test.txt still unresolved. At that point, the I/O manager checks to see whether \Device\HarddiskVolume2's VPB references a file system. If it doesn't, the I/O manager asks each registered file system driver via a mount request whether the driver recognizes the format of the partition in question as the driver's own.
EXPERIMENT
Looking at VPBsYou can look at the contents of a VPB by using the !vpb kernel debugger command. Because the VPB is pointed to by the device object for a volume, you must first locate a volume device object. To do this, you must dump a volume manager's driver object, locate a device object that represents a volume, and display the device object, which reveals its VPB field.
If your system has a dynamic disk, you can use the !drvobj driver object viewing command on the DMIO driver; otherwise, you need to specify the FtDisk driver. Here's an example:
The !drvobj command lists the addresses of the device objects a driver owns. In this example, there are seven device objects. One of them represents the programmatic interface to the device driver, and the rest are volume device objects. Because the objects are listed in reverse order of the way that they were created, and the driver creates the device driver interface object first, you know the first device object listed is that of a volume. Now execute the !devobj kernel debugger command on the volume device object address:
The !devobj command shows the VPB field for the volume device object. (The device object shown is named HarddiskVolume6.) Now you're ready to execute the !vpb command:
The command reveals that the volume device object is mounted by a file system driver that has assigned the volume the name GAMES. The RealDevice field in the VPB points back to the volume device object, and the DeviceObject field points to the mounted file system device object.
The convention followed by file system drivers for recognizing volumes mounted with their format is to examine the volume's boot record, which is stored in the first sector of the volume. Boot records for Microsoft file systems contain a field that stores a file system format type. File system drivers usually examine this field, and if it indicates a format they manage, they look at other information stored in the boot record. This information usually includes a file system name field and enough data for the file system driver to locate critical metadata files on the volume. NTFS, for example, will recognize a volume only if the type field is NTFS, the name field is "NTFS," and the critical metadata files described by the boot record are consistent.
If a file system driver signals affirmatively, the I/O manager fills in the VPB and passes the open request with the remaining path (that is, \Test) to the file system driver. The file system driver completes the request by using its file system format to interpret the data that the partition stores. After a mount fills in a partition device object's VPB, the I/O manager hands subsequent open requests aimed at the partition to the mounted file system driver. If no file system driver claims a partition, Raw—a file system driver built into Windows 2000—claims the partition and fails all requests to open files on that partition. Figure 10-13 shows a simplified example (that is, the figure omits the file system driver's interactions with the Windows 2000 cache manager) of the path that I/O directed at a mounted partition follows.
Figure 10-13 Mount operation
Instead of having every file system driver loaded, regardless of whether or not they have any volumes to manage, Windows 2000 tries to minimize memory usage by using a surrogate driver named File System Recognizer (Winnt\System32\Drivers\Fs_rec.sys) to perform preliminary file system recognition. File System Recognizer knows enough about each file system format that Windows 2000 supports to be able to examine a boot record and determine whether it's associated with a Windows 2000 file system driver. When the system boots, File System Recognizer registers as a file system driver, and when the I/O manager calls it during a file system mount operation for a new volume, File System Recognizer loads the appropriate file system driver if the boot record corresponds to one that isn't loaded. After loading a file system driver, File System Recognizer forwards the mount IRP to the driver and lets the file system driver claim ownership of the volume.
Aside from the boot volume, which a driver mounts while the kernel is initializing, file system drivers mount most volumes when the Chkdsk file system consistency-checking application runs during a boot sequence. The boot-time version of Chkdsk is a native application (as opposed to a Win32 application) named Autochk.exe (\Winnt\System32\Autochk.exe), and the Session Manager (\Winnt\System32\Smss.exe) runs it because it is specified as a boot-run program in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute value.
Chkdsk accesses each drive letter to see whether the volume associated with the letter requires a consistency check. One place in which mounting can occur more than once for the same disk is with removable media. Windows 2000 file system drivers respond to media changes by querying the disk's volume identifier. If they see the volume identifier change, the driver dismounts the disk and attempts to remount it.
EAN: 2147483647
Pages: 121