Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration – Loading initialization program
Reexamination Certificate
2000-11-16
2004-06-01
Butler, Dennis M. (Department: 2115)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
Loading initialization program
C714S006130, C714S006130
Reexamination Certificate
active
06745324
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to memory systems, and more particularly to an apparatus and method that can dynamically create an executable image from an object file stored in a reserved area of a data storage device of a memory system including a Redundant Array of Independent Disks (RAID) system.
BACKGROUND OF THE INVENTION
Modern computer networks frequently require large, fault-tolerant memory systems. One approach to meeting this need is to provide a RAID system having a number of hard disk drives operated by a controller that is coupled to a host computer. RAID systems improve storage reliability, availability and system performance by providing storage capacities larger than any single data storage device. This larger storage capacity enables more data to be stored and accessed more rapidly. In addition, the larger storage capacity improves reliability by providing redundancy and allowing storage of parity and/or error checking bits.
RAID systems can be configured to store the data in numerous alternative ways commonly referred to as RAID levels. There are six basic RAID levels, each possessing different advantages and disadvantages. These levels are described in, for example, an article titled “A Case for Redundant Arrays of Inexpensive Disks (RAID)” by David A. Patterson, Garth Gibson and Randy H. Katz; University of California Report No. UCB/CSD 87/391, December 1987, which is incorporated herein by reference. RAID level
2
uses non-standard disks and as such is not normally commercially feasible.
RAID level
0
employs “striping”, where the data is broken into a number of stripes which are stored across the disks in the array. This technique provides higher performance in accessing the data but provides no redundancy which is needed in the event of a disk failure.
RAID level
1
employs “mirroring”, where each unit of data is duplicated or “mirrored” onto another disk drive. Mirroring requires two or more disk drives. For read operations, this technique is advantageous since the read operations can be performed in parallel. A drawback with mirroring is that it achieves a storage efficiency of only 50%.
In RAID level
3
, a data block is partitioned into stripes which are striped across a set of drives. A separate parity drive is used to store the parity bytes associated with the data block. The parity is used for data redundancy. Data can be regenerated when there is a single drive failure from the data on the remaining drives and the parity drive. This type of data management is advantageous since it requires less space than mirroring and only a single parity drive. In addition, the data is accessed in parallel from each drive which is beneficial for large file transfers. However, performance is poor for high input/output request (I/O) transaction applications since it requires access to each drive in the array.
In RAID level
4
, an entire data block is written to a disk drive. Parity for each data block is stored on a single parity drive. Since each disk is accessed independently, this technique is beneficial for high I/O transaction applications. A drawback with this technique is the single parity disk which becomes a bottleneck since the single parity drive needs to be accessed for each write operation. This is especially burdensome when there are a number of small I/O operations scattered randomly across the disks in the array.
In RAID level
5
, a data block is partitioned into stripes which are striped across the disk drives. Parity for the data blocks is distributed across the drives thereby reducing the bottleneck inherent to level
4
which stores the parity on a single disk drive. This technique offers fast throughput for small data files but performs poorly for large data files. Other somewhat non-standard RAID levels or configurations have been proposed and are in use. Some of these combine features of RAID configuration levels already described.
The controller provides the brains of the memory system, coordinating the operation of the disk drives to perform read and write functions, parity generation and checking, and handling drive failures without interrupting host requests. To provide this functionality utilizing minimal host processor time and without modifying user applications the controller typically includes a processor or Central Processing Unit (CPU), Random Access Memory (RAM) and a Programable Read Only Memory (PROM). In addition, the controller also includes firmware or microcode whose primary purpose is to initialize the memory system when it is first turned on. The process of initializing the memory system is commonly referred to as “booting”, the system. Firmware is essentially a series of machine instructions stored in the PROM or other non-volatile memory. After power to the controller is turned on, the CPU begins to execute the firmware instructions and initialize the memory system. Thereafter, the controller functions to allow other operations to be performed, i.e., enables a host computer to write data to and read data from the memory system.
One problem or limitation encountered in the design of RAID systems concerns problems with the controller firmware. Basically, if the controller firmware has any program errors or if the components or configuration (RAID level) of the memory system needs to be changed, the firmware stored in the PROM must be upgraded, namely, replaced by another program without the problems or errors. Traditionally, this involved removing the existing PROM from the controller and replacing it with a new PROM pre-programmed with the corrected or upgraded programs. The latest generation of controllers uses Electronically Erasable PROM (EEPROM), also known as Flash EPROM, that along with utility programs on an attached host computer, allow the EEPROM to be erased and reprogrammed in-situ with new firmware downloaded via a host interface.
Significant problems remain, however, in that the above procedure typically requires that a user stop or shut down the controller prior to upgrading the firmware. This involves finishing or aborting all pending requests for data input/output, flushing the RAM, stopping background activities (such as Battery Back-up Unit monitoring, enclosure monitoring, and other periodic processes) and performing no host interrupts. After the firmware upgrade procedure, it is necessary to re-initialize the controller, sync up with a firmware power up procedure and, if needed due to a change in the configuration, to re-initialize and spin up disk drives in the array. These problems are multiplied if, as is often the case in larger computer networks, such as Wide Area Networks (WANs) and Local Area Networks (LANs), there are multiple RAID systems each coupled to a different host computer. In this situation the user must load or check to make certain that the firmware upgrade and the necessary utility programs are present on each host computer before beginning the upgrade procedure. Moreover, because the hardware and operating system on each RAID system and its associated host computer can vary due to differences in vendor, model or capacity, the user must check the upgrade to make certain the appropriate device drivers are present. This downtime can have a significant impact when the system is used, for example, in an information server, such as a server on the Internet running 24 hours a day and 7 days a week.
A more significant problem arises in those situations in which no interface between the controller of the RAID system and the host computer is possible. Inability to interface with the controller may be due to problems with the host computer, for example problems with the firmware in the RAID system may prevent loading an operating system for the host computer, or because the necessary utility program for erasing and reprogramming the EEPROM is not available on the host computer. The utility program can be unavailable because the host computer is a “closed system”, to which the user is unable or not authorized to load programs, or because the utility prog
Otterness Noel S.
Skazinski Joseph G.
Ananian R. Michael
Butler Dennis M.
Samodovitz Arthur J.
Suryawanshi Suresh K
LandOfFree
Dynamic firmware image creation from an object file stored... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic firmware image creation from an object file stored..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic firmware image creation from an object file stored... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3347232