Electrical computers and digital processing systems: memory – Storage accessing and control – Specific memory composition
Reexamination Certificate
2000-06-27
2004-11-02
Kim, Matthew (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Specific memory composition
C711S112000, C711S147000, C711S148000, C711S163000, C711S202000, C711S209000, C711S207000, C711S004000, C711S161000, C711S162000, C709S229000, C709S241000
Reexamination Certificate
active
06813686
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to data storage for computers, and more particularly to identification of logical volumes stored in multiple storage elements in a storage domain.
DISCUSSION OF THE RELATED ART
Virtually all computer applications (or programs) rely on storage. This storage can be used for both storing the computer code and for storing data manipulated by the code. (The term “data” refers to any information, including formatting information, error detection and correction information, executable code and data for manipulation by an application program.)
Storage technology has developed in a variety of different directions. Accordingly, a wide variety of storage systems are available. It has become impractical, therefore, for the person writing the computer application to also be responsible for detailed control over how data is stored on the storage system.
For this (and other) reasons, application programs typically run on an operating system (e.g., Unix, Windows, MS DOS, Linux, and the many variations of each). Once again, however, the operating system may be used with a variety of storage systems.
It would be highly inefficient to have to change the operating system, or the application programs, every time a change is made to physical storage. As a result, various layers of abstraction have evolved for viewing how data is actually stored in the storage system.
FIG. 1
illustrates one way of viewing the layers of abstraction. At the top level
10
, the application program may assume that data is stored in a manner that has very little to do with how the data is placed onto the physical device. For example, the application may view the storage system as containing a number of directories and data files within the directories. Thus, in an application written for use in the Unix operating system, the application will assume that files are stored according to the Unix directory structure (including hierarchical directories and files located within the directories). This assumed organization of physical storage may have very little to do with how that data is actually stored onto the actual storage devices. This view may be referred to as the “logical view” because of the separation between the logical view of data from the application level is divorced from any view of how the data is physically stored. A logical entity, such as a file, database or other construct, may be referred to at the logical level as a “logical object.”
The application level
10
interfaces with the file system level
12
. The file system level is concerned with how files are stored on disks and how to make everything work efficiently and reliably. Thus, the file system level may be responsible for storing directory structure, and for breaking up files into constituent data blocks for storage onto a physical storage system. For example, in most implementations of Unix, each file has an associated I-node. This node may contain accounting and protection information and, additionally, a set of pointers to data blocks.
Relatively early in the development of computer systems, disk drives became a fundamental device for storage. Accordingly, computer operating systems have been is developed assuming that memory will rely on input/output (“I/O”) to a disk drive. The file system
12
, therefore, may assume one or more “volumes” which correspond to a physical storage unit such as a disk drive (or any other unit of storage), with data stored in blocks on the disk drive.
The demand for storage to be available for use by applications has sky rocketed. As a result, a number of separate physical devices may be required to accommodate the total amount of storage required for a system. In addition, storage systems are often changed or reconfigured.
To insulate the operating system from any changes within the physical device storage system, some mechanism is often employed to flexibly map a standard (volume) view of physical storage onto an actual physical storage system. Thus, an operating system or application may rely on “volumes” of data. Again, these “volumes” may not correspond to how data is actually stored on physical devices. Accordingly, these are “logical volumes” (as opposed to actual physical storage volumes) and are themselves “logical objects.”
The logical volume manager (“LVM”)
14
of
FIG. 1
can help achieve the function of mapping the file system view of data storage into an intermediate layer.
For purposes of the specification and claims, “logical volume” refers to a logical entity that generally corresponds to a logical abstraction of physical storage. “Logical volume” may include, for example, an entity that is treated (logically) as though it were composed of consecutively addressed blocks in a fixed block architecture or records in a count-key-data architecture. “Logical volume” includes not only standard logical volumes, but also components of a standard logical volume, hyper-volumes, partitions, striped volumes, and concatenated (or meta) volumes. A logical volume may be physically stored on more than one storage element.
Finally, the actual storage reading and writing (and, potentially, additional mapping onto physical storage devices) occurs within the physical storage system level
16
, as illustrated in FIG.
1
. Thus, for example, the logical volume manager may map the file system level view of data (as logical volumes or some other logical entity) into volume sizes corresponding to fixed physical storage segment sizes for storage on a physical device (e.g, block sizes). The physical storage system level may then map the logical volume manager level (“logical”) volumes onto physical storage segments (e.g., hyper-volumes discussed below).
Logical volume managers have been implemented for use with the HP-UX by HP and by VERITAS for Solaris operating systems (i.e., V×VM), as examples. The Symmetrix line of storage systems, available from EMC Corporation, of Hopkinton, Mass., is one system capable of mapping hyper-volumes onto physical devices. (The Symmetrix product line of integrated cached disk arrays is described in numerous publications from EMC Corporation, including the Symmetrix model 55xx product manual, p-n200-810-550, rev.f, February, 1996.)
In the VERITAS Volume Manager, sold by VERITAS of Mountain View, Calif., logical volumes are assigned tags, which consist of an identifier for the host computer on which the volume manager is located and a time stamp indicating the time at which a logical volume was created. If a logical volume is electronically moved among the storage elements, it is assigned a new tag. Although logical volumes handled by this Volume Manager are not intended to be accessed by more than one host computer at any point in time, this has been done by manipulating the Volume Manager to provide tags for shared logical volumes to other host computers.
In any event, in the above examples, the mapping of application level data into actual physical storage occurs across four levels: application level to file system level; file system level to LVM level; LVM level to physical storage system level; and physical storage system level to the actual physical storage devices. More or fewer levels of mapping can be done. In some systems, for example, only one level of mapping is performed, e.g., mapping from the application level directly onto actual physical storage devices. In many systems, the mapping stage at the LVM level is omitted. Similarly, in many systems, no mapping is done at the physical storage level (e.g., data is stored directly onto actual devices corresponding to the format of the preceding level and without any further mapping onto physical storage components.) As another example, the file system level could be omitted and the application directly with logical (or actual) volumes.
FIG. 2A
illustrates an example of the mapping that may be performed by the logical volume manager
14
and the physical storage system
16
, to store data onto actual physical devices. The application/file system's view of the storage system co
EMC Corporation
Kim Matthew
Li Zhuo H
Wolf Greenfield & Sacks P.C.
LandOfFree
Method and apparatus for identifying logical volumes in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for identifying logical volumes in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for identifying logical volumes in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3362833