JP2001516080A - Data storage device and redundancy maintenance method - Google Patents

Abstract

A data storage system (110) stores thereon data organized as a plurality of objects (124-126), each having an attribute indicative of a characteristic of the object (124-126). Storage medium (132). The objects (124-126) include redundant objects (412) that store redundant information. A control element (150) is operatively connected to the storage medium (132) and configured to provide an interface (128) to the object (124-126). The interface (128) presents a method (φ-N) that is invoked to access the object (124-126).

Description

Detailed Description of the Invention

FIELD OF THE INVENTION The present invention relates to data storage devices. In particular, the invention relates to data storage devices such as disk drives, tape drives, or optical drives where data is organized and accessed as objects.

BACKGROUND OF THE INVENTION Two conventional computational models are becoming well known in the computational industry. The first is a mainframe calculation model, and the second is a cluster calculation model.

[0003] The conventional way forward for end users in mainframe computing models is to purchase an initial system and replace the initial system with a larger system when additional processing power is needed. At various points in this cycle, impulsive discontinuities occur. For example, if the user surpasses the architecture of the initial system, when purchasing the second upgraded mainframe system, the user is from one operating system to another operating system, or even from an architecture owned by one vendor to another vendor May require conversion to an architecture owned by. Such changes involve significant cost to the mechanism to purchase upgrades in both money and employee time. Therefore, such conversions are often avoided.

In addition, mainframe models are associated with poor residual value of computing devices. Thus, system replacement may result in substantially complete loss of investment capital when replacing an initial system with an upgrade system. Furthermore, large upgrade systems tend to be sold at smaller volumes than smaller systems. Thus, each new system upgrade typically results in higher computational costs than previous systems.

In a cluster computing model, mainframe computers are replaced by small, standard base servers. It offers many advantages over mainframe models. Because clusters can only be started as a single system, the threshold for entering the cluster model is low. In addition, such small systems are typically sold at high volumes, resulting in lower computational costs. Also, such systems are standards-based in that they do not show a dependency on ownership architecture. As a result, the device can be used from multiple sources and the user can select the best alternative each time they make a purchase later.

Cluster computing models have other advantages. Upgrade costs can be more precisely managed simply by adding the additional resources needed to meet current and urgent future needs. In addition, users can select from a wide range of vendors regardless of migration or conversion to a new architecture. Likewise, the correct architecture does not require conversion to another operating system.

Even so, cluster computing models have drawbacks and problems. For example, cluster computing models encounter difficulties in providing a cluster system with the ability to share data such that the cluster takes over the workload that a single mainframe can perform. For example, it is currently very difficult to implement a cluster model where each server in a cluster needs to process the same data transaction. Examples of such applications include a complete inventory of aircraft reservations and financial institution transactions.

[0008] A second drawback of cluster computing models is the lack of extensive experience in managing storage and data present in the mainframe environment. Management software is deployed from this experience, but it is not yet available in a standards-based cluster environment.

The present invention addresses these and other issues and provides advantages over the prior art.

SUMMARY OF THE INVENTION A data storage device includes a storage medium having stored thereon data configured as a plurality of objects, each having an attribute indicative of a property of the object. The objects include redundant length objects that store redundant information. A control element is connected to the storage medium and configured to provide an interface to the object. The interface presents a method that is called to access the object.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT FIG. 1 is a block diagram of a data storage system 100 in accordance with one aspect of the present invention. System 100 includes object oriented data storage 110 and 112, file server 114, requestors 116, 118, 120 and interconnect 122. The system 100 can be configured with devices and software from many different vendors, presenting a network connected storage configuration that appears to the user as a single large computer system.

Object oriented data storage 110-112 is a system 100.
Storage element implementing the data storage function of The storage devices 110-112 are preferably disk drives, redundant arrays of independent disk (RAID) subsystems,
It includes tape drives, tape libraries, optical drives, jukeboxes or any other shareable storage device. Storage devices 110-112 are also provided with (I / O) channel attachments to requestors 116, 118, 120 (I / O) accessing them.

The requestors 116, 118, 120 are elements such as servers or clients that share information stored on the devices 110, 112. Requester 116-120
Are also preferably configured to directly access the information on the storage devices 110,112.

The file server 114 performs management and security functions such as request confirmation and resource allocation. In small systems, preferably no dedicated file server is used. Instead, one of the requesters 116-120 assumes the function and responsibility of overseeing the operation of the system 100 performed by the file server 114. Furthermore, if the security and functionality provided by file server 114 is not necessary or desirable, or if the cluster of requestors 116-120 needs to talk directly to storage 110, 112 due to the need for overriding for performance. The file server 114 is removed from the system 100.

In one embodiment, interconnect 122 is a network attached storage device 10.
It is a physical infrastructure in which all the components in 0 communicate with each other.

In operation, when the system 100 is powered up, preferably all devices identify each other or a common reference point, such as the file server 114 or interconnect 122. For example, in the fiber channel based system 100, the object oriented storages 110, 112 and the requester 11
6-120 log on to the system's fabric. In such an implementation, any component of the system 110 for which it is desired to determine an operational configuration can use Fabric Services to identify all other components. From the file server 114, the requestors 116-120 learn the existence of storage devices 110, 112 that can be accessed. Similarly, storage 110
, 112 learn the location of the information needed to locate other devices in the system 100 and the addresses that must be used to invoke management services such as backups.

Depending on the security practices of the particular system 100, requestors 116-12.
Access to certain components of the system 100, either zero or any of it, can be denied. From the set of storage devices 110, 112 available to each requester, the requester can then identify files, databases, and free space available to it.

At the same time, each component in system 100 preferably identifies to file server 114 any special requirements associated therewith. For example, any storage level service attributes may be communicated to file server 114 once so that all other components in system 100 learn these attributes from file server 114. For example, a particular requestor 116-120 may want to be notified of the installation of additional storage following startup. Such attributes are, for example,
This can be provided when the requester logs on to the file server 114. Next, file server 114 can automatically advise that particular requestor 116-120 whenever a new storage device is added to system 100. Typically, file server 114 can then pass the requester other important characteristics, such as whether the storage device is a storage device such as RAID 5, mirrored, etc.

In accordance with one aspect of the present invention, the information stored in storage devices 110, 112 is stored by the system shown in FIG. Preferably, each storage device 110, 112 is an object 12 rather than as a sequence of sectors in which data is ordered.
4-126 is an object oriented device that operates in a mode configured and accessed as 4-126. Object oriented devices 110, 112 manage objects 124-126 with the object file system illustrated to include a single level list of objects for each partition of a particular device. It is also called flat file system. Each device 110,
The objects 124-126 stored on the storage medium in 112 are preferably the smallest visible units of capacity allocation on the devices 110, 112 operating in object oriented device mode. An object on such a storage device comprises a set of ordered sectors associated with a unique identifier. Data is referenced by an identifier and offset into the object. Object is a storage device 110, 11
2 are allocated and arranged on the storage medium by itself, and the operating system manages the files and metadata in these object structures rather than managing sectors of data as in the conventional architecture.

Objects 124-126 are accessed by interface 128,
The object then presents multiple methods that can be invoked by the requestors 116-120 to access and manipulate the attributes and data within the objects 124-126. Therefore, as shown in FIG.
From 20, a request 130 is issued. In the preferred embodiment, requestors 116-12
0 is a component of a computer system or a cluster or network of systems, which issues a request 130 for an action on a storage device including objects 124-126. Thus, requesters 116-120 can be both clients and servers. In any case, the request 130 issued from one requestor 116-120 invokes one method in the interface 128 and thereby causes one or more objects 124 to be received, as described below.
-126 is operated.

FIGS. 3-1 and 3-2 illustrate two different configurations that can be used to access objects stored on storage device 110-112. For simplicity, only single requestor 116 and single object oriented storage 110 are shown in FIGS. 3-1 and 3-2. If you want to open an object (such as object 124-126), requestor 116 can directly access storage device 110 or request permission and location information from file server 114 to access an object on storage device 110. It may be necessary to The extent to which file server 114 controls access to storage 110 is primarily a function of the security requirements of a particular implementation of system 100.

In the block diagram of FIG. 3-1, it is assumed that the system 100 is secure. That is, there is no need to protect the transmission of command information and data between the requestor 116 and the storage device 110. In such an implementation, file server 114 for management functions may still exist, but file server 114 need not supervise requester interactions with storage device 110.

In such an implementation, requester 116 may
It is in a position to access and generate an object directly above. Thus, the requestor 116 opens and reads the object as if it had originally been attached to it.
And can write close. Such an operation will be described later. However, it is briefly outlined here for the sake of clarity. In order to retrieve objects on storage device 110, preferably requester 116 indicates one or more ways to initiate a search for logical volumes or partitions on storage device 110 and objects stored thereon. Reading from the object can be done first. The requestor 116 then opens and reads the object that can be the root dictionary. Finding other objects from this object is not roundabout, but based on the contents of the root dictionary. The requestor 116 repeats the process until the desired data is found. Data is referenced by object identification (ID) and displacement within the object.

In the second implementation shown in FIG. 3-2, security is required. Thus, in the I / O chain between requester 116 and storage device 110,
The file server 114 is interposed to the extent necessary for the desired level of protection. In one preferred embodiment, requester 116 must first request permission from file server 114 to perform an I / O operation. Next, the file server 114 (which may have suspended storage location information from the requestor 116 for added security) requests from the requestor 116 by returning sufficient information that the requestor 116 can directly communicate with the storage device 110. Authorize Since the storage device 110 is preferably informed of the security parameters when logging on to the file server 114, preferably I / O unless it is properly configured and contains encoded data including valid permissions from the file server 114. Do not allow the request.

The process then proceeds as described with respect to FIG. 3-1. However,
The payload associated with each command may be quite different. For example, if security is required (as shown in FIG. 3B), both commands and data passing between requester 116 and storage 110 may be encrypted. Furthermore, permission information should preferably be added to the command parameters given from the requester 116 to the storage device 110.

In one preferred embodiment, the storage devices 110, 112 can include hard disk drives, and a brief discussion of disk drives follows. FIG. 4 is a perspective view of a hard disk drive that can be implemented as storage device 110. In the disk drive 110, a plurality of disks 132 is a housing 13
6 is pivotally supported about a spindle motor assembly 134. Each disk 1
32 has a number of concentric recording tracks, shown schematically at 138. Each track 13
8 is subdivided into multiple partitions (described in more detail with respect to FIG. 6)
. Disc 132 by referring to a particular partition in track 138
You can store and retrieve data in Preferably, the actuator arm assembly 140 is rotatably mounted at one corner of the housing 136. The actuator arm assembly 140 includes a plurality of head gimbal assemblies 142, each including a slider having a read / write head, or a transducer (not shown) that reads and writes information to a disk 132.

The voice coil motor 114 precisely rotates the actuator arm assembly 140 back and forth so that the transducer on the slider 142 crosses the surface of the disk 132 generally along the arc indicated by the arrow 146. . Also shown in block diagram form in FIG. 4 is disk drive controller 148, which is used to control certain operations of disk drive 110 in a known manner.
However, in accordance with the present invention, disk drive controller 148 interfaces 12 with objects 124-126 stored on disk 132.
Also used to realize eight.

FIG. 5 shows the disk drive 11 when it is fitted into the system 100 shown in FIG.
It is a part of 0 block. In FIG. 5, disk drive controller 148 includes a control element 150 that implements interface 128. Disk 132
Objects 124-126 are stored on the storage medium that constitutes the Requirement element 1
52 are implemented on requesters 116-120 and are configured to logically represent the request to invoke the method at interface 128. When the method is invoked, control element 150 performs a task to manipulate the identified object in the desired manner. Control element 150 returns an event, which can include data or attributes associated with any of the objects identified. Events are also returned based on the particular method called by requestors 116-120.

In order to provide the same functionality as object oriented devices 110-112 are delivered from an operating system having block object oriented devices, the storage space on devices 110-112 can be managed to the same extent Must. Thus, in one embodiment, storage device 110-11
Two feature layers are provided on objects 124-126 stored thereon. In one embodiment, object oriented storage 110-112 is:
Provide allocated disk space in one or more mutually exclusive areas called partitions. Partitions are described in detail with respect to FIG. Within a partition, requesters 116-120 can create objects. In one embodiment, the structure in the partition is simple and flat. On this mechanism, any operating system can map its own structure.

FIG. 6 illustrates a portion of storage space on a storage medium, such as one of the disks 132.
The storage space is a number of objects such as device control object 154, device related object 156, etc., and partition 0 (also denoted by 158), partition 1 (also denoted by 160) and partition N
It includes multiple partitions that are displayed as (also displayed with the number 162).
Each partition may also include several objects, such as a partition control object 164, a partition object list 166, and a plurality of data objects 138 (shown as data object 0-data object N).

Each object has a set of attributes associated with it. In accordance with one aspect of the present invention, access control attributes are provided which are set by an attribute setting method (discussed in more detail below) to provide a means by which access to particular objects is controlled. By changing the version number of the access control attribute, a certain requester 116-
120 can be denied or given access to a particular object.

Cluster attributes are attributes that indicate whether it is desirable to place a particular object near other objects in the storage system. The cloning attribute indicates whether a particular object was created by copying another object in the storage system. One group of size attributes defines the size characteristics of a particular object. For example, a group of size attributes has information indicating the maximum offset to be written into the object, the number of objects allocated to the object, the number of blocks used to store data in the object, and the number of bytes per block in the object. Including.

One group of time attributes indicates the creation time of the object, the time when the data in the object was last modified, and the time when the attribute was last modified in the object.
The object may also preferably include a set of attributes defining the time at which any data in the file system was last modified and the time at which any attribute in the file system was last modified. Other parameters of any given object,
Other attributes may also be provided to indicate a feature or feature.

Each object is also associated with an object identifier that is selected by a particular storage device 110-112 and returned to the requestors 116-120 in response to a command to create an object. Preferably, the identifier is an unsigned integer of a specified length. In one preferred embodiment, the identifier length is a specific storage device 110-1.
It can be defaulted to a size specified by 12 or set as a device attribute. Furthermore, in one preferred embodiment, predefined subsets of identifiers (IDs) are stored for known objects, special applications, and other special functions that can be optionally implemented.

FIG. 6 shows that the storage medium typically contains several known objects always with a specific object ID. Such known objects may exist in each device or each partition.

For example, one such known object is a device control object 15
4 and preferably includes the attributes maintained by each device 110-112, and relates to the device itself or all objects on the device. Attribute is Set-Attr described later
It is maintained by the ibute method. In one preferred embodiment, there is one device control object 154 per device 110-112.

Table 1 shows a set of preferred device control object (DCO) attributes.

[Table 1]

In one preferred embodiment, the DCO attribute controls a clock that is only a monotonous counter, a master key that includes an encryption key, or other master keys that control all other keys on the device, and a partition key. And a device key that can be used to lock the partition. The attributes define a protection level key that identifies a predetermined protection level and has an associated security policy, a partition cant that defines several partitions on the device, and properties associated with all objects on the particular device being accessed. Object attributes to be included.

In order to properly manage objects spanning multiple storage devices 110-112,
Each storage device 110-112 preferably also includes device related objects 156 that define the association between the various devices 110-112. For example, storage 110, 1
If 12 is a component of a mirror pair or array set of devices, then the device related object 156 identifies this relationship. Table 2 shows the preferred attributes of device related object 156.

【Table 2】

Such an attribute preferably comprises an association identifier, which is a unique identifier for each given set of association devices. The attributes preferably also include association types that define the type of association between devices (eg, mirror pair, RIAID 5, etc.). The attribute further preferably includes a membership list that only identifies the associated component 110-112.

Each partition 158, 160, 162 on storage device 110-112 preferably comprises a partition control object 164 comprising the properties of a single partition
Also includes. Object 164 preferably includes not only partitions, but also any object attributes involved with all objects in it. Each device 110-112
Preferably includes one partition control object 164 for each partition defined on the device. Although FIG. 6 includes partition control objects stored within each partition, this need not be the case. Partition control objects can be stored in the flat file system above partitions.

Table 3 preferably shows some of the attributes contained within partition control object 168.

[Table 3]

Such attributes preferably include a master key defining an encrypted key for all partitions, and can be used to set the current working key. The attributes preferably also include the current working key and the previous working key used for encryption and decryption of command and data messages. Partition control object 164 preferably also includes object attributes associated with all objects in the indicated partition.

FIG. 6 also shows that each partition preferably includes a partition object list 166, which is an object created by the control element 150 when the partition is created on the storage medium. The partition object list 166 preferably has the same identifier in each partition and constitutes a starting point for navigating the object file system implemented on the storage medium. Table 5 preferably shows a list of attributes associated with each partition object list.

[Table 4]

As shown in Table 4, preferably the objects include a list of object identifiers (ie object IDs) for all objects residing in the partition, and the volume of user space allocated to each object. Object identifiers are used by requesters to open, read, write and close objects. Furthermore, the user preferably sets each object ID by setting the user data attribute in the partition object list
Allocate user space for Partition object list 16
After six, each partition preferably includes a plurality of data objects 168. Each data object 168 preferably includes one or more of the attributes shown in Table 1 and may include additional attributes depending on the particular implementation of the data storage system.

Object oriented storage 110-112 preferably supports requests to provide and store data to requestors 116-120. In addition, storage devices 110-112 are preferably responsible for other components in the prior art, possibly other functions performed in the operating system.
Space management is preferably implemented by the devices 110-112 themselves, as well as maintenance of attributes associated with objects on the devices 110-112. Such functions are preferably implemented by invoking methods supported by the interface 128 implemented by the control element 150 in each storage device 110-112. Some of the ways in which it can be called will be described later. However, to provide a better understanding of such a method, FIGS. 7-1 and 7-2 show a flow diagram illustrating the navigation of an object oriented file system according to one aspect of the present invention. Before detailed examination of each method described below, FIG.
It is believed that the present invention can be easily understood if the examination of 1 and FIG. 7-2 is conducted.

FIGS. 7-1 and 7-2, which extend from block 170-204, illustrate finding objects within a designated partition on one storage device 110-112. Initially, requestor 116 obtains device attributes within device control object 154. It is indicated by block 172. The control element 150 returns the attributes stored in the device control object 154 by calling the Get-DCO-Attributes method. It is indicated by block 174. The requestor 116 then selects a given partition based on the attributes returned from the device control object 154. It is indicated by block 176.

Once a partition is selected by the requestor 116, the requestor 11 can then
6 calls the Get-DAO-Attributes method as shown in block 173. Thereby, the control element 150 is a device related object 156 stored on the storage medium 110.
Get attributes from Control element 150 then returns device related attributes to requestor 116, as shown in block 175. Based on device related attributes and device control attributes
The requestor 116 selects the partition to query. That's block 176
Indicated by.

The requestor 116 then invokes the Get-PCO-Attributes method, which causes the control element 158 to obtain the attributes found in the partition control object 164 associated with the particular partition being interrogated by the requestor 116. The control element 150 thereby obtains the partition control object attribute and returns it. It is indicated by blocks 178 and 180. If the objects in the selected partition are not of interest to the requestor, then the requestor selects another partition, as shown in blocks 182 and 176.

However, assuming that the requestor 116 has found the partition of interest, the requestor calls Get-POL-Attributes, as shown in block 184. In this manner, control element 150 obtains attributes from partition object list 166 associated with the selected partition. These attributes are then provided to the requestor 116, as indicated at block 186.

The requestor 116 then invokes the Open-Read-Only-POL method. It is indicated by block 188. As described below, the control element 150 gets the data stored in the partition object list 166 associated with the selected partition, but that object to indicate that the data is given on a read-only basis so that it can not be modified or expanded. Modify the attributes in It is indicated by block 190.

The requestor 116 then invokes the Read-POL method, which causes the control element 150 to submit a list of objects in the partition that it has selected for review. It is indicated by block 194. After selecting the desired object in the selected partition, the requestor 116 invokes the close-POL method which causes the control element 150 to close the partition object list. It is indicated by block 196.

Once the object ID for the desired object is found, then the requestor 116 calls the Open-xxx-Objectx method. xxx is a specific opening method called by the requester based on the specific data manipulation desired by the requester. Obje
ctx indicates an object ID from a partition object list identifying an object operated or accessed by the requester. For example, xxx can represent an Open-Update operation or an Open-Read-Only operation. They are described below and this step is indicated by block 198.

The requestor then performs the desired manipulation of the object returned by the control element 150. The various methods that can be used to manipulate objects are described below. It is indicated by block 200.

Finally, when the desired object operation or access is completed by the requester,
The requestor 116 also invokes the Close-Objectx method, which is described below and operates to close objects accessed by the requestor 116.

FIGS. 8-24 are flows showing various exemplary methods that can be invoked by a requester to perform desired functions and desired operations of objects stored on an object oriented device such as device 110. FIG.

FIG. 8 is a flow diagram specifically illustrating the Open-Create-Object method. Requester 116
When the method invokes this method, as shown in block 208, control element 150 generates a new ID and places the ID in the partition object list associated with the particular partition for which the object is to be generated. It is indicated by block 210. Control element 150 then assigns the number of blocks associated with the object, etc., indicates the object creation time, and modifies the object attributes to modify the object attributes to set other attributes associated with the object and listed in Table 1. Generate This is indicated by block 212. Next, control element 15
0 returns the state of the request with the new ID of the object just created. This is indicated by block 214.

In addition to just creating objects, the requestor 116 can specify several options. For example, in the preferred embodiment, the requestor 116 is an object password protected, an object encrypted, some quality service (eg, object backed up), locking characteristics (eg, partition and device locks, etc.) Objects locked by object locks as well as any other locks), access control versions, mirrors and other backup support (so that all updates are mirrored or designated on other objects) Will be backed up by
Can be specified to indicate that space is allocated with the specified minimum size, and collision properties (writing to UNIX-type systems) can be set.

The specific information that the requestor 116 provides to the control element 150 to invoke this method is the authorization information in the system that requires it for security, the partition of the device on which the object is generated, and any of the aforementioned. Contains options. In response, in one embodiment, control element 15 returns the available capacity on the device, the status of the request, along with the new object ID.

Note also that special instances of this method can be invoked, including all data associated with the object. In that case, one can create an object, write to the object, and invoke one method that can close the object.

FIG. 9 is a flow diagram illustrating the Open-Update-Objectx method. When the requestor 116 invokes this method, the requestor 116 can read and write the specified object, as shown in block 220. It also extends the length of the object. When this method is called, control element 150 sets an attribute in the specified object indicating that the object is being used. The requester 116 provides permission information, a partition ID containing the object, an identifier of the object to be accessed, an action (update or read) to be taken, and any of the options described above. In response, control element 150 returns the status of the request and the length of the specified object, along with the remaining capacity available to requestor 116.

FIG. 10 is a flow chart showing the Wrire-Object method. When the requestor 116 invokes this method, as indicated at block 242, the control element 150 writes the specified number of blocks into the specified object at the specified location.

Another method can also be called by the Write method. For example, if parity support is invoked on the devices 110-112 to be accessed, the write performs an exclusive-OR operation on the data to be written and parity data to be written to one or more pre-specified parity devices. The OR method can be called automatically.

In order to invoke this method, requestor 116 is allowed information, an object identifier, a partition ID, the start position of the block to be written in the object,
Provides some blocks to be written to the object, optional information, and data to be written. When this method is called, control element 150 modifies the specified object with the particular data provided. This is indicated by block 244. Control element 150 then modifies the required attributes in the specified object, such as object length, timestamp associated with the object, etc. This is indicated by block 246. The control element 150 then modifies the necessary attributes of other objects, such as the partition object list, if necessary. This is indicated by block 248. Control element 150 then returns the status of the request to the particular requester. This is indicated by block 250.

[0065] Figure 11 is a flow diagram illustrating the Open-Read-Only-Object _x methods. When this method is called, control element 150 allows requester 116 to access the specified object for read-only purposes. Thus, when this object is called, the requester provides permission information, partition ID, object ID, and option information, as shown in block 230. Next, control element 150 sets an attribute in the specified object to indicate that the object is being used. This is indicated by block 232. Control element 150 next
Sets the read-only attribute in the object to indicate that the object can not be written by the requester. This is indicated by block 234. Control element 150 then returns the state of the request and the length of the specified object. This is indicated by block 236.

FIG. 12 is a flow chart showing the Read-Objects method. This method is invoked by the requestor 116 when the requestor 116 wishes to return data from an object specified by the device 110. The requester has permission information, object ID,
Provides partition ID, start position of block to be read, some blocks to be read, and any other desired option information. In response to that
Control element 150 returns the status of the request, the length of the data returned, and the actual data returned in response to this method. This is illustrated by blocks 256 and 258.

FIG. 13 is a flow chart showing the Close-Objectx method. When the method is invoked by requestor 116, the requestor provides authorization information, an object ID, and any desired option information, as shown in block 264. In response, control element 150 modifies the data in the specified object as indicated at block 266. Furthermore, any changes in the object resulting from the writing to the object are written at this point, if not already written to the storage medium. As indicated at block 268, control element 150 also updates the attributes of object x. For example, if it is a newly created object, this attribute is updated with the creation time and other necessary attribute information. In addition, the attribute is modified to indicate the last time the data in the object was modified, the length of the data if it is changing, indicating that the object is no longer used by a given requester. Are set by the control element 150.

The control element 150 can optionally update the remaining cush information associated with the object and reflected in the object attributes. This is indicated by block 270. For example, if the particular requester 116 making the request is configured to inform storage 110 that the data is still cached for the closed object or is no longer cached, then the object is quick. The operating system of storage device 110 can maintain cache information for these applications that are subsequently reopened and closed again. However, at the same time, if another requestor requests access to this object, storage device 110 can keep track of which components in system 100 need to be notified of a coherency conflict. The control element 150 then returns the status of the request, as shown in block 272.

FIG. 14 is a flow chart showing the Remove-Object method. When this method is invoked, as shown in block 278, control element 150 takes the necessary steps to delete the object from the storage medium. This is indicated at block 280. Next, the control element 150 modifies the partition object list associated with the partition from which the object has been deleted, in order to reflect that the specified object ID is available. This is indicated at block 282. Control element 15 next
A zero returns the status of the request as shown in block 284. To invoke this method, requestor 116 provides permission information, partition ID, object ID, and any desired option information. The control element 150 then returns the status of the request, as shown in block 284.

FIG. 15 is a flow diagram illustrating a Create-Partitionx method that can be invoked by a requester to create a partition on storage device 110, as indicated at block 290. Note that although the Create-Partitionx method partitions the drive into one or more areas, it is not necessary to consider all the space on the storage medium. In addition, partition space can span different zones on the disk.

In one embodiment, this method is used to create partitions in a tile arrangement, where the partitions represent a true division of storage space on the device. This arrangement is used to divide the space by service levels such as data arrays. Such partitions can not be resized, but can be removed and regenerated.

In accordance with another aspect of the invention, partitions are used as logical partitioning to logically organize objects rather than managing space according to service levels. In this second embodiment, partitions can be dynamically resized.

In order to invoke this method, the requestor may enter authorization information, optional options,
The partition ID and initial space allocation identifying the space allocated to the identified specific part is provided. In response, as shown at block 292, control element 150 allocates space on the storage medium to a particular partition. Control element 150 then establishes a partition control object and a partition object list, as shown in blocks 294 and 296. As mentioned above, the partition object list can not be removed and serves as a starting point for navigating objects in the partition. Control element 150 then returns a partition map indicating the status of the request and the partitioning being performed. This is indicated at block 298.

FIG. 16 is a flow diagram illustrating the Remove-partitionx method. To invoke this method, requestor 116 provides permission information, option information, and a partition ID that identifies the partition to be removed. This is indicated at block 304. In response, control element 150 reassigns the space previously associated with the partition as shown in block 306. Control element 150 next
Removes all objects in the partition object associated with the partition to be deleted, deletes the partition object list and deletes the partition control object. This is indicated at blocks 308, 310, 312. Control element 150 then returns a partition map that indicates the status of the request and the changes made to the partitioning. This is indicated at block 314.

In accordance with one aspect of the present invention, a data management policy is stored on each storage device 110-11.
It is communicated to 2 and the storage devices are made to act independently of one another to execute the management policy. Not only does this reduce human intervention, but it also provides significant benefits of more predictable and timely management control.

For example, it may be desirable to back up the data on storage devices 110-112 weekly. Conventional systems are typically backed up during weekend idle periods to ensure that system availability is not interrupted during business days. However, at the same time as system capacity is increasing, availability windows are shrinking gradually. Thus, the problem of trying to find a system downtime long enough to backup possible terabytes of data becomes very difficult.

Thus, in accordance with one aspect of the present invention, by taking action on the object based on the assigned attributes, the object oriented storage 110-112 will be in the correct state for the object backup. Backup information can be notified whenever it reaches. Also, full file backups can be extended over time-while others are still updating-without affecting data integrity.

Other examples of attributes whose actions can be invoked by object oriented storage 110-112 include encryption, compression, versioning and parity redundancy. In each of these instances, storage devices 110-112 preferably need to inform only the policy for a particular object or set of objects. The device itself can then be informed of the agent instructed to perform the function or provide the service.

For example, compression and encryption may be implemented on storage devices 110-112 themselves. Thus, it is only the fact that compression or encryption is necessary for the object that needs to be communicated to the device. For management functions implemented by the agent, in addition to informing the storage device management function policy,
The identity of the agent performing the function should also be informed and storage should be accessible to the agent when performing the function.

According to one aspect of the present invention, associations are established between objects such that they can be identified to have the same attributes or dependencies. For example, assume that the database contains six files or objects, none of which can be backed up until all have been closed or everything else indicated as subordinate objects has been closed. A file server 14 may be required to manage this type of relationship between objects. Furthermore, the invention also establishes inter-device dependencies as in the case of array parity sets. Group management can be more efficient and effective if one device or object can establish a group to verify that the rest of the group have the same intrinsic properties.

FIG. 17-24 is a flow diagram illustrating a management function that can be implemented by invoking a method presented by an object on a storage device. By invoking the method, the control element 150 and / or the associated control element take steps to perform the management functions associated with the invoked method.

FIG. 17 is a flowchart showing the Expose-Object method. As indicated at block 320, the requestor 116 invokes this method by providing permission information, option information, object ID, target ID and target partition ID. Actions can be taken based on rules expressed in attributes associated with a given object by means of the export method. For example, it can be used to initiate backup or support versioning of objects to other devices.

When the Expose-Objectx method is called, as shown in block 32, control element 150 gets the specified object from the storage medium. Control element 150 then invokes the Open-Create method on the target device specified by requestor 116. This is indicated by block 324. The control element 150 then invokes the write method on the target device which supplies the data and attributes of the specified object. This is indicated by block 326. The control element 150 then invokes the Close method on the target device to close the objects thereon after being written to the target device. This is indicated by block 328. Finally, control element 150 returns the status of the request to the requester with the new object ID of the object being written to the target device. This is indicated by block 330.

The interface 128 implemented by the control element 150 also supports a method that allows the requester to obtain object attributes for review and to set the object attributes. Figures 18 and 19 show the corresponding Get _- Objectx-Attrib
FIG. 5 is a flow diagram showing the utes and Get-Objectx-Attributes methods.

As shown at block 336, when the method shown in FIG. 18 is called, the control element 150 gets attributes for the specified object. In one embodiment, the requester provides authorization information, an object ID, or a list of object IDs, and optional information. Control element 150 then obtains a list of attributes or object IDs associated with the object ID and returns these attributes to the requester along with the status of the request. This is indicated by block 338.

As shown in block 344, the Get-Objectx-Attributes method shown in FIG. 19 can be invoked by a requester that provides permission information, object ID, and option information to the control element 150. The control element 150 then modifies the attributes of the specified object with the information provided by the requester, and returns the status of the request with the attributes of the specified object. This is indicated by blocks 346 and 348.

In another embodiment of the present invention, an object can be locked so that it can not be accessed unless it is unlocked by the server that owns the lock placed on the object. In one embodiment, objects can be locked at the object level, partition level, or device level. The lock mechanism provides inter-server access resource. In the preferred embodiment, such a lock is used to schedule concurrent updates as well as prohibit access during maintenance function periods. Figures 20, 21 and 22 show Get-Attribute and Set.
FIG. 6 is a flow diagram showing a locking method that can be considered as an instance of the Attribute method. However, these particular instances of these methods will be described in more detail so that they can be used to share data between requester clusters.

FIG. 20 is a flow chart showing the Read-Rock-Attributes method. As shown at block 344, the method may include authorization information, objects, partitions or
, Lock parameters, and any desired option information from the requestor 116 to the control element 150 can be invoked and invoked. In response, control element 150 determines whether the specified object has a lock to be set. The control element 150 then returns the state of the request of the requester that owns the lock. This is indicated by block 356.

FIG. 21 is a flow chart showing the Set-Lock-Attributes method. As indicated at block 362, the method may be invoked by the requester with authorization information, object, partition or device identifier information, lock parameters, option information. When this method is called, control element 150 examines the lock associated with the identified object. This is indicated by block 364.
The control element then attempts to perform a lock or unlock operation with the identity of the requestor. This is indicated by block 366. If the requester requesting the operation is the owner of the lock, the operation is performed. Otherwise, the operation is not performed. In any case, control element 150 returns the status of the request with the ID of the server that owns the lock. This is indicated by block 368.

FIG. 22 is a flow diagram illustrating the Reset-Lock-Attribute method. This function is used to try to reset the lock if the server that owns the lock no longer functions. As shown at block 374, the method may be invoked with authorization information, object, partition or device identification information, lock parameters, and optional option information. In response, as shown at block 376, the control element 150 locks the specified object, partition or device and returns the status of the request with the identity of the server that owns the lock. This is indicated by block 378.

FIGS. 23 and 24 are flow diagrams showing the Get and Set-Device-Association method. These methods define or query the relationship between devices 110-112.
One implementation of such a relationship is one of storage devices 110-112.
One is identified as the master of the first set of devices, including the other being a dependent member of that set. The first or master set is responsible for disseminating set attribute changes to other members. Other members can reject the attribute setting if not supplied from the first or master set. Storage devices 110-112 are given the ability to perform self-tests to perform these functions. The device can then examine the device itself to see if it is included in the large device group membership.

FIG. 23 shows the Get-Device-Associations method. As shown at block 384, the method may be invoked with authorization information, option information. In response, control element 150 returns the status of the request and the requested association of which the device is a member. This is indicated by block 386. Figure 24 shows Set-Device-Associa
FIG. 5 is a flow diagram illustrating the methods of As shown in block 392, the method can be invoked with attributes defining permission information, option information, and member lists and associations. In response, as shown at block 394, control element 150 modifies device-related objects 156 contained on the storage medium.
The device-related object is modified to include an attribute given by the requester, a timestamp indicating the time at which the object attribute is last modified, and so on.
As indicated at block 396, control element 150 returns the status of the request.

By controlling which requester 116-120 gives the certificate necessary for the file server 114 to obtain a response from the storage device 110-112 according to the above described permission information, the file server 114 can It has gate access to the storage device. In addition, the storage device 1 that the file server 114 can only accept I / O requests that follow the installation security policy.
Command 10-112. The key underlying authorization security capabilities is Set-Device-A
It is shown communicating with storage devices 110-112 according to the ttributes method. If appropriate security is set for storage devices 110-112,
The storage can be configured to check every I / O command for security compliance. However, as mentioned above,
Some applications do not need to use security. Furthermore, if a particular server cluster has one device located in another physical facility, high level security is defined for communication with remotely located devices, but for communication from local traffic It is desirable not to do so. This makes it possible to use security for remotely located requesters or servers but avoid the performance loss associated with using such security for local requestors or servers.

Furthermore, each storage unit 110-112 preferably includes a readable monotonically incrementing clock used for timestamp security messages and objects. In one embodiment, the clocks for the various devices are synchronized on a system wide basis. In another embodiment, file server 114 adjusts for storage differences and values.

Thus, it can be seen that the present invention provides an object oriented storage such as a disk drive that has significant advantages over conventional storage. Object oriented storage significantly improves the cluster architecture. For example, by storing data in an object-oriented manner, data can be managed by the storage device itself. The object is given sufficient knowledge of its resident data so that the object can be responsible for managing its own space. Furthermore, data sharing can be more intelligently controlled if the device has information about what constitutes a logical entity. For example, if two systems share data stored on a block oriented device, then all metadata activities have to be controlled for simultaneous access. In contrast, in object-oriented devices, most metadata activity is opaque to the system accessing it. Thus, the system need only be concerned with access conflicts with user data. Furthermore, the space management implemented by the device itself eliminates any conflicts or confusion that may arise from two systems trying to manage space on the same storage at the same time.

Furthermore, mixed computations are made much easier by object abstraction. Object oriented storage provides the ability to at least have features that the operating system can interpret.

In addition, performance in cluster systems is improved by using object oriented storage for several reasons. For example, metadata never leaves the device itself, and I / O operations are eliminated.

In addition, the device can know which objects are open or closed at any time, and can use this information to more effectively cache data.
Since the device knows the layout of the object to be read out, prefetching is also much more effective. The storage device can determine the sequential access pattern more effectively. The cache in the device can also hold metadata once for many systems accessing it. In addition, the device can be involved in the quality of service decisions, such as where to find data more appropriately. Typically, a device can do that only if it is responsible for allocating storage. In contrast, almost any operating system can not allocate data in zones on a disk drive. Thus, providing this capability to the drive itself improves performance.

The invention can also be implemented as a disk drive arranged as an array of drives. Drive arrays are often referred to as redundant arrays of inexpensive disks (RAID) because the information stored on the disk drive array is often far more valuable than the disk drives themselves. Several RAID systems, or RAID levels, are known. For example, as described above, the first level RAI
D features a mirror disk. In the fifth level RAID, both parity and redundant data as well as both data stored in the array are disseminated to all disk drives in the group. The fifth level RAID distributes data and check information across all disks including check disks. U.S. Patent No. 5,617,425
DISC ARRAY HAVING ARRAY SUPPORTING CONTROLLERS AND INTERFACE OTHER RAI
D levels (eg, levels) are described in detail.

FIGS. 25-29 show a write operation according to one aspect of the invention, in which data is stored as objects on disk drives in an array. In the example shown in FIG. 25, file server 114, requestor (ie, host) 116 and interconnect 122 connect to a disk drive array including target drives 402 and parity drives 404 configured as storage devices such as storage devices 110-112. It is done. The target drive 402 holds the object to be written or a part thereof, and the parity drive 404 holds parity information related to the target object stored on the target drive 402.

In FIG. 25, the drive array is implemented as a RAID 5 array in which data and parity are distributed across all the drives in the group. Therefore, the drive 402 is a target drive and the drive 404 is a parity drive only for this write operation. That is, the target drive 402 also holds parity information, and the parity drive 404 also holds data. However, for the single write operation described below, drive 402 is the target drive and drive 404 is the corresponding parity drive. It should also be appreciated that the present invention can be implemented using other RAID levels other than RAID level 5.
Those skilled in the art will appreciate the present invention in such a RAID system.

In FIG. 25, target drive 402 and parity drive 404 are connected to one another via a fiber channel interface or other suitable interface such as another serial interface.

FIGS. 26 and 27 show a target drive 402 and a parity drive 404, respectively. Each drive includes a control element 150 and one or more disks 132. Each drive also includes a / write (such as the data head described above) and an OR circuit 408. Target drive 402 includes disk space 410 for storing target objects to be written. Parity drive 404
It includes disk space 412 for storing the corresponding parity object. The operation of drives 402 and 404 is described below with respect to FIGS. 28 and 29.

Implementing a Small Computer System Interface (SCSI) XOR Command A conventional disk array allows the disk drive to perform the bit operations necessary to achieve parity protection against drive failure. Such a command causes the host (that is, the requestor) to access the sector to the disk and update the corresponding sector on another disk drive including parity information appropriately for any sector written to one disk drive. You need to be able to do it. However, the object oriented disk drive described above introduces a one-layer abstraction between the host and the actual storage sector on the disk drive. In particular, the disk drive manages disk space as an object so that the host (ie, requestor) does not have access to the underlying sector addressing scheme. The disk drive itself is responsible for space management, allowing the requestor or host to correlate some of the data written on one disk drive to another disk drive's location. Therefore,
The requester does not know the address on the disk drive of the block it wrote and can not calculate the corresponding parity address. Therefore, as mentioned above, X
Using the OR function with object-oriented disk drives can be very difficult, if not impossible.

Thus, the present invention provides a method called Define-Parity-Group, which is called at each disk drive in a set of disk drives that make up a parity group. This method does two things. First, it provides sufficient information to enable the Write _- Object method to perform the same function as a sector-based XOR command in a conventional drive array. It also creates an object on each drive in the set that holds that particular driver's share of parity data. The parity object ID is a known ID known to each drive, such that any drive waiting for parity information update is made aware of the correct object identifier that can address the request.

The Define-Parity-Group method is described in detail with respect to FIG. First, the requestor or host invokes this method on each drive in the parity group. It is indicated by block 420. To invoke this method, the requester provides several things, such as: 1. An ordered list of drives containing parity groups. It can include, by way of example, a serial number and an address for each drive. 2. Algorithm used for parity calculations. In one simple implementation, modulus arithmetic is performed on the block addresses of the data to be written. This arithmetic provides the parity drive address (ordered list from item number 1) and the relative block address in the parity object on the parity drive (the relative portion of the parity object containing the desired parity information). 3. Amount of data in parity stripe in blocks as an example. If parity data is scattered throughout the space on each drive, this information is in atomic units of allocation. 4. Parity object identifier. Write-Ob to update parity object
The drive invoking the eject method distributes it to this object ID on the parity drive which is sought as described in 2 above. Multi-level parity (
Please understand that two-level parity can be realized. Thus, each drive can have up to two parity objects. In one implementation, when the drive is used in a disk array with two level parity, two known object IDs are assigned and stored by each drive. The presence of the second parity object indicates that two level parity is being used. 5. Parity object allocation policy. It indicates whether each drive allocates a parity object as a single contiguous range of disk space or distributes user data objects to the parity object. Thus, although the parity and data objects are shown as contiguous disk space in FIGS. 26 and 27, it is only an example. Note that if data is distributed to parity objects, it can be done before allocation.

In response to the Define-Parity-group method call, the control element 150 in each disk drive in the parity group calculates the percentage of space required for parity data. It is shown at block 422. The amount of space required for the parity object is determined based on the number of disk drives in the parity group list. For example, if there are nine disk drives in the list, each drive must allocate one-ninth of its space for parity information. This amount of space is identified by the known parity object ID provided by the requestor or host at the time of invocation of the method. It is shown at block 424.

Each drive in the parity set or group list holds the information defining the parity group so that each time the disk drive is powered up or reset, it can be verified that the parity group is not damaged . Thus, as indicated at block 426, the information is stored in non-volatile memory.

Once the disk drive's parity set has been created in this way and space to hold one or more parity objects has been allocated on each disk drive, it has been stored in a data object on one or more of the drives Data can be updated. FIG. 29 is a block diagram illustrating updating of data objects and corresponding updating of parity objects according to one aspect of the present invention.

Requester 116 requesting data to be updated to update data
Calls the Write-Object method described above on one disk space in the parity group. In the example of FIGS. 25-27, the requestor 116 invokes the Write-Object method on the target drive. It is shown at 428 in FIG.
9 is shown at block 430. Requester 1 to invoke this method
For example, an object identifier 16 for identifying an object to be updated, a partition ID, a start position of a block to be written in the object, some blocks to be written in the object, option information, and data to be written. The target drive 402 knows that the service of the Write-Object method must include updating the parity information associated with the object being updated. The target drive 402 defines it in non-volatile memory
-Know that it is because it stores information given and generated during execution of the Parity-Group method.

The target drive 402 performs several steps in order to update the parity information. First, it reads the old data from the specified location in the target object and provides it to the XOR circuit 408, along with the new data to be written to that location. It is shown at block 432 in FIG. 29 and arrow 434 in FIG.
, 436, 438.

Next, the target drive 402 XORs the old data with the new data to obtain intermediate parity information. It is shown at block 440 in FIG. Target drive 402 provides intermediate parity information at output 442 of FIG.
Next, target drive 402 targets new data 41
Write to the target location within 0 and update the target object. It is shown at block 444 in FIG.

The parity drive 404 then identifies the parity object corresponding to the target object 410 for which the target drive 402 itself has just been updated.
Invoke another Write-Object method above. It is shown at block 446 in FIG. 29 and at arrow 448 in FIG. The target drive 402 can calculate the target position for the parity object in several ways. For example, target drive 402 can calculate the position from the relative sector address of the block target object to be written. The relative address is divided by the number of drives in the parity group to give the relative address in the parity object on parity drive 404. Parity drive address is Define
-Determined by the algorithm specified in the Parity-group method. The target drive 402 then configures the Write-Object method to
Call it at the appropriate location in the object using this relative address on parity drive 404 which identifies T.12.

As an example, to calculate relative blocks within the parity object on drive 404 to be updated, target drive 402 can use the following equation: formula:

[Equation 1] Here, B is a relative block in the parity block, S is a relative sector address written in the target drive 402, and D is the number of drives in the parity group.

To calculate the parity drive address, target drive 402 can use the following equation: formula:

[Equation 2] If P is a displacement into the list of drives in the parity group of the parity drive (the list used to calculate P should exclude the address of target drive 402).

In response to this Write-Object method, parity drive 404 recognizes the command as a write to its parity object and performs parity operations. Such operations include reading old parity data, as indicated by block 450 in FIG. 29 and arrow 452 in FIG. The parity drive 404 then sends the old parity data to the X by the intermediate parity data from the target drive 402.
OR It is indicated by block 454 in FIG. 29 and arrows 456, 458 in FIG. The result of the exclusive OR operation is the updated parity information written to the parity object of disk 132. It is indicated by block 460 in FIG. 29 and arrows 462 and 464 in FIG. This completes the update of the parity object.

Thus, the present invention provides several advantages over the sector based parity schemes conventionally used. For example, parity data does not scatter user data on a disk. User files (i.e. objects) can thereby be stored continuously for better performance. Furthermore, objects can be backed up or exported as true user data files. Because the parity data is not scattered, they are themselves significant and usable.

Also, when unloading the database to the parity group, the application can access from the requester without waiting for parity to be calculated immediately after the data is loaded. As a background process, parity information can be configured without interrupting access to data. The data can then be used more quickly. Conventional systems can not access data until all data has been loaded, including parity data configuration. Parity data is scattered into user data, and user data can not be loaded separately, but only for parity calculations.

Furthermore, because each disk drive in the parity group knows the other members of the parity group, the disk drive can verify that the targeted drive is correct by means of parity update. If the drive is replaced or the drive's address changes, it is detected and the operation is interrupted. The parity data is thereby protected against tampering.

Also, there is no need to use a special XOR command to invoke parity protection. By distributing the Define-Parity-Group command, the drive knows to simply extend the Write-Object command to include parity protection.
It can be done more transparently by the drive.

Additionally, second level parity can be supported without distributing additional I / O commands from the requester to the drive. Two Define-Parity-Group methods are invoked on the drive to activate dual fault protection. The drive knows that it needs to update two parity objects, one for each parity group. The drive can also check to ensure that there is only one drive in common between the two parity groups (otherwise the configuration is invalid).

The present invention includes a data storage system including a first storage medium 132 in which data configured as a plurality of objects 124-126 is stored. Each object has an attribute indicating its characteristic. Objects include redundant objects that store redundant information. A first control element 150 is operatively connected to the storage medium 132 and configured to provide an interface 128 to the objects 124-126. Interface 128 presents methods (methods 0-N) that are invoked to access objects 124-126.

In one embodiment, methods 0-N include the Define-Redundancy method, in which control element 150 allocates storage space for redundant object 412 when it is called.
In another embodiment, when the Define-Redundancy method is invoked, control element 150 stores information indicating the redundant set to which it belongs.

In another embodiment, the control element 150 calculates the size of the storage space allocated to the redundant object 412 when the Define-Redundancy method is called.

In another embodiment, when the Write-Object method is called, the control element 150 updates the specified data object with new data and updates the corresponding redundant object 412 based on the new data.

In another embodiment, the storage system comprises a plurality of storage devices 402, 404, and the first
Storage unit 402 includes a first storage medium 132 and a first control element 150,
The second storage medium 404 includes a second storage medium 132 and a second control element 150. In one such embodiment, the designated data object is at least partially stored on the first storage device, and the corresponding redundant object is at least partially stored on the second storage device. In one embodiment, the first control element 150 is a second
Call the Write-Object method on the storage device to update the redundant object.

The invention can also be implemented as a method of maintaining redundancy in a data storage device comprising a plurality of storage devices, each comprising a storage medium 132 and a control element 150. The method includes storing data on a storage medium 132, the data including a plurality of objects 124-12 each including an attribute indicative of a property of the object.
It is configured as six. An object contains redundant objects that store redundant information. The method further provides an interface 128 to the object presentation method (Method 0-Method N) which is invoked to access the object.

In one embodiment, the method proceeds to step 420 on a set of storage devices.
It is included to call the Define-Parity method and configure it to realize the desired redundancy scheme. In one embodiment, the method includes generating redundant objects 412 on each storage device in response to the calling step. The method further includes calculating a portion of storage space and assigning to redundant object 412 at step 422.

Although the numerous features and advantages of various embodiments of the present invention have been described with the details of the various structures and functions of the present invention, the present disclosure is for the purpose of illustration only, and more particularly for the present invention. With respect to the structure and arrangement of parts within the principles of the invention, the appended claims can be varied up to the full scope indicated by the broad general meaning of the expressed term. For example, particular elements may be varied depending upon the particular interface method and redundancy scheme used while maintaining substantially the same functionality without departing from the scope and spirit of the present invention.

Brief Description of the Drawings

FIG. 1 is a block diagram of a network attached storage system in accordance with an aspect of the present invention.

FIG. 2 shows an object model according to one aspect of the invention.

FIG. 3-1 is a block diagram of a first configuration in which an object on a storage device is accessed by a requester.

FIG. 3B is a block diagram of a second configuration in which an object on a storage device is accessed by a requester.

FIG. 4 is a perspective view of a disk drive in accordance with one aspect of the present invention.

FIG. 5 is a functional block diagram illustrating access of an object by a requester.

FIG. 5-1 is a functional block diagram showing access of an object by a requester.

FIG. 5-2 is a functional block diagram showing access of an object by a requester.

FIG. 6 is a partial view of a storage medium partitioned in accordance with one aspect of the present invention.

FIG. 7 is a flow diagram illustrating access of an object by a requester in accordance with one aspect of the present invention.

7-2 is a flow diagram illustrating access of an object by a requester in accordance with one aspect of the present invention.

FIG. 8 is a flow diagram illustrating the generation of an object in accordance with one aspect of the present invention.

FIG. 9 is a flow diagram illustrating opening and updating an object in accordance with one aspect of the present invention.

FIG. 10 is a flow diagram illustrating writing to an object in accordance with one aspect of the present invention.

FIG. 11 is a flow diagram illustrating opening an object for read-only in accordance with one aspect of the present invention.

FIG. 12 is a flow diagram illustrating reading an object in accordance with one aspect of the present invention.

FIG. 13 is a flow diagram illustrating closing an object in accordance with one aspect of the present invention.

FIG. 14 is a flow diagram illustrating removing an object in accordance with one aspect of the present invention.

FIG. 15 is a flow diagram illustrating creating a partition in accordance with one aspect of the present invention.

FIG. 16 is a flow diagram illustrating removing a partition in accordance with one aspect of the present invention.

FIG. 17 is a flow diagram illustrating exporting an object in accordance with one aspect of the present invention.

FIG. 18 is a flow diagram illustrating obtaining object attributes in accordance with one aspect of the present invention.

FIG. 19 is a flow diagram illustrating setting or modifying object attributes in accordance with one aspect of the present invention.

FIG. 20 is a flow diagram illustrating reading lock attributes in accordance with one aspect of the present invention.

FIG. 21 is a flow diagram illustrating setting lock attributes in accordance with one aspect of the present invention.

FIG. 22 is a flow diagram illustrating resetting an object's locking attributes in accordance with one aspect of the present invention.

FIG. 23 is a flow diagram illustrating obtaining device associations in accordance with one aspect of the present invention.

FIG. 24 is a flow diagram showing setting device association according to one aspect of the present invention.

FIG. 25 is a block diagram illustrating a disk drive array implemented in accordance with an aspect of the present invention.

FIG. 26 is a block diagram illustrating a target disk drive in accordance with one aspect of the present invention.

FIG. 27 is a block diagram illustrating a parity disk drive in accordance with one aspect of the present invention.

FIG. 28 is a flow diagram illustrating the generation of parity groups according to one aspect of the present invention.

FIG. 29 is a flow diagram illustrating a write operation in which parity information is updated in accordance with one aspect of the present invention.

Claims (13)

[Claim of claim] 1. A data storage device storing data configured as a plurality of objects each having an attribute indicating a property of an object, the object including a redundant object for storing redundant information. A data storage comprising: a storage medium; a first control element operatively connected to the first storage medium and configured to provide an interface with the object presenting a method to be called for accessing the object. apparatus. 2. A method of maintaining redundancy in a data storage system comprising a plurality of storage devices each comprising a storage medium and a control element operatively connected thereto, said method comprising the steps of: Data configured as a plurality of objects including an attribute indicating an object, the object storing data including a redundant object storing redundant information on a storage medium, and a method called for accessing the object Providing an interface to the objects to be presented; and a method of maintaining redundancy. 3. The method of claim 2, further comprising: invoking redundancy definition methods on a set of multiple storage devices to configure them to achieve a desired redundancy. . 4. The method of claim 3, further comprising: in response to the calling step, generating redundant objects on each of the set of storage devices. 5. The method of claim 4, wherein the generating step comprises: calculating a portion of the storage space and assigning to a redundant object. 6. The method according to claim 3, further comprising: calling a write method on a first storage device of the plurality of storage devices to cause the first control element on the first storage device to A method comprising: updating a specified data object on a first storage medium on one storage device. 7. The method according to claim 6, further comprising, in response to the write method, invoking a parity write method on a second storage device of the plurality of storage devices on the second storage device. Updating the parity object associated with the specified data object stored on the second storage medium of 8. The method of claim 7, wherein the step of invoking the writing method comprises the steps of: reading old data from the specified data object; and writing new data in the specified data object. 9. The method according to claim 7, wherein the step of invoking the redundant writing method comprises: performing an OR (XOR) operation on the old data and the new data to obtain intermediate redundant data; Invoking a redundant write method on a second storage device to provide redundant object identification (ID). 10. The method according to claim 9, further comprising the steps of: reading old redundant data from the redundant object in response to the call of the redundant write method; XORing the old redundant data with the intermediate redundant data to generate a new Obtaining redundant data, and writing new redundant data into the redundant object. 11. The method according to claim 9, further comprising: specifying the storage device based on the number of storage devices in a set of storage devices and the position in a designated data object to which new data is written. Calculating whether the data object contains redundant objects associated with the data object. 12. The method according to claim 11, further comprising: updating the redundant object based on the number of storage devices in the set of storage devices and the position in the designated data object to which the new data is written. Calculating the position within. 13. A data storage system, wherein the system stores data configured as a plurality of objects, each having an attribute indicative of a property of the object, the object storing a first redundancy information storing redundancy information. A first storage medium containing the object, and a first control element operatively connected to the first storage medium and configured to provide an interface with the object;
A plurality of objects having a first disk drive including a second disk drive presenting a method called by the interface to access the object, an operationally first disk drive, and an attribute each indicating a property of the object A second disk drive including a first data object for storing data corresponding to redundant information in the first redundant object, the second disk drive being connected to a medium storing data configured as: A second control element connected to the second storage medium and configured to provide an interface with the object, the interface presenting a method called to access the object.