Electrical computers and digital processing systems: memory – Storage accessing and control – Control technique
Reexamination Certificate
1998-12-31
2002-05-07
Kim, Matthew M. (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Control technique
C711S112000, C711S202000, C707S793000
Reexamination Certificate
active
06385706
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to data storage for computers, and more particularly to an apparatus and methods for copying a logical object to a primary storage device using a map of a storage locations.
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, 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 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. The logical volume manager (“LVM”)
14
of
FIG. 1
can help achieve this function by mapping the file system view of data storage into an intermediate layer.
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 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 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 operating systems, as examples. The Symmetrix line of storage systems, available from EMC Corporation, of Hopkinton, Massachusetts, 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 form EMC Corporation, including the Symmetrix model 55xx product manual, p-n200-810-550, rev.f, February, 1996.)
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.)
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 contemplates three separate storage devices—volume A
20
, volume B
21
, and volume C
22
. Thus, as far as the file system level
12
can discern, the system consists of three separate storage devices
20
-
22
. Each separate storage device may be referred to as a “virtual volume,” or “virtual disk.” This reflects that the operating system's view of the storage device structure may not correspond to the actual physical storage system implementing the structure (hence, “virtual”). Unlike the application level
10
, however, the file system
12
perspective is as if the file system
12
were dealing with raw physical devices or volumes.
As far as the file system level is concerned, the virtual volumes may be divided up into “partitions,” which are continuous segments of storage. These partitions are, in-fact, “virtual” partitions, because the partition may actually be stored across a variety of physical storage segments (e.g., hyper-volumes).
In
FIG. 2A
, the data is physically stored on the physical storage devices
24
-
26
. In this particular example, although there are three physical devices
24
-
26
and three volumes
20
-
22
, there is not a one to one mapping of the virtual volumes to physical devices. In this particular example, the data in volume A
20
is actually stored on physical devices
24
-
26
, as indicated at
20
a
,
20
b
and
20
c
. In this example, volume B is stored entirely on physical device
24
, as indicated at
22
a
,
22
b
. Finally, volume C is stored on physical device
24
and physical device
26
as indicated at
21
a
,
21
b.
In this particular example, the boxes
20
a
-
20
c
,
21
a
-
21
b
and
22
a
-
22
b
represent contiguous segments of storage within the respective physical devices
24
-
26
. These contiguous segments of storage may, but ne
Cakeljic Zoran
Ofek Yuval
Tamer Philip
EMX Corporation
Kim Matthew M.
Vital Pierre M
LandOfFree
Apparatus and methods for copying a logical object to a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and methods for copying a logical object to a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and methods for copying a logical object to a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2861339