USPatent applicationPatented

System and method for transparent hard disk drive update

Granted 18 Sep 2012 · 2 office actions

Current assignee: DELL MARKETING L.P. · originally Dell Inc.

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Don H. Walker, Russell Woodbury, Frank Widjaja Yu · Examiner: Tuan Q Dam · AU 2192 · TC 2100

Life of the application

25 dated events
⤢ drag to zoom2008201020122014201620182020202220242026ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

Information handling system hard disk drive firmware updates are initiated on a hard disk drive without disrupting operations of the information handling system. A firmware update is copied in executable form to the hard disk drive\'s buffer and executed by the hard disk drive\'s controller without aborting queued tasks or losing system synchronization. The controller then copies the firmware update to flash memory in parallel with execution of the firmware update so that the hard disk drive operates with minimal degradation in performance.

Description

5 parts
›BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to the field of information handling system hard disk drives, and more particularly to a system and method for transparent hard disk drive update.

2. Description of the Related Art

As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.

During normal operations, information handling systems typically depend on one or more hard disk drives to store information. Hard disk drives generally have one or more magnetic disks that provide persistent storage of information when the information handling system is powered down. Often, hard disk drives are used to store an operating system so that upon application of power the central processing unit (CPU) can retrieve the operating system in a bootstrapping process. Basic communications between the hard disk drive and CPU are managed through standardized bus systems, such SCSI or SAS bus systems, by a microcontroller included in the hard disk drive. The microcontroller operates based on firmware instructions stored in persistent memory of the hard disk drive. The hard disk drive firmware is generally “flashed” or loaded at manufacture of the hard disk drive so that the hard disk drive is prepared to interact with information handling systems when first powered up. However, hard disk drives do typically have a capability to re-flash the firmware in the event that an update is subsequently needed to the operations of the hard disk drive.

A number of difficulties exist with attempts to update hard disk drive firmware in an information handling system. These difficulties generally relate to the current process for performing firmware updates, which involves taking the hard disk drive offline while the firmware is updated. One concern is that taking the hard disk drive offline causes system downtime while the update to firmware takes place. For example, updates are stored in the hard disk drive buffer so that normal hard disk drive operations are halted and then power is cycled to bring the firmware into operation. The downtime involved with hard disk drive updates discourages end users from performing updates unless the danger of continuing with the current firmware is high. Thus, end users tend to avoid periodic hard disk drive updates made for proactive maintenance until a critical update arises that corrects potential problems of critical magnitude. This approach leaves hard disk drive operations susceptible to known vulnerabilities of lesser magnitude between critical updates.

›SUMMARY OF THE INVENTION

Therefore a need has arisen for a system and method which provides transparent hard disk drive updates performed in parallel with normal hard disk drive operations.

In accordance with the present invention, a system and method are provided which substantially reduce the disadvantages and problems associated with previous methods and systems for performing hard disk drive firmware updates. A firmware update is copied to a hard disk drive buffer and executed to manage hard disk drive operations without loss of synchronization or aborting queued tasks. The firmware update is background written to flash memory in parallel with normal hard disk drive operations.

More specifically, an information handling system interfaces with a hard disk drive through a bus. The hard disk drive has a controller that manages I/O tasks through the bus, such as writes or reads of information, by executing firmware instructions stored in flash memory and loaded into a buffer, such as DRAM. A firmware update module associated with the hard disk drive, such as instructions running on the controller, receives a firmware update through the bus interface and loads the firmware update in executable form in the buffer. The firmware update module ensures that queued tasks are not aborted by, for instance, flushing or storing queued tasks before execution of the firmware update. New tasks that arrive before execution of the firmware update are either refused with a busy or check condition status or, alternatively, stored for subsequent execution. Once the firmware update is executed from the buffer, the stored tasks are retrieved and executed, new tasks are actively managed, and the firmware update is background written to flash memory with limited controller resources so as to avoid excessive degradation of normal hard disk drive operations.

The present invention provides a number of important technical advantages. One example of an important technical advantage is that hard disk drive firmware updates are performed quickly in a transparent manner with minimal interference to normal hard disk drive operations. For example, outstanding I/O requests to the hard disk drive are not aborted to perform a firmware update. Firmware updates are interleaved with normal hard disk drive operations so that no loss of synchronization occurs in hard disk drive operations. By using busy status and check condition responses at specific points during the firmware update, the hard disk drive maintains its link with the information handling system throughout the firmware download process so that vulnerability to interrupted downloads is reduced from approximately 30 seconds with conventional downloads to approximately 2 seconds. Updates interleaved with normal I/O operations have a minimal impact on hard disk drive performance of approximately a 10% degradation for a typical period of 20 seconds or less.

›BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element.

FIG. 1 depicts a block diagram of an information handling system having a hard disk drive firmware update module;

FIG. 2 depicts a block diagram of a firmware update module;

FIG. 3 depicts a flow diagram of a process for executing a firmware update at a hard disk drive controller without loss of synchronization; and

FIG. 4 depicts a flow diagram of a process for storing the firmware update to flash memory as a background operation to normal tasks.

›DETAILED DESCRIPTION · 1 of 2

Firmware updates for information handling system hard disk drives are executed without loss of synchronization or undue degradation of normal operations. For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.

Referring now to FIG. 1 , a block diagram depicts an information handling system 10 having a hard disk drive 12 firmware update module 14 . Information handling system 10 is built from a variety of processing components, such as a CPU 16 , RAM 18 and chipset 20 that interact with hard disk drive 12 through a bus 22 . Hard disk drive 12 has a magnetic storage disk 24 that spins relative to a disk head 26 to allow writes and reads of information communicated with the processing components through bus 22 and a bus interface 28 . Writes and reads of information are managed by a controller 30 running firmware retrieved from a flash 32 and loaded in executable form into a buffer 34 , such as DRAM. The firmware is periodically updated through a network 36 with firmware updates provided by a firmware update source 38 . Firmware update module 14 retrieves a firmware update sent to information handling system 10 from bus interface 28 , stores the firmware update in buffer 34 in executable form, executes the firmware update on controller 30 to manage reads and writes of information, and then copies the firmware update to flash memory 32 in parallel while executing the firmware update on the controller 30 . Firmware update module 14 executes the firmware update on controller 30 without aborting tasks queued for the controller to manage, such as reads and writes of information. Firmware update module 14 is, for instance, an application running on controller 30 , a hardware solution or other solution capable of managing hard disk drive operations.

Referring now to FIG. 2 , a block diagram depicts a firmware update module 14 . A firmware update receiver 40 receives the firmware update from bus interface 28 and stores the firmware update in executable form in buffer 34 . In one embodiment, firmware update receiver 40 leverages storage disk 24 to store the firmware update for subsequent transfer to buffer 34 . Firmware update receiver 40 checks the firmware image upon completion of the download to ensure an accurate image or otherwise attempt another download. Once the firmware update is in executable form in buffer 34 , firmware update executor 42 executes the firmware update without a loss of synchronization or loss of queued tasks, typically in a time period of two seconds or less. Firmware update executor 42 manages queued tasks of controller 30 by either flushing the queue to accomplish the tasks before executing the firmware update or storing the queued tasks during the executing of the firmware update and restoring the stored tasks for subsequent management by the executing firmware update. In addition, firmware update executor 42 manages new tasks sent to controller 30 before executing the firmware update by responding with a busy status to the new tasks or by storing the new tasks for management after execution of the firmware update. Once the firmware update is executing on controller 30 to manage operations of hard disk drive 12 , a firmware update writer 44 performs a background write of the firmware update image to flash memory 32 . The background write occurs in parallel with normal operations of controller 30 by taking a limited number of processor cycles so that any degradation of performance of controller 30 in managing operations of hard disk drive 12 are insubstantial, such as no more than approximately ten percent degradation.

Referring now to FIG. 3 , a flow diagram depicts a process for executing a firmware update at a hard disk drive controller without loss of synchronization. The process begins at step 46 with receipt of a first write buffer associated with a firmware update. At step 48 , a determination is made of whether to reject or not reject new I/O tasks. If not rejected, the write buffers continue in parallel with new I/O tasks until the last write buffer is received at step 50 . If new I/O tasks are rejected, the process continues to step 52 to assert a check condition for new requests so that new I/O task requests are not sent until the firmware update is complete. After receiving the last write buffer at steps 50 and 54 , the process continues to step 56 to check if the firmware update image is a good image. If a fault has occurred in the download of the firmware update, the process ends at step 58 with a check condition so that another update attempt may take place.

Once the firmware image is stored in the buffer in executable form, the process continues to step 60 or step 70 based upon whether new I/O tasks were rejected at step 48 . If new tasks were not rejected, the process continues to step 60 to determine whether to flush the queue of pending tasks by executing those queued tasks before executing the firmware update. If the determination at step 60 is to not flush the queue, the queued tasks are stored at step 62 and the process continues to step 64 to determine whether to busy new I/O tasks. If a determination is made to busy new I/O tasks, a busy status is issued at step 66 and the firmware update is executed. If a determination is made at step 64 not to busy new tasks, the new tasks are placed in storage at step 68 and the firmware update is executed. If a determination is made at step 60 to flush the queue by executing queued tasks or new tasks are rejected at step 48 , the process continues to step 70 to reject new task requests with a busy status and to step 72 to complete outstanding queued tasks so that the firmware update can be executed. Busy and check condition statuses are selectively used as illustrated in FIG. 3 so that a firmware update is executed without a loss of synchronization and in a time period of two seconds or less. The determination of whether to enforce busy and check condition statuses may be based upon the number of queued tasks, the time expected to execute the firmware update or other factors.

›DETAILED DESCRIPTION · 2 of 2

Referring now to FIG. 4 , a flow diagram depicts a process for storing the firmware update to flash memory as a background operation to normal tasks. The process begins at step 74 with a unit attention status while the firmware update is initiated and a good status at step 76 when the firmware update has taken over management of the hard disk drive. At step 78 , a determination is made of whether tasks were in queue before execution of the firmware update. If queued tasks were stored, the process continues to step 80 to restore the queue. If no queued tasks were stored or all queued tasks are restored, the process continues to step 82 to determine if a background write to flash memory or the firmware update is needed. If so, the process continues to step 84 for the controller to write the firmware update to flash memory in parallel with execution of I/O tasks. The controller processing cycles dedicated to writing the firmware update are limited so that degradation of I/O tasks is limited by a predetermined amount, such as approximately ten percent. Once the firmware update is written to the flash memory, the process continues to step 86 to support normal I/O tasks and at step 88 the firmware update download is completed.

Although the present invention has been described in detail, it should be understood that various changes, substitutions and alterations can be made hereto without departing from the spirit and scope of the invention as defined by the appended claims.

Claims as granted

19 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

7 codes
IPC · International Patent Classification
Section G — Physics
  • G06F9/44
  • G06F9/46
USPC · US Patent Classification
717/170718/103718/104717/171717/169

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoom2007200820092010201120122013USPTOApplicantNon-final rejectionApplicant-initiated interview
USPTOApplicanthover for detail · click to open
Pendency
5.8 y
2,107 days filing → grant
Office actions
2
non-final + final
Responses
2
no RCE
Interviews
1
examiner interview summaries
Examiner
Tuan Q Dam
art unit 2192 · TC 2100
Citations: 71 back · 1 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom2008201020122014201620182020202220242026Owner 1liens, releases & corrections
TitleLienReleasehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock