The Magic of Mount Points

For UNIX users, the concept of mount points is old hat—something that UNIX and other OSs, such as Novell NetWare, have used for years. However, in the Windows space, mount points are a relatively new concept. Let's look at how Windows uses mount points and the value and usefulness that this minor but powerful feature provides for Windows Server 2003 and Windows 2000 Server storage systems.

A Brief Mount Points Primer
The idea of mount points, which originated in UNIX and older minicomputer OSs years ago, grew out of a desire to simplify storage management. Simply put, a mount point is a physical location in the directory structure on which you graft—or mount—the root directory of another volume. Mount points are persistent directories that point to disk volumes; in Windows, they always resolve to the root directory of the desired volume. Because mount points don't require that you associate each disk volume with a drive letter, they overcome Windows' drive-letter limitation (i.e., only 26 drives—A through Z) for disk drives.

When you use NFS to mount a remote file system, you must specify both the remote resource name and the local file-system location for that resource. In Windows, you must use an NTFS directory to host the volume mount point because the underlying mechanism uses NTFS reparse points. You can mount a variety of file systems, such as CD-ROM File System (CDFS), FAT, FAT32, NTFS, and Universal Disc File System (UDFS).

Mount points provide a useful storage-management tool that avoids the tedious work of assigning specific volume mappings to every disk resource (whether local or remote). Integrating local and remote disk resources into a unified and singular directory tree greatly simplifies file-system traversal and makes the traversal transparent to the administrator, application, and user.

Using Mount Points in Windows
Administrators of non-Windows systems understand mount points and use them extensively, but Windows administrators are just beginning to realize their power. Because the Windows storage-management paradigm has always relied heavily on alphabetic drive-letter designations, mount points—with their lack of dependence on drive-letter associations—are especially valuable. When Windows servers were simple and rarely assigned more than 5 or 10 drive letters, the need for mount points was almost nonexistent. Today, however, the need for mount points has become vital because Windows administrators are building larger, more complex servers that have numerous attached storage solutions, such as Network Attached Storage (NAS) devices and Storage Area Network (SAN) devices. Add complex applications such as Microsoft Exchange Server and Microsoft SQL Server to the mix, and drive-letter scarcity becomes even more of a problem. Clustering further complicates the situation because an entire cluster is allowed only 26 drive letters. (A shared disk resource in a cluster must maintain a consistent drive letter regardless of which cluster node owns it.) Microsoft added volume mount points to Windows 2003 and Win2K Server to overcome these problems with drive-letter limitations and to simplify storage management.

You can configure mount points on Windows three ways. The first method is perhaps the most familiar to Windows administrators. You use the Microsoft Management Console (MMC) Disk Management snap-in (diskmgmt.msc) to mount volumes to already-configured physical drive resources by selecting Add Mountpoint from the interface. Second, if you prefer to use the command-line interface, you can run mountvol.exe from the command line. Third, you can use Win32 API calls in your own .exe file. Win32 API's SetVolumeMountPoint and DeleteVolumeMountPoint functions add and delete mount points, respectively.

Practical Applications and Implications
To more easily understand the utility of mount points, let's look at some specific examples of how they're used and the benefits they provide. These practical examples illustrate the use of volume mount points in Windows Server and Exchange Server environments.

Let's start with a simple example. Suppose that you want to add a second hard disk to your Windows machine. You already have one hard disk (Drive 1) mapped as C, and you don't want to map the second disk (Drive 2) as D. You can get around this problem by adding a mount point to the directory structure of Drive 1 that references Drive 2, as Figure 1 shows. In this example, Drive 2 is configured as a mount point of C:My DocumentsData. When traversing the directory tree to C:My DocumentData, the user or application is redirected to the root of Drive 2. This simple technique avoids assigning a drive letter and greatly simplifies directory navigation.

Now let's look at a more complicated, real-world example. Microsoft's Operations and Technology Group (OTG) operates one of the world's largest Exchange deployments, which supports more than 88,000 mailboxes, more than 50TB of storage, and more than 6 million messages per day. As part of an aggressive consolidation project during the past year, OTG decided to use Microsoft Cluster Server (MSCS) clusters for its large Exchange servers. The largest of these configurations is a five-node cluster (four active nodes and one standby node) that supports 16,000 mailboxes (4000 mailboxes per active node).

As you can imagine, this large-scale configuration requires huge amounts of storage consisting of multiple LUNs used as database volumes, log-file volumes, and backup volumes. OTG originally designed this configuration without using volume mount points because mount points weren't supported on clustered shared disks before Windows 2003. The original configuration required 36 drive letters, which rendered the cluster design impossible to implement and deploy in Win2K Server.

However, because Windows 2003 supports the use of mount points on clustered shared disks, OTG was able to reduce the original design's 36 drive letters to 16 drive letters in the Windows 2003­based design. This modification let OTG build and scale the Exchange clusters to meet its requirements for the consolidation project. For Microsoft, volume mount points were a key enabler for a leading-edge Exchange cluster design.

Volume mount points are powerful tools for both simple and complex applications. You can use them to overcome drive-letter limitations or to simplify directory traversal. Whether you're building large-scale cluster configurations or just trying to simplify volume management on your file server, you'll come to appreciate mount points the way the UNIX gurus do.