Electrical computers and digital processing systems: memory – Storage accessing and control – Specific memory composition
Reexamination Certificate
2001-03-06
2003-02-18
Yoo, Do Hyun (Department: 2187)
Electrical computers and digital processing systems: memory
Storage accessing and control
Specific memory composition
C711S113000, C711S161000, C711S162000, C714S006130, C714S020000
Reexamination Certificate
active
06523087
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to performance enhancements for RAID storage systems and more particularly to a method and system for enhancing performance of non-full stripe writes by utilizing parity caching and parity logging.
BACKGROUND OF THE INVENTION
A typical data processing system generally involves one or more storage units which are connected to a host computer either directly or through a control unit and a channel. The function of the storage units is to store data and other information (e.g., program code) which the host computer uses in performing particular data processing tasks.
Various types of storage units are used in current data processing systems. A typical system may include one or more large capacity tape units and/or disk drives connected to the system through respective control units for storing data. However, a problem exists if one of the storage units fails such that information contained in that unit is no longer available to the system. Generally, such a failure will shut down the entire computer system, which can create a problem for systems which require high availability.
This problem has been overcome to a large extent by the use of Redundant Arrays of Inexpensive Disks (RAID) systems. RAID systems are widely known, and several different levels of RAID architectures exist, including RAID 1 through RAID 5, which are also widely known. A key feature of a RAID system is redundancy, which is achieved through the storage of a data file over several disk drives and parity information stored on one or more drives. While the utilization of a RAID system provides redundancy, having to break a file into several parts, generate parity data, and store the file and parity on the array of disk drives can take a significant amount of time. It is therefore advantageous to have a RAID system that can process the data and generate parity information quickly to provide enhanced performance.
With reference to
FIG. 1
, a typical RAID system
10
contains a host computer
12
, at least one controller
14
, and a number of disk drives
16
,
17
,
18
,
19
. It should be understood that the number of drives shown in
FIG. 1
are for the purpose of discussion only, and that a RAID system may contain more or fewer disk drives than shown in FIG.
1
. Data is written to the drives
16
,
17
,
18
,
19
in such a way that if one drive fails, the controller can recover the data written to the array. How this redundancy is accomplished depends upon the level of RAID architecture used, and is well known in the art.
The controller
14
is connected to the host computer
12
, which communicates with the controller unit
14
as if it were communicating to a single drive or other storage unit. Thus, the RAID looks like a single drive to the host computer
12
. The controller unit
14
receives read and write commands, and performs the appropriate functions required to read and write data to the disk drives
16
,
17
,
18
,
19
, depending upon the RAID level of the system. Typically, when the host computer
12
issues a write command, the controller unit
14
receives this command and stores the data to be written in a memory location, and sends a reply to the host computer
12
that the write is complete. Thus, even though the data may not have been written to the disk drives
16
,
17
,
18
,
19
, the host computer
12
believes that is has been written. The controller unit
14
then takes appropriate steps to process and store the data on the disk drives
16
,
17
,
18
,
19
. It is common for a controller unit
14
to receive several write commands before completing the first write command, in which case the other write commands are placed in to a queue, with the data written for each command as the controller unit
14
works through the queue.
When storing data, generally, the controller
14
receives the data and breaks the data down into blocks which will be stored on the individual disk drives
16
,
17
,
18
,
19
. The blocks of data are then arranged to be stored on the drives
16
,
17
,
18
,
19
. In arranging the blocks of data, the controller
14
organizes the blocks into stripes and generates a parity block for each stripe. The data blocks are written across several drives, and the parity block for that stripe which is written to one disk drive. In certain cases, the data may not be large enough to fill a complete stripe on the RAID system. This is known as a non-full stripe write. When the data sent to the controller occupies a full stripe, the data is simply written over existing data and the parity is written over the existing parity. Additionally, in certain cases, the controller may aggregate several small writes together to create a full stripe of data, which the controller treats as a fill stripe of data for purposes of generating parity. However, in the case of a non-full stripe write, modifying the stripe of data requires several steps, and is a disk intensive activity.
The occurrence of non-full stripe writes is common in many applications, such as financial, reservation and retail systems, where relatively small data records are widely used and are accessed and modified at random. When an individual customer record needs to be revised, it may reside in a stripe of data that contains several other customer data records. In such a case, only a portion of the stripe needs to be modified, while the remainder of the stripe remains unaffected by the modification of the data.
With reference to
FIG. 2
, a flow chart representation for completing a non-full stripe write operation is shown. First, shown in block
20
, the RAID controller receives new data to be written to the disk array. Next, shown in block
24
, the controller reads the old data from the disk array. Then, the controller reads the old parity from the disk array, shown in block
28
. The two reads of blocks
24
and
28
may be issued by the controller at the same time, however, they may finish at different times, depending upon several factors, such as other disk activity. Next, shown in block
32
, new parity is created by XORing the old data and old parity with the new data. This results in new parity that is generated for the stripe of data. The controller then writes the new data to the disk array, shown in block
36
. Finally, the controller writes the new parity to the disk array, shown in block
40
. Like the read commands above, the two write commands may be issued by the controller at the same time, although they may finish at different times. When both writes complete, the parity and data are consistent on the disk. When the data has been written but the parity write has not completed, then the parity is not consistent on the disk array. The same is true when the parity has been written but the data write has not completed.
This non-full stripe write process is slow and opens the possibility for data corruption. Normal RAID input and output operations can handle any single failure, but data corruption can occur if there is a double failure. For example, a single failure may be a failure of one hard drive. In such a case, the controller will detect the hard drive failure and operate the RAID system in a critical mode, using the parity drive to generate missing data located on the failed hard drive. Likewise, a single failure may be a controller rebooting, which may occur when all of the data has not been written to the disk drives yet. In this case, the data will still be in the controller non-volatile memory, and when the controller initializes, it will detect the data in memory, compute parity and write the data and parity to insure that the data and parity are valid on the disk drives. If the controller reboots after the data has been written, but prior to the parity being written, the parity for the stripe may be recomputed using the data in that stripe. A double failure is a situation where the controller reboots and then a hard drive fails while the parity and data are not consistent. In such a situation, customer data may be lost, because the con
Chaparral Network Storage Inc.
Sheridan & Ross P.C.
Song Jasmine
Yoo Do Hyun
LandOfFree
Utilizing parity caching and parity logging while closing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Utilizing parity caching and parity logging while closing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Utilizing parity caching and parity logging while closing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3146177