The widespread use of computerized data processing systems has created vast amounts of data that must be stored. To serve this need, data storage system providers have developed data storage systems that use tape or disk arrays to store such data. In a typical data storage system using disk or tape array technology, there can be many individual physical storage devices, such as hard disk drives or tape drives. Circuitry and/or software in either the data storage system or in the host computing devices (hosts) which interface to the data storage system can manipulate the way in which data is stored in the various individual storage devices. Various arrangements of the storage devices and of the data maintained in each device are possible. Each arrangement generally allows the storage devices to appear as a single contiguous data repository or as groups of repositories to an application executing on a host that requires storage or access to stored data.
By way of example, a data storage technology such as Redundant Arrays of Inexpensive Disks (RAID) allows a data storage system to present conglomerations of many individual hard disk drives to host computing devices as one or more disk storage areas. In general, the data storage system handles the RAID operations in such a way that they are transparent to the host computing devices which interface to the data storage system. RAID systems also provide various levels of fault tolerance, error correction and error recovery. This allows the hosts to treat a conglomeration of disks within the RAID data storage system without regard to the underlying physical separation or layout of data within or “across” each individual disk drive. For more details concerning RAID technology and systems which implement this technology, the reader is referred to Patterson et al., “A Case for Redundant Arrays of Inexpensive Disks (RAID),” ACM SIGMOND Conference, Jun. 1-3, 1988, the teaching of which are hereby incorporated by reference in their entirety.
The conglomerations of disks presented as a single repository for data to a host computing device from a data storage system are called volumes. A prior art volume identifies and serves as a host interface to the raw physical storage associated with one or more storage devices within the data storage system. Typically, in the prior art, a person known as a systems administrator configures one or more volumes during an initial or periodic configuration process performed on the data storage system. Between configurations, the total amount of available data storage within a prior art volume does not change. For instance, an administrator may configure a data storage system containing four physically separate hard disk drives “A”, “B”, “C” and “D” to present only two volumes of data storage, V1 and V2, to a host computing device that interfaces to the data storage system. The first volume V1 may be a conglomeration of physical storage space (using RAID or another data-over-multiple-disk technology) located on disks “A” and “B”, while the second volume V2 may be a conglomeration of storage space existing within hard disk drives “C” and “D”.
A single volume need not be comprised of space from more than one storage device. For example, a volume might be comprised of only a portion of storage space from a single hard disk. In this case, the volume may be equivalent, for example, to a partition, slice or other apportionment of that hard disk.
In any event, prior art data storage systems provide volumes that are essentially interface mechanisms to a host computing device. Generally, in the prior art, a single host directly interfaces (i.e., via a SCSI bus or other connection mechanism) to the data storage system and “serves” the data from the data storage system onto a network for access by other hosts, which do not directly interface to the data storage system. The volumes appear to the server host as individual contiguous repositories for data. Within the data storage system, however, the volumes may actually span portions of one or more storage devices (e.g. disk drives, tape drives, and so forth). Providing volumes insulates server software applications and server host computing devices from the details of complicated data and disk storage mechanisms such as minoring, error correction, striping and so on. From here on in this description, a host or host computing device generally refers to a host (i.e., a server) that directly interfaces with a data storage system.
Generally, when a host computing device starts-up or “boots”, an operating system that controls the host polls any attached data storage systems via device drivers to determine what volumes are available for access to the host computing device within the data storage system. By way of example, a host executing a version of the Solaris operating system (a variant of Unix), which is manufactured by Sun Microsystems of Mountain View, Calif., (Solaris being a registered trademark of Sun Microsystems Inc.) can use an operating system call, such as “report LUNS” for a SCSI-3 device, to poll the SCSI port coupled to the data storage system in order to determine volume availability. In response to the host poll, the data storage system provides a list of available volumes in the given target device. Host-specific access information stored in the volumes may be reported back to the host as well.
A host filesystem in the host computing device can then access a particular volume by “mounting” a volume identifier associated with the volume (obtained from the initial poll) that is provided from the data storage system to a “mount point” within the host filesystem. A filesystem mount point is essentially a stub directory within the host filesystem that serves as an entry point into the volume once the host has mounted the volume. After the host has mounted the volume, software applications on the host can access data in the volume by referencing the mount point directory and any subdirectories that are now available within the mounted volume of data storage. For example, in a computing device controlled by the Unix operating system, a mount point may correspond to a directory within the Unix filesystem, such as “/home”. A system command such as
mount /home /dev/dsk/c0t0d0s0
can be used to mount the volume identified by “/dev/dsk/c0t0d0s0” to the mount point “/home” in the Unix filesystem. After the volume is mounted, users or applications executing on the computing device can reference files and data within the /home directory and any subdirectories within /home that actually exist within the data storage associated with the volume. That is, all data accessed within the /home directory is physically maintained on storage space within storage devices (e.g., hard disk drives) that are associated with the mounted volume “/dev/dsk/c0t0d0s0” in the data storage system.
Most operating systems rely on volumes provided by a data storage system for certain operations. For example, many host operating systems expect storage space within volumes to be organized into sequential blocks of data ranging from Block 0 to Block N. Many operating systems frequently store certain host-specific volume directory information, partition information, track/sector layout and size information, and so forth on a predetermined designated portion of storage space within a volume. Block 0 (i.e. the first block) of a volume is frequently used for storing such host-specific data. As another example, the Microsoft Windows NT operating system, manufactured by Microsoft Corporation of Redmond, Wash., performs periodic checks to make sure that a mounted volume is always accessible within the data storage system. Windows and Windows NT are registered trademarks of Microsoft Corporation.
Generally, once an operating system of a host computing device mounts a prior art volume, the host and/or the data storage system cannot change the amount of available storage space (i.e. the size) within the volume while the volume remains mounted. Thus, if a host mounts a ten Gigabyte volume of data storage, the host operating system and any host software applications can have access to the full ten Gigabytes of data storage within that volume as a single contiguous portion of storage space. However, the amount of data that can be stored on such a volume is limited to ten Gigabytes, less any space used for volume formatting requirements, such as the Block 0 information. In order for more storage space to be associated with (i.e. added to) the volume, a systems administrator for the host must unmount the volume and reconfigure the volume size by associating additional storage devices to the volume within the data storage system. Once the systems administrator reconfigures the volume size, the systems administrator can again present the volume to the host operating system as available data storage space.
Reconfiguration of a volume (i.e., to add or remove or move data storage space) typically requires high-level systems administrator (e.g. “root”) privileges on the host computing device. For example, during volume reconfiguration, the host operating system must be brought into a special restricted user mode (e.g. single-user mode). The restricted user mode ensures that no host application programs are attempting to access data within the volume while reconfiguration is in progress. Once reconfigured, the host operating system may need to be re-started or “re-booted” in order for the operating system to re-poll the attached data storage system to discover the newly re-configured volume(s) containing the additional storage space.
The access information stored by a host operating system in Block 0 of a volume is often specific to a particular operating system or host architecture. By way of example, if a version of the Solaris operating system is used to configure and mount a volume, Block 0 of that volume may contain Solaris-specific volume access information. If the data storage system that contains the Solaris-specific volume is subsequently interfaced with another host computing device that uses a different operating system or architecture, such as Microsoft Windows NT, the access information in Block 0 of the Solaris-specific volume may not be suitable to allow access to the volume by the Windows NT controlled computing device. This is because volume labeling information provided by Solaris in Block 0 of the volume is not be compatible with volume labeling information required by Windows NT.
Certain software application programs that execute on host computing devices also rely on the existence and correct operation of volumes. For instance, a data storage application called TimeFinder, manufactured by EMC Corporation of Hopkinton, Mass. (TimeFinder is a trademark of EMC Corporation), allows a data storage system to create and continuously maintain a mirror image volume of a master volume. While the mirror image volume is continuously being maintained as a copy of the master volume (reflecting all changes made to data within the master volume), both the mirror image volume and the master volumes are “visible” to the host operating system that is interfaced to the data storage system. From time to time, the TimeFinder software can detach the minor image volume from its synchronous relationship with the master volume. TimeFinder may detach the mirror image volume from the master volume, for example, to allow the minor image volume to be used for offline application testing or periodic backup purposes on dedicated backup host. This allows the master volume to remain accessible the regular host computing devices thus providing uninterrupted access to data in the master volume. Such a system is valuable in mission critical systems requiring around-the-clock access to data. When the offline operations (i.e., backup or testing) on the minor image volume are complete, TimeFinder reinstates the synchronous relationship between the mirror image volume and the master volume so that the minor image volume can be brought back up-to-date with the master volume to reflect any changes that may have occurred in the master volume during the backup of testing processing.
As another example of the reliance on volumes for the proper operation of host software applications, certain host application programs may require a minimum amount of storage space to be available within a volume before allowing processing within the application to proceed. This may be the case, for example, when a database program attempts to initially access a volume of storage to create a new database. The database application may have minimum storage size requirements with respect to the volume in order to allow processing to proceed beyond a certain point.
USPTO Backgrounds
USPTO Backgrounds