|Publication number||US6912687 B1|
|Application number||US 09/568,996|
|Publication date||Jun 28, 2005|
|Filing date||May 11, 2000|
|Priority date||May 11, 2000|
|Publication number||09568996, 568996, US 6912687 B1, US 6912687B1, US-B1-6912687, US6912687 B1, US6912687B1|
|Inventors||Dennis Gates, Rodney A. DeKoning|
|Original Assignee||Lsi Logic Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Referenced by (7), Classifications (11), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates generally to disk array storage subsystems, and more particularly to a parity assist circuit having integral scatter-gather list processing features useful in such a subsystem
2. Description of Related Art
Modem mass storage subsystems continue to provide increased storage capabilities to fulfill user demands from host computer applications. Due to this critical reliance on large capacity mass storage, demands for enhanced reliability are also high. Various storage device configurations and geometries are commonly applied to meet the demands for higher storage capacity while maintaining or enhancing reliability of the mass storage subsystem.
A popular solution to these mass storage demands for increased capacity and reliability is the use of multiple smaller storage modules configured in geometries that permit redundancy of stored data to assure data integrity in case of various failures. These systems also frequently configure the array of smaller disk drives to enhance storage subsystem performance.
A redundant array of inexpensive (or independent) disks, commonly referred to as RAID, is a collection of disk drives which appears as a single (or virtual) large disk drive to a host computer. Part of the disk storage capacity is typically used to store redundant information about user data stored on the remainder of the storage capacity. This redundant information allows the disk array to continue functioning without the loss of data should an array disk drive member fail, and permits the regeneration of data to a replacement array disk drive member.
Several RAID disk array design alternatives were presented by David A. Patterson et al. in an article entitled A Case for Redundant Arrays of Inexpensive Disks (RAID), University of California Report No. UCB/CSD 87/391, December 1987. This article discusses improvements in performance, reliability, power consumption and scalability that disk arrays provide over single large magnetic disk drives, as well as five disk array arrangements known as RAID levels 1-5.
RAID level 1 comprises N data disks for storing data and N additional mirror disks for storing copies of the information written to the data disks. RAID level 1 write functions require that data be written to two disks, the second mirror disk receiving redundant information, i.e., the same information provided to the data disk. When data is read, it can be read from either disk.
RAID level 2 protects data using a Hamming code. However, RAID level 2 is seldom used largely because it requires special features not found in standard disk drives.
RAID level 3 comprises N+1 disks in which N disks are used to store data and the additional disk is used to store redundant information, i.e., parity information. During RAID level 3 write functions, each block of data is divided into N portions for storing among the N data disks. The corresponding parity information is calculated from the data written to the N data disks and is written to a dedicated parity disk. When data is read, all N data disks must be accessed. The parity disk is used to reconstruct the data in the event of disk failure.
RAID level 4 also comprises N+1 disks in which N disks are used to store data and the additional disk is used to store parity information. RAID level 4 differs from RAID level 3 in that data to be saved is divided into blocks, and each block is stored on a single one of the data disks. Writes still require access to two disks, i.e., one of the N data disks and the parity disk. In a similar fashion, read operations typically need only access a single one of the N data disks unless the data to be read exceeds the block length stored on each disk. As with RAID level 3, the parity disk is used to reconstruct information in the event of disk failure.
RAID level 5 is similar to RAID level 4 except that parity information, in addition to the data, is distributed across the N+1 disks. Thus, each disk includes some blocks for storing data and some blocks for storing parity information. Where parity information is stored is controlled by an algorithm implemented by the user. RAID level 5 differs from RAID level 4 in that the parity information is distributed across the disks rather than concentrated on one, which provides the opportunity to perform concurrent write operations.
RAID levels 0 and 6 were defined after the Patterson et al. article. RAID level 0 involves disk striping without data protection. Disk striping distributes data across multiple disk drives to permit parallel operations. Strictly speaking, the absence of redundancy makes the term RAID a misnomer, however RAID level 0 is commonly used interchangeably with disk stripping. RAID level 6 expands upon RAID levels 4 and 5 by providing N+2 disks in which N disks are used to store data and 2 disks are used to store two independently computed sets of parity information.
RAID levels 3-6 have become collectively known as parity RAID. The data stored in the subsystem is logically divided into stripes each subdivided into smaller units often referred to as “blocks.” A stripe is comprised of a group of related data blocks and a corresponding redundancy (i.e., parity) block (or blocks in RAID level 6 ). The parity data is calculated by determining the exclusive-OR (XOR) product of the associated data blocks. Advantageously, if one of the data blocks contains an error it can be reconstructed by calculating the XOR product of the remaining data blocks and the parity block. For instance, the XOR product of the second, third and fourth data blocks and the parity block is equal to the data in the first data block. Thus any missing or unavailable data block (or parity block) may be reconstructed from the remaining available blocks of any particular stripe.
RAID storage subsystems typically utilize a controller that shields the host computer from the details of managing the redundant array. In particular, the RAID controller typically performs all the above-identified parity computations with no intervention by, or even knowledge of the host system. The controller makes the subsystem appear to the host computer as one (or more) highly reliable, high capacity disk drive. Unbeknownst to the host system, the RAID controller distributes the host computer's data across numerous small independent disk drives with redundancy and error checking so as to improve subsystem reliability and/or performance. The RAID controller typically employs a central processing unit (CPU) and program memory that stores instructions for the CPU. RAID controllers also frequently provide cache memory to further improve performance. The cache memory is associated with the controller such that the storage blocks on the disk array are mapped to blocks in the cache memory. This mapping is transparent to the host computer. The host computer simply requests blocks of data to be read or written and the RAID controller manipulates the disk array and cache memory as required.
Posting the cached data to the disk drives is often done by a read-modify-write (RMW) method wherein the new data blocks to be posted are used in conjunction with the associated old data blocks and old parity data on the disk drives to compute the new parity data, as mentioned above. A second posting method, called the full write method (also referred to as a stripe write method or simply a stripe write) writes new data blocks and associated new parity data without reading the old data blocks or old parity data from the disk drives. Rather, all data blocks which comprise a stripe are resident in the cache memory, the new parity data is calculated therefrom, and the new data blocks and new parity block are written to the disk drives.
It is long known in the art that the CPU of the RAID controller can compute the XOR parity data as it reads and writes data from and to the disk drives (or as it receives data from the host systems). The CPU in a modern, high performance RAID controller has a number of responsibilities and can often be overloaded by its many computational functions. RAID controllers often also include a parity assist circuit for providing the XOR operations during parity calculations. Although the CPU could perform this function, the parity assist circuit relieves the CPU of this burden. For example, when the CPU determines that an XOR product is needed, it gives a short series of instructions to the parity assist circuit. These instructions typically include the address and length of a first operand, the address and length of a second operand, and the destination address and length for the result. In response to these instructions, the parity assist circuit obtains the first and second operands from the cache memory of the RAID controller, calculates the XOR product, and stores the XOR product at the destination address in the cache memory. In the meantime, the CPU may continue on to other operations while awaiting an interrupt from the parity assist circuit to signify that the XOR calculation is complete. As a result, the parity assist circuit saves the CPU a substantial amount of processing time.
Although the parity assist circuit helps speed the RAID storage subsystem, considerable room for improvement exists. For example, each time the CPU requests an XOR calculation from the parity assist circuit, the CPU generates a short series of setup instructions to compute a particular parity block from two source blocks. Each parity block computation therefore consumes CPU processing time to setup the computation parameters and start the parity assist circuit operating. Furthermore, each time the parity assist circuit completes an XOR calculation and generates an interrupt, the CPU halts the current operation and implements an interrupt routine. This typically involves saving CPU state information on a stack, executing an interrupt operation, then reloading the stored state information to resume the previous operation. Since XOR parity calculations are so prevalent in RAID storage subsystems, the high volume of CPU setup instructions to the parity assist circuit and subsequent interrupts by the parity assist circuit is a key performance factor.
Accordingly, a need exists for a parity assist circuit in RAID storage subsystems that reduces demands on processor overhead and improves performance.
The present invention solves the above and other problems, and thereby advances the useful arts, by providing a parity assist circuit that performs multiple XOR calculations using a scatter-gather list. Preferably, the parity assist circuit is part of a RAID controller and utilizes a scatter-gather list to provide multiple XOR products to the cache memory before sending an interrupt to the RAID controller CPU or receiving additional setup instructions from the processor. This structure provides rapid and efficient parity calculations and improves overall system performance by reducing overhead processing of the RAID controller's CPU.
Generally speaking, the parity assist circuit includes a scatter-gather list processor coupled with a control circuit that obtains a plurality of XOR operation operands/parameters in the form of a scatter-gather list, and an XOR engine that provides a plurality of XOR products in response to supplied operands and parameters. The destination locations of the XOR product computations are preferably also provided in the scatter-gather list definition.
In the preferred embodiment, a plurality of registers are defined within the parity assist circuit to define the scatter-gather list XOR operation parameters. In particular, registers for the first through N-th operands of the XOR operation, the destination location of the resulting XOR product and the length of the operation are provided in the parity assist circuit. In accordance with the present invention, these registers, rather than providing a single value for its corresponding parameter, provides a pointer to a list of such parameters. The first operand register points to a list of first operands to be used in a sequence of XOR operations. The second operand register points to a corresponding list of second operand values to be used in XOR computations and so on for all N operand registers and the destination register. The length of each XOR operation may be identified by a similar list of length entries pointed to by the value in the length register. In the preferred embodiment, the length of each operation is derived from a length field in the scatter-gather list entry of an operand—specifically a length portion of each scatter-gather list element identifying a source 1 operand value,
Corresponding registers in the parallel sets of corresponding registers define a tuple of parameters for a single XOR operation. A plurality of such tuples define a scatter-gather list.
When started, the parity assist circuit scatter-gather list processor preferably reads the scatter-gather lists pointed to by the registers into a local memory associated with the parity assist circuit. The scatter-gather list processor then processes these scatter-gather lists to cause the XOR engine element within the parity assist circuit to generate all requested XOR parity values and store them at the requested destinations.
Alternate embodiments may support a variety of other formats or structures of scatter-gather lists. For example, a scatter-gather list may be a data structure with all parameters and operands integrated into data structure elements constructed by the RAID controller CPU and stored in memory of the RAID controller. The control circuit of the parity assist circuit first transfers the scatter-gather list(s) to the local memory of the parity assist circuit. The control circuit then processes the scatter-gather list(s) to perform the requests multiple XOR parity computations.
In the preferred embodiment, the operands and parameters specified by the scatter-gather lists regardless of the structure of the list are retrieved from appropriate memory external to the parity assist circuit (i.e., from the RAID controller's cache memory or direct from the host system memory as appropriate for the particular embodiment). Local memory within the parity assist circuit may be used as temporary scratchpad memory to perform the requested XOR computation. The XOR products so computed from the operands are then transferred to the external memory locations specified as destinations in the scatter-gather list(s).
It is therefore an object of the present invention to provide a parity assist circuit that increases the utilization of a processor that requires frequent parity calculations.
It is a further object of the present invention to provide a disk array controller with a unique parity assist circuit for performing high speed parity calculations.
It is another object of the present invention to provide a disk array controller with a parity assist circuit that requires fewer setup instructions and generates fewer interrupts than conventional parity assist circuits thereby enhancing the speed and efficiency of the processor.
It is a yet another object of the present invention to provide a disk array storage subsystem with enhanced throughput and performance.
It is still another object of the present invention to provide a RAID storage subsystem that implements parity RAID with rapid XOR calculations using a conventional XOR engine.
These and other objects, features and advantages of the invention will be further described and more readily apparent from a review of the detailed description of the preferred embodiments which follows.
The following detailed description of the preferred embodiments can best be understood when read in conjunction with the following drawings, in which:
While the present invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
RAID controller 102 includes central processing unit (CPU) 112, program memory 114 (e.g., ROM/RAM devices for storing program instructions and variables for the operation of CPU 112), and cache memory 116 for storing data and control information related to the data stored in disk array 108. RAID controller 102 further includes host interface 120 for interfacing with host computer 152, drive interface 122 for interfacing with disk array 108, direct memory access (DMA) controller 124 for assisting CPU 112 with transferring data to and from cache memory 116, and RAID parity assist (RPA) circuit 126 for assisting CPU 112 with parity calculations. CPU 112, program memory 114, cache memory 116, host interface 120, drive interface 122, DMA controller 124 and parity assist circuit 126 are connected together by bus 130 to exchange of information among the devices.
Those skilled in the art will recognize that the block diagram of
DMA controller 124 transfers data between program memory 114 and cache memory 116 using a scatter-gather list constructed by CPU 112. The scatter-gather list contains multiple entries each of which define the starting address and size of a memory block in cache memory 116. Adjacent scatter-gather list entries represent non-contiguous memory blocks in cache memory 116 in order to increase the efficiency of read and write operations to and from the disk array 108. DMA controller 124 is also used to move blocks of data between cache memory 116 and the host computer 152 via host interface 120.
Scatter-gather lists in this known context of DMA controller 124 maps non-contiguous memory blocks in cache memory 116 to corresponding host memory locations or disk drive block addresses. The term scatter-gather in this context refers to the concept that the various blocks of the source and/or destination of a DMA data movement operation may be in non-contiguous locations of memory or disk. For instance, during a write operation, the scatter-gather list entries are arranged so that non-contiguous memory blocks in cache memory 116 intended for a given disk drive are continuously written to consecutive addresses of that disk drive. Similarly, during a read operation, the scatter-gather list entries are arranged so that consecutive addresses are continuously read from a disk drive and transferred to non-contiguous memory blocks in cache memory 116.
As presently practiced in the art RPA 126 has control registers 210 . . . 216 programmed by CPU 112 to define the desired XOR computation. For example, source 1 register 210 may be programmed with the address in cache memory of a first source block for the XOR parity computation. Other operands to be used in the XOR computation are programmed into other source registers up to and including source N register 212. Destination register 214 is programmed with the address for the resultant XOR parity block computed by XOR operation on the two provided source operands. Length register 216 is programmed to indicate the length of the data block XOR operation to be performed. Those skilled in the art will recognize that the specific set of registers utilized is a matter of design choice in implementation of such a device.
Further, it will be noted that each register 210 . . . 216 is shown as a bank of multiple such registers—a set of registers. Each related register of the parallel sets or banks of registers is used to define a single XOR operation. Specifically, source 1 register 210 is a sequence of multiple registers (parallel sets) each of which identifies a source operand for one XOR operation. In like manner other source registers including source N register 212 is a sequence of registers each of which defines an N-th source operand corresponding to a source 1 operand in a register 210. Destination register 214 and length register 216 are likewise parallel sets or banks of registers defining corresponding destinations and lengths for XOR operations. A single XOR operation is therefore defined by a tuple of registers, a source 1 register 210 and related other operands up to and through a corresponding source N register 212, a corresponding destination register 214 and a corresponding length register 216. A list of such operations is therefore defined by multiple such tuples in the parallel sets of corresponding registers. The end of the list may be flagged by, for example, a zero length value in a length register 216 of a tuple.
CPU 112 may program multiple XOR operation requests into the parity assist circuit 126 of
S/G processor 304 processes a first XOR operation defined by the scatter-gather lists read into local memory 300. A tuple in the parallel sets of registers 310 . . . 316 defines a scatter-gather list to be processed rather than a single XOR operation. After reading the scatter-gather list into local memory 300, the SIG list processor 304 loads a first XOR operation request from the list into the first tuple of the registers 310 . . . 316 and starts the XOR computation. Upon completion of a first XOR operation the SIG processor 304 looks for a next XOR operation defined in the scatter-gather list before indicating completion of the operation to CPU 112. Each XOR operation defined in the scatter-gather list in local memory 300 is processed in turn by S/G list processor and the corresponding XOR operation performed until all requests in the list are processed. At completion of the list processing, the CPU 112 is interrupted to indicate that the entire list of requests has been completed. Further details of the operation of improved RPA 126 are provided herein below.
The specific format of a scatter-gather list to be processed by S/G processor 304 is a matter of design choice. A number of scatter-gather list structures are known to those skilled in the art. The preferred structure for any given RPA design is one that is common to other scatter-gather lists used in the RAID controller. For example, CPU 112 typically creates scatter-gather lists to control the operation of DMA controller 124. A preferred embodiment is therefore one that uses a similar (if not identical) format to that used for DMA controller 124 of the RAID controller.
In the exemplary preferred embodiment of
Those skilled in the art will recognize other formats useful in particular applications. As noted above, the preferred structure of the scatter-gather list is a matter of design choice for the implementer.
In the preferred embodiment, scatter gather list formats used for other purposes by CPU 112 (of
A pointer to the head of list 600 is programmed by CPU 112 into each of the registers 310 . . . 314 of the parity assist circuit 126 to define a first series of XOR operations. The length value in the list element for the source 1 operand of each XOR operation is used as the length of the operation to thereby obviate the need for a separate length value list. This preferred embodiment is suggested by the structure of existing scatter-gather lists in one particular existing controller architecture. Since the length value is already encoded into each scatter-gather list element a separate length value is not required as a listed to be programmed in register 316. Those skilled in the art will recognize the equivalency of providing a scatter-gather list for length values as well. Such design choices are well known to those skilled in the art.
This format is preferred in that it provides a degree of compatibility with the prior architecture noted in FIG. 2. The use of such scatter-gather list processing may be selectively enabled or disabled in the improved parity assist circuit 126 of the invention. A few XOR operations may be programmed in the registers as is presently known in the art by placing the parameter values in the parallel sets of registers 310 . . . 316. Alternatively, scatter-gather list processing may be enabled in the parity assist circuit 126 and the registers 310 . . . 316 may be programmed with pointers to lists of corresponding parameter values.
Such a feature to enable or disable the enhanced operation would preferably be implemented as a signal applied to the RPA circuit by the controller's CPU. Such design choices are well known in the art and a variety of other techniques to enable and disable the enhanced operations will occur to those skilled in the art.
An alternative embodiment of a combined scatter-gather list is also shown in FIG. 6. Scatter-gather list 650 is another common format for such lists wherein the parameters for one XOR operation are all combined in an element of a list. Each element of the list defines all parameters for a single XOR operation. For example, element 652 of list 650 contains source operand pointer 652 . . . 658, a destination operand pointer 660, a length value 662 and a pointer to the next element 664. Subsequent elements in the linked list (666 and 680) similarly contain all parameters required for their respective XOR operations (i.e., parameters 668 . . . 678 and 682 . . . 692 for elements 666 and 680, respectively).
As noted above, a preferred scatter-gather list format is one that maintains compatibility with formats for other scatter-gather lists used within the RAID controller. The specific format used in practice of the improved RAP of the present invention is a matter of design choice well known to those skilled in the art.
Those skilled in the art will recognize that the scatter-gather lists may be retrieved in portions if the aggregate length of the lists is too long to save in local memory 300. In other words, elements of the parallel scatter-gather lists (500 . . . 506) may be retrieved as needed for the list processing by scatter-gather list processor 304. Lengthy scatter-gather lists may easily exceed the limited capacity of local memory 300.
Specifically, a first element 510.1 of list 510 is copied to register 310. A corresponding element 512.1 . . . 516.1 of each of the related parallel lists 512 . . . 516, respectively, is copied to a corresponding register 312 . . . 316, respectively. These values, 510.1 . . . 516.1, represent a first tuple, a first XOR operation of the scatter-gather lists 510 . . . 516. Scatter-gather list processor 304 (in conjunction with control logic 306) then initiates the XOR computation via XOR engine 302 operating using the values in registers 310 . . . 316. The computation involved in this first XOR operation is as known in the art as discussed above. When this first operation is completed, scatter-gather list processor 304 is next operable to copy elements defining the second tuple in the lists to the registers. Specifically, elements 510.2 . . . 516.2 of lists 510 . . . 516, respectively, are copied to registers 310 . . . 316, respectively. XOR engine 302 is again started to perform the XOR computation presently defined in the registers 310 . . . 316. This sequencing of XOR engine 302 and registers 310 . . . 316 by scatter-gather list processor 304 continues through elements 510.N . . . 516.N. When scatter-gather list processor completes processing of all N tuples defined in the copied lists 510 . . . 516, the CPU 112 (not shown) will be notified of completion of the entire list of operations.
Those skilled in the art will recognize similar functional relationships appropriate to other formats of scatter-gather lists. As noted above, the preferred scatter-gather list format and associated processing logic is determined for each application. Preferably the format is that of an existing scatter-gather list function performed within the RAID controller. The preferred format described herein permits backward compatibility with operation of known parity assist circuits such as that shown in FIG. 2.
The method of
Processing then continues with element 404. If scatter-gather list processing is not enabled in the improved RPA by CPU 112, processing jumps immediately to element 404.
Element 404 then processes a single XOR operation as defined by the present parameters defined in RPA registers 310 . . . 316. When the single XOR computation is completed element 406 again determines whether scatter-gather list processing is enabled. If not, processing is completed and element 410 posts a completion status as required by CPU 112 and interrupts CPU 112 to signify the operation is complete. As known in the art and as shown in
If scatter-gather list processing is enabled in the improved RPA, processing continues with element 408 to determine whether the end of the scatter-gather list has been detected. As noted above, the end of the list may be signified by a special reserved value in a scatter-gather list entry such as a zero length field or by a flag value associated with the last valid entry. Such design choices for an end of list signal are well know to those skilled in the art.
Details of the control circuit of the RPA to cause a sequencing through the plurality of entries in a scatter-gather list is a well known matter of design choice for those skilled in the art. Further, as noted above, the improved RPA of the present invention may be easily modified to accommodate any of several scatter-gather list structures and formats. The details of the control logic design to sequence through the list of entries is therefore dependent upon the specific scatter-gather list format used in the RPA application. All such control circuit designs are a matter of well known design choices to those skilled in the art.
When operating in a compatibility mode with prior know techniques (as shown in FIG. 2 and as described above), all standard registers (310 . . . 316) and shadow registers (710 . . . 716) may be exposed to the CPU for programming in the known manner (wherein each tuple of registers specifies an XOR operation to be performed). When operating in the scatter-gather list processing enhanced mode of operation, the CPU has access only to the standard exposed registers 310 . . . 316. The shadow registers are used by the RPA in processing each element of the parallel scatter-gather lists. In particular, as noted above, the RAID controller CPU programs pointers to scatter-gather lists in exposed registers 310 . . . 314. The CPU may program a set of pointers to a parallel set of scatter-gather lists in each tuple of registers in the standard exposed set of registers 310 . . . 314. As noted above, the length register is not used in this mode in the preferred embodiment. Rather, the length of each XOR operation is determined from the length value in each scatter-gather list element of the source 1 scatter-gather list.
For each set of lists pointed to by one tuple of exposed registers, the scatter-gather list processor processes the list of XOR operations by decomposing the lists into individual XOR operations (after copying the lists to the local memory as noted above). Each element in the parallel scatter-gather lists defines one XOR operation the parameters of which are copied into one tuple of the hidden (“shadow”) registers 700. The XOR engine and control logic (302 and 306 of
Still more specifically, the scatter-gather list processor may program a plurality of such individual operations into the shadow registers so as to prepare a continuous source of operations for processing by the XOR engine. In like manner, the RAID controller CPU may program additional scatter-gather lists into the tuples represented by the exposed registers. In this manner large sequences of XOR operations may be programmed to permit essentially continuous operation of the RPA device with minimal overhead processing required by the RAID controller CPU.
Element 402 of
In the alternative embodiment of
While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character, it being understood that only the preferred embodiment and minor variants thereof have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5708849 *||Jan 27, 1997||Jan 13, 1998||Intel Corporation||Implementing scatter/gather operations in a direct memory access device on a personal computer|
|US5883909 *||Nov 6, 1996||Mar 16, 1999||Lsi Logic Corporation||Method and apparatus for reducing data transfers across a memory bus of a disk array controller|
|US6065096 *||Sep 30, 1997||May 16, 2000||Lsi Logic Corporation||Integrated single chip dual mode raid controller|
|US6145017 *||Aug 7, 1998||Nov 7, 2000||Adaptec, Inc.||Data alignment system for a hardware accelerated command interpreter engine|
|US6151641 *||Sep 30, 1997||Nov 21, 2000||Lsi Logic Corporation||DMA controller of a RAID storage controller with integrated XOR parity computation capability adapted to compute parity in parallel with the transfer of data segments|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7636814||Dec 22, 2009||Symantec Operating Corporation||System and method for asynchronous reads of old data blocks updated through a write-back cache|
|US7743191||Dec 20, 2007||Jun 22, 2010||Pmc-Sierra, Inc.||On-chip shared memory based device architecture|
|US8756371||Oct 12, 2011||Jun 17, 2014||Lsi Corporation||Methods and apparatus for improved raid parity computation in a storage controller|
|US8782113||Aug 31, 2006||Jul 15, 2014||Infortrend Technology, Inc.||Method and controller for processing data multiplication in RAID system|
|US20070067697 *||Aug 31, 2006||Mar 22, 2007||Schnapp Michael G||Method and controller for processing data multiplication in RAID system|
|CN100414489C *||Sep 1, 2006||Aug 27, 2008||普安科技股份有限公司||Parity engine for use in storage virtualization controller and method of generating data by parity engine|
|CN100470489C *||Jul 18, 2006||Mar 18, 2009||普安科技股份有限公司||A method for processing data multiplication in a disk array and its controller|
|U.S. Classification||714/800, 714/E11.034, 714/6.24, 714/6.2|
|International Classification||H02H3/05, G06F11/10, G06F11/00|
|Cooperative Classification||G06F2211/1054, G06F2211/1009, G06F11/1076|
|May 11, 2000||AS||Assignment|
Owner name: LSI LOGIC CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GATES, DENNIS;DEKONING, RODNEY A.;REEL/FRAME:010806/0545
Effective date: 20000508
|Dec 24, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Oct 1, 2012||FPAY||Fee payment|
Year of fee payment: 8
|May 8, 2014||AS||Assignment|
Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AG
Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:LSI CORPORATION;AGERE SYSTEMS LLC;REEL/FRAME:032856/0031
Effective date: 20140506
|Jun 6, 2014||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:LSI LOGIC CORPORATION;REEL/FRAME:033102/0270
Effective date: 20070406
|Apr 3, 2015||AS||Assignment|
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LSI CORPORATION;REEL/FRAME:035390/0388
Effective date: 20140814
|Feb 2, 2016||AS||Assignment|
Owner name: AGERE SYSTEMS LLC, PENNSYLVANIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201
|Feb 11, 2016||AS||Assignment|
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH
Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001
Effective date: 20160201