Abstract:
A method for adopting an orphaned I/O port of a storage controller is disclosed. The storage controller has first and second redundant field-replaceable units (FRU) for processing I/O requests and a third FRU having at least one I/O port for receiving the I/O requests from host computers coupled to it. Initially the first FRU processes the I/O requests received by the I/O port and the third FRU routes to the first FRU interrupt requests generated by the I/O port in response to receiving the I/O requests. Subsequently, the second FRU determines that the first FRU has failed and is no longer processing I/O requests received by the I/O port, and configures the third FRU to route the interrupt requests from the I/O port to the second FRU rather than the first FRU, in response to the determining that the first FRU has failed.

Description:
CROSS REFERENCE TO RELATED APPLICATION(S)  
       [0001]     This application is a divisional of co-pending U.S. patent application Ser. No. 10/946,341 (Docket CHAP.0113) filed on Sep. 21, 2004.  
         [0002]     U.S. patent application Ser. No. 10/946,341 is a continuation-in-part (CIP) of the following co-pending Non-Provisional U.S. Patent Applications, which are hereby incorporated by reference in their entirety for all purposes:  
                                       Ser. No.               (Docket No.)   Filing Date   Title                   09/967,027   Sep. 28, 2001   BUS ZONING IN A CHANNEL       (4430-28)       INDEPENDENT CONTROLLER               ARCHITECTURE       09/967,126   Sep. 28, 2001   CONTROLLER DATA SHARING       (4430-29)       USING A MODULAR DMA ARCHI-               TECTURE       09/967,194   Sep. 28, 2001   MODULAR ARCHITECTURE FOR       (4430-32)       NETWORK STORAGE CONTROL-               LER       10/368,688   Feb. 18, 2003   BROADCAST BRIDGE APPARATUS       (CHAP.0101)       FOR TRANSFERRING DATA TO               REDUNDANT MEMORY SUB-               SYSTEMS IN A STORAGE               CONTROLLER                  
 
         [0003]     U.S. patent application Ser. No. 10/946,341 claims the benefit of the following U.S. Provisional Applications, each of which is incorporated by reference in its entirety for all purposes:  
                                       Ser. No.               (Docket No.)   Filing Date   Title                   60/554052   Mar. 17, 2004   LIBERTY APPLICATION BLADE       (CHAP.0111)                  
 
     
    
     BACKGROUND OF THE INVENTION  
     Field Of The Invention  
       [0004]     The present invention relates in general to the field of fault-tolerant storage controllers, and particularly to failover of failed I/O ports thereof.  
         [0005]     Today&#39;s computer networks include vast amounts of storage, require high data throughput, and demand high data availability. Many networks support hundreds or even thousands of users connected to them. Many networks store extremely valuable data, such as bank account information, personal medical information, databases whose unavailability equates to huge sums of lost revenue due to inability to sell a product or provide a service, and scientific data gathered over large amounts of time and at great expense.  
         [0006]     A typical computer network includes one or more computers connected to one or more storage devices, such as disk drives or tape drives, by one or more storage controllers. One technique for providing higher data availability in computer networks is to include redundant components in the network. Providing redundant components means providing two or more of the component such that if one of the components fails, one of the other redundant components continues to perform the function of the failed component. In many cases, the failed component can be quickly replaced to restore the system to its original data availability level. For example, some network storage controllers include redundant hot-pluggable field replaceable units (FRUs), commonly referred to as blades. If one of the blades fails it may be replaced with a good blade while the system is still running to restore the storage controller to its original data availability level.  
         [0007]     Another technique employed in storage controllers is modularity. A modular storage controller comprises multiple modules or FRUs such that one or more of the modules may be replaced without replacing all the modules of the storage controller. An advantage of modularity may be increased performance in a cost effective manner. For example, the RIO RAID controller sold by Dot Hill Systems Corp. of Carlsbad, Calif., formerly Chaparral Network Storage, Inc., is a redundant modular storage controller.  
         [0008]      FIG. 1  illustrates a RIO RAID controller  100  in a common configuration. The RIO controller  100  includes a backplane  108  including four local buses  112 , denoted  112 A,  112 B,  112 C, and  112 D. In one version of the product, the local buses  112  are PCI-X buses. The RIO RAID controller  100  also includes four modules, or blades, which are hot-pluggable into the backplane  108 : two Data Manager (DM) blades  114 , denoted DM-A  114 A and DM-B  114 B, and two Data Gate (DG) blades  116 , denoted DG-A  116 A and DG-B  116 B. Each of the blades  114  and  116  is a field-replaceable unit (FRU). Each DG blade  116  includes two I/O controllers  126 , denoted  126 A and  126 B. Each I/O controller  126  includes two I/O ports  128 , such as FibreChannel (FC) ports, for connecting to host computers and disk drives. Each of the four I/O controllers  126  also has a local bus interface for interfacing with a different one of the local buses  112 . On one version of the RIO RAID controller  100 , the I/O controllers  126  are JNIC-1560 Milano dual channel FibreChannel to PCI-X controllers. Each DM blade  114  includes a CPU  124 , a memory  122 , and a memory controller/bridge circuit  118  for interfacing the CPU  124  and memory  122  with two of the local buses  112 . In the RIO RAID controller  100  of  FIG. 1 , DM-A  114 A is connected to local bus  112 A and  112 B, and DM-B  114 B is connected to local bus  112 C and  112 D. I/O controller  126 A of DG-A  116 A is connected to local bus  112 A, I/O controller  126 B of DG-A  116 A is connected to local bus  112 C, I/O controller  126 A of DG-B  116 B is connected to local bus  112 B, and I/O controller  126 B of DG-B  116 B is connected to local bus  112 D.  
         [0009]     The I/O controllers  126  function as target devices of the CPUs  124 . In particular, the I/O controllers  126 A of DG-A  116 A and DG-B  116 B are controlled by DM-A  114 A, and the I/O controllers  126 B of DG-A  116 A and DG-B  116 B are controlled by DM-B  114 B. Each of the I/O controllers  126  generates an interrupt request (IRQ)  134  that is routed through the backplane  108  to its respective controlling CPU  124 . The I/O controllers  126  receive I/O requests from the host computers on their respective I/O ports  128  and in response generate an interrupt request  134  to notify the CPU  124  of the I/O request. Additionally, each of the I/O controllers  126  may generate an interrupt request  134  to notify its respective CPU  124  that it has received a packet of data from a disk drive or transmitted a packet of data to a disk drive or host computer. The memory  122  caches data from the disk drives for more efficient provision to the host computers. The CPU  124  performs RAID functions, such as performing logical block translation, striping, mirroring, controlling parity generation, processing I/O requests, data caching, buffer management, and the like.  
         [0010]     An advantage of a modular approach such as that of the RIO RAID controller  100 , is that it provides an architecture for cost effective upgrades to the storage controller  300 . For example, in some versions of the RIO RAID controller products, the customer may incrementally add or delete DG blades  116  from the configuration based on connectivity and data availability requirements, such as based on the number of host computers and disk drives to be connected. Additionally, the architecture potentially provides the customer the ability to migrate in technology. For example, a subsequent DG blade could be provided that uses a different interface technology other than FibreChannel, such as SCSI, Infiniband, SATA, iSCSI, etc. Advantageously, the DM blades  114  would not have to be replaced (although a firmware upgrade of the DM blades  14  might be required) in order to enjoy the benefit of the migration in I/O interface technology. Also, the architecture facilitates higher density in 1 U high  19 ″ rack-mountable enclosures.  
         [0011]      FIG. 2  illustrates a scenario in which DM-A  114 A has failed. DM-B  114 B detects that DM-A  114 A has failed via loss of a heartbeat signal  134 A from DM-A  114 A. When DM-B  114 B detects that DM-A  114 A has failed, DM-B  114 B performs an active-active failover operation to take over processing I/O requests from the host computers previously serviced by DM-A  114 A. This is possible because in a typical configuration DM-B  114 B is able to communicate with all of the disk drives—including the disk drives comprising the logical units, or disk arrays—previously controlled by now failed DM-A  114 A and because in a typical configuration the host computers are capable of issuing requests to the RIO RAID controller  100  via an alternate path, namely through one of the I/O ports  128  connected to surviving DM-B  114 B, as discussed below.  
         [0012]     Unfortunately, as may be observed from  FIG. 2 , the I/O ports  128  previously owned by failed DM-A  114 A, namely the I/O ports  128  of the I/O controllers  126 A of each of DG-A  116 A and DG-B  116 B, are now inaccessible by DM-B  114 B since DM-B  114 B has no local bus  112  path to the I/O controllers  126 A. Consequently, the I/O ports  128  of the I/O controllers  126 A not connected to the surviving DM-B  114 B are unused, and are referred to as “orphaned” I/O ports.  
         [0013]     There are disadvantages of incurring orphaned I/O ports. In a typical configuration, prior to the failure, DM-A  114 A is responsible for servicing I/O requests from some of the host computers to transfer data with some of the disk drives, and DM-B  114 B is responsible for servicing I/O requests from the rest of the host computers to transfer data with the rest of the disk drives. In the worst case scenario, the host computers and/or disk drives previously serviced by DM-A  114 A are not also connected to the non-orphaned I/O ports  128  (I/O ports  128  of the I/O controllers  126 B connected to DM-B  114 B), or the host computers previously serviced by DM-A  114 A are not configured to use multi-pathing (discussed below), resulting in a loss of data availability.  
         [0014]     In the best case scenario, the host computers and disk drives previously serviced by DM-A  114 A are connected to the non-orphaned I/O ports  128 , thereby enabling DM-B  114 B to function in a redundant manner with DM-A  114 A to tolerate the failure of DM-A  114 A. In this scenario, in response to detecting the failure of DM-A  114 A, DM-B  14 B resets DM-A  114 A via a reset line  132 B, and services I/O requests from the host computers previously serviced by DM-A  114 A via the non-orphaned I/O ports  128 . DM-B  114 B may service I/O requests from the host computers previously serviced by DM-A  114 A by causing the non-orphaned I/O ports  128  to impersonate the orphaned I/O ports  128 . DM-B  114 B may cause the non-orphaned I/O ports  128  to impersonate the orphaned I/O ports  128  in two ways: DM-B  114 B may cause the non-orphaned I/O ports  128  to change their personality to the orphaned I/O ports&#39;  128  personality, or DM-B  114 B may cause the non-orphaned I/O ports  128  to add to their current personality the orphaned I/O ports&#39;  128  personality.  
         [0015]     Each of the I/O ports  128  has a unique ID for communicating with the host computers and disk drives, such as a unique world-wide name on a FibreChannel point-to-point link, arbitrated loop, or switched fabric network. The first impersonation technique—causing the non-orphaned I/O ports  128  to change their personality to the orphaned I/O ports  128  personality—operates as follows. When DM-B  114 B detects that DM-A  114 A has failed, DM-B  114 B reprograms one or more of the non-orphaned I/O ports  128  to communicate using the unique IDs previously used by the orphaned I/O ports. Consequently, the reprogrammed non-orphaned I/O ports  128  appear as the orphaned I/O ports, thereby continuing to provide data availability to the host computers and/or disk drives.  
         [0016]     The second impersonation technique—causing the non-orphaned I/O ports  128  to add to their current personality the orphaned I/O ports  128  personality—is referred to as “multi-ID” operation. When DM-B  114 B detects that DM-A  114 A has failed, DM-B  114 B reprograms the non-orphaned I/O ports  128  to communicate using not only their previous unique IDs, but also using the unique ID of the orphaned I/O ports. Consequently, the non-orphaned I/O ports  128  appear as the orphaned I/O ports, thereby continuing to provide data availability.  
         [0017]     However, there are problems associated with each of these techniques. First, neither of the techniques is transparent to the host computers. That is, each technique may require the host computers to have the capability to begin transmitting I/O requests along a different path to the non-orphaned I/O ports  128 , a technique referred to as “multi-pathing.” Furthermore, multi-ID operation is not supported in the FibreChannel point-to-point configuration, and for some users it is desirable to connect the host computers in a FibreChannel point-to-point configuration, rather than in an arbitrated loop or switched fabric configuration. Additionally, some FibreChannel switches do not support arbitrated loop mode, but only support point-to-point mode, with which multi-ID operation may not be used.  
         [0018]     A still further problem with orphaned I/O ports is that data throughput is lost even assuming the surviving DM blade  114  is able to failover via non-orphaned I/O ports  128 . During normal operation, the DM blades  114  and DG blades  116  operate in an active-active manner such that data may be transferred simultaneously between all the I/O ports  128  along all the local buses  112  and the memory  122 , resulting in very high data throughput. However, a reduction in throughput may be a consequence of some of the I/O ports  128  being orphaned.  
         [0019]     Therefore, what is needed is an apparatus and method for the surviving DM blade  114  to adopt the orphaned I/O ports  128 .  
       SUMMARY OF INVENTION  
       [0020]     The present invention provides an enhanced data gate blade that includes a bus bridge that enables a surviving data manager blade to adopt the orphaned I/O ports by enabling a local bus connection between the surviving data manager blade and the I/O controller having the orphaned I/O ports.  
         [0021]     In one aspect, the present invention provides a method for adopting an orphaned I/O port of a storage controller. The storage controller has first and second redundant field-replaceable units (FRU) for processing I/O requests and a third FRU having at least one I/O port for receiving the I/O requests from host computers coupled thereto. Initially the first FRU is configured to process the I/O requests received by the I/O port. The third FRU is initially configured to route to the first FRU interrupt requests generated by the I/O port in response to receiving the I/O requests. The method includes determining, by the second FRU, that the first FRU has failed and is no longer processing I/O requests received by the I/O port. The method also includes configuring the third FRU to route the interrupt requests from the I/O port to the second FRU rather than the first FRU in response to determining that the first FRU has failed.  
         [0022]     An advantage of the present invention is that it provides transparent failover to the host computers. Another advantage is that it eliminates the need to have the non-orphaned I/O ports impersonate the orphaned I/O ports, thereby eliminating the requirement for the host computers to have the capability to multi-path. In particular, the present invention eliminates the need to use multi-ID operation to perform failover to the surviving data manager blade. Another advantage is that there is potentially essentially no throughput loss once the orphaned I/O ports are adopted. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0023]      FIG. 1  is a related art block diagram of RIO RAID controller.  
         [0024]      FIG. 2  is a related art block diagram of RIO RAID controller with a failed data manager blade causing some of the data gate blade I/O ports to be orphaned.  
         [0025]      FIG. 3  is a block diagram of a storage controller with the ability to adopt orphaned I/O ports according to the present invention.  
         [0026]      FIG. 4  is a block diagram of the storage controller of  FIG. 3  illustrating the adoption of orphaned I/O ports according to the present invention.  
         [0027]      FIG. 5  is a block diagram illustrating the bus bridge of  FIG. 3  according to the present invention.  
         [0028]      FIG. 6  is a flowchart illustrating operation of the storage controller of  FIG. 3  to adopt orphaned I/O ports according to the present invention.  
         [0029]      FIG. 7  is a flowchart illustrating failback of the storage controller of  FIG. 3  according to the present invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0030]     Referring now to  FIG. 3 , a block diagram of a storage controller  300  with the ability to adopt orphaned I/O ports according to the present invention is shown. The storage controller  300  of  FIG. 3  is similar in some respects to the RIO RAID controller  100  of  FIG. 1  and like-numbered elements may be similar. However, the DG blades  116  of the storage controller  300  further include a bus bridge  312  on each data gate blade  116 . The bus bridge  312  is coupled between the I/O controllers  126  and the local buses  112 . Furthermore, the CPU  124  of each DM blade  114  is programmed to perform orphaned I/O port adoption as described below. Each DM blade  114  is capable of resetting each of the DG blades  116 . In one embodiment, each DM blade  114  has a dedicated line included in the backplane  108  to each of the DG blades  116  for resetting the respective DG blade  116 . The bus bridge  312  is described in detail presently with respect to  FIG. 5 .  
         [0031]     Referring now to  FIG. 5 , a block diagram illustrating the bus bridge  312  of  FIG. 3  according to the present invention is shown. The bus bridge  312  includes four local bus interfaces  502 . The first local bus interface  502 A is coupled to a local bus for coupling to one of the backplane  108  local buses  112  for coupling to DM-A  114 A. A second local bus interface  502 C is coupled to another local bus for coupling to another of the backplane  108  local buses  112  for coupling to DM-B  114 B. A third local bus interface  502 B is coupled to another local bus for coupling to I/O controller  126 A. A fourth local bus interface  502 D is coupled to another local bus for coupling to I/O controller  126 B. In one embodiment, the local buses comprise PCI-X buses. Other embodiments are contemplated in which the local buses  516  include, but are not limited to a PCI, CompactPCI, PCI-Express, PCI-X2, EISA, VESA, VME, RapidIO, AGP, ISA, 3GIO, HyperTransport, Futurebus, MultiBus, or any similar local bus capable of transferring data at a high rate.  
         [0032]     The bus bridge  312  also includes five bridge circuits  504 . A first bridge circuit  504 A bridges local bus interface  502 A and local bus interface  502 B, for enabling communication and data transfer between DM-A  114 A and I/O controller  126 A. A second bridge circuit  504 B bridges local bus interface  502 C and local bus interface  502 B, for enabling communication and data transfer between DM-B  114 B and I/O controller  126 A. A third bridge circuit  504 C bridges local bus interface  502 A and local bus interface  502 D, for enabling communication and data transfer between DM-A  114 A and I/O controller  126 B. A fourth bridge circuit  504 D bridges local bus interface  502 C and local bus interface  502 D, for enabling communication and data transfer between DM-B  114 B and I/O controller  126 B. A fifth bridge circuit  504 E bridges local bus interface  502 A and local bus interface  502 C, for enabling communication and data transfer between DM-A  114 A and DM-B  114 B. The bridge circuits  504  include local bus target and master circuits. The target circuits are configured to function as a target of local bus commands initiated by the respective local bus interfaces  502  and to cause the master circuits to regenerate the commands on the respective opposite local bus interface  502 . In one embodiment, the bridge circuits  504  also include FIFO memories for buffering data transfers between the respective local bus interfaces  502 .  
         [0033]     The bus bridge  312  also includes programmable interrupt request routing logic  508 . The interrupt request routing logic  508  receives the IRQ  134 A from I/O controller  126 A and the IRQ  134 B from I/O controller  126 B and selectively routes each of the IRQs  134  independently to either DM-A  114 A or DM-B  114 B as last programmed by the DM blades  114 .  
         [0034]     Referring now to  FIG. 4 , a block diagram illustrating the storage controller  300  of  FIG. 3  having a failed DM-A  114 A is shown. As illustrated with respect to  FIG. 2 , without the benefit of the present invention, the I/O ports  128  of I/O controller  126 B of each of the DG blades  116  would be orphaned I/O ports  128 , i.e., the surviving DM-B  114 B would not be able to access the I/O ports  128  of I/O controller  126 A of each of the DG blades  116 ; i.e., the I/O ports  128  of I/O controller  126 A of each of the DG blades  116  would be orphaned. However, advantageously, the bus bridge  312  of DG-A  116 A also couples backplane  108  local bus  112 C to I/O controller  126 A, as shown, thereby providing a control and data path for surviving DM-B  114 B to adopt the orphaned I/O ports  128  of DG-A  116 A; similarly, the bus bridge  312  of DG-B  116 B also couples backplane  108  local bus  112 D to I/O controller  126 A, as shown, thereby providing a control and data path for surviving DM-B  114 B to adopt the orphaned I/O ports  128  of DG-B  116 B. In one embodiment, each respective bus bridge  312  provides a constant path between each of the I/O controllers  126  and its respective local buses  112 . In another embodiment, the surviving DM blade  114  must program the bus bridge  312  to provide the path to the I/O controller  126  having the orphaned I/O ports  128 .  
         [0035]     In addition, the bus bridge  312  of DG-A  116 A re-routes the IRQ  134 A from I/O controller  126 A to the CPU  124  of DM-B  114 B, as shown, in response to being programmed by the CPU  124 ; similarly, the bus bridge  312  of DG-B  116 B re-routes the IRQ  134 A from I/O controller  126 A to the CPU  124  of DM-B  114 B, as shown, in response to being programmed by the CPU  124 , as described below with respect to  FIG. 6 . In one embodiment, the IRQ  134 A of I/O controller  126 A and the IRQ  134 B of I/O controller  126 B share an interrupt request input to CPU  124 . In another embodiment, the IRQ  134 A of I/O controller  126 A and the IRQ  134 B of I/O controller  126 B occupy unique interrupt request inputs to CPU  124 . In both embodiments, CPU  124  has the ability to individually clear the source of each of the IRQs  134 A and  134 B.  
         [0036]     Referring now to  FIG. 6 , a flowchart illustrating operation of the storage controller  300  of  FIG. 3  to adopt orphaned I/O ports  128  is shown. Flow begins at block  602 .  
         [0037]     At block  602 , during initialization time, each DM blade  114  CPU  124  performs several initialization steps. In one embodiment, an operating system executes on the CPU  124 , including a device driver controlling the I/O controllers  126 . In one embodiment, each CPU  124  has its own dedicated memory for storing program instructions, such as the operating system programs. First, the device driver executing on the CPU  124  registers an interrupt handler routine with the operating system to handle interrupt requests  134  from the I/O controllers  126  it owns, i.e., from the I/O controllers  126  for which it will initially service I/O requests. In the embodiment of  FIG. 3 , the CPU  124  of DM-A  114 A registers an interrupt handler to handle interrupts from the I/O controllers  126 A of DG-A  116 A and DG-B  116 B, and the CPU  124  of DM-B  114 B registers an interrupt handler to handle interrupts from the I/O controllers  126 B of DG-A  116 A and DG-B  116 B. In one embodiment, the device driver also allocates needed memory, such as for storing data structures. Additionally, the CPU  124  programs the bus bridges  312  to route the IRQs  134  from the I/O controllers  126  it owns to itself. Furthermore, the CPU  124  programs the I/O ports  128  it owns with a unique ID. In one embodiment, the unique ID comprises a unique world-wide name. Other embodiments are contemplated in which the unique ID comprises a MAC address or IP address. In one embodiment, each DM blade  114  has a single unique ID associated with it that is programmed into the I/O ports  128  owned by the DM blade  114 . In another embodiment, each DM blade  114  has multiple unique IDs associated with it that may be uniquely programmed into the various I/O ports  128  owned by the DM blade  114 . Finally, the CPU  124  provides its unique ID or unique IDs to the other DM blade  114 . In the case of multiple unique IDs, the CPU  124  also provides a mapping of which unique ID is programmed into which of the I/O ports  128  owned by the DM blade  114 . In one embodiment, each I/O controller  126  includes a sequencer that executes program instructions, and at initialization the CPU  124  also loads the program instructions into the I/O controller  126  for execution by the sequencer. Flow proceeds to block  604 .  
         [0038]     At block  604 , in one embodiment, the storage controller  300  receives input from a user to select an option whether to enable or disable orphaned I/O port adoption. Flow proceeds to block  606 .  
         [0039]     At block  606 , normal I/O operation begins. That is, the host computers issue I/O requests to the I/O ports  128 , which responsively generate IRQs  134  to their respective DM blades  114 . In one embodiment, the I/O controllers  126  transfer the I/O request to the memory  122  prior to generating the interrupt request  134  to the CPU  124 . In response to receiving the IRQ  134 , the DM blade  114  CPUs  124  process the I/O requests. For example, if the I/O request is a disk write request, the DM blade  114  receives the write data from the host computer into its memory  122  and subsequently programs the appropriate I/O port  128  to write the data from its memory  122  to one or more disk drives, which may be part of a redundant array of disks. If the I/O request is a disk read request, the DM blade  114  determines whether the requested data is cached in the memory  122 . If so, the DM blade  114  programs the appropriate I/O port  128  to write the data from its memory  122  to the host computer. Otherwise, the DM blade  114  reads the data from one or more disk drives into its memory  122  and subsequently writes the data from its memory  122  to the host computer. Flow proceeds to block  608 .  
         [0040]     At block  608 , DM-B  114 B detects the failure of DM-A  114 A, causing I/O ports  128  to be orphaned, namely the I/O ports  128  of I/O controllers  126 A of each of the DG blades  116 . In one embodiment, DM-B  114 B detects the failure of DM-A  114 A via a loss of heartbeat  134 A. Flow proceeds to block  612 .  
         [0041]     At block  612 , DM-B  114 B kills DM-A  114 A. That is, DM-B  114 B generates a reset  132 B to reset DM-A  114 A, and in particular to disable DM-A  114 A from communicating with the I/O controllers  126 A of each of the DG blades  116 . Flow proceeds to decision block  614 .  
         [0042]     At decision block  614 , the CPU  124  of DM-B  114 B determines whether at block  604  the user enabled orphaned I/O port adoption. If so, flow proceeds to block  616 ; otherwise, flow ends.  
         [0043]     At block  616 , DM-B  114 B resets the I/O controllers  126  having the orphaned I/O ports  128 , causing the orphaned I/O controllers  126  to de-assert their interrupt requests  134 , if they were asserted, and disabling the orphaned I/O ports  128  from receiving more I/O requests from the host computers. That is, the reset quiesces all I/O activity on the orphaned I/O ports  128 . In one embodiment, the DM blades  114  reset the orphaned I/O controllers  126 . Flow proceeds to block  618 .  
         [0044]     At block  618 , DM-B  114 B diagnoses the orphaned I/O ports  128  to verify that they are working properly. In one embodiment, DM-B  114 B will not adopt the orphaned I/O ports  128  unless the orphaned I/O ports  128  are functioning properly since a hardware problem with an orphaned I/O port  128  may have caused DM-A  114 A to fail. Advantageously, the present invention provides a means for the user to selectively disable or enable orphaned I/O port adoption, so that a more conservative user may avoid the risk of potentially adopting an orphaned I/O port that might also cause DM-B  114 B to fail, even though the orphaned I/O port  128  was diagnosed as functioning properly. Flow proceeds to block  622 .  
         [0045]     At block  622 , DM-B  114 B registers an interrupt handler with the operating system to handle interrupt requests  134  from the orphaned I/O ports  128 . Flow proceeds to block  624 .  
         [0046]     At block  624 , DM-B  114 B programs the bus bridge  312  to re-route interrupt requests  134  from the orphaned I/O controllers  126  to itself rather than to DM-A  114 A. In one embodiment, DM-B  114 B also programs the bus bridge  312  to make a path between itself and the orphaned I/O controllers  126 . Flow proceeds to block  626 .  
         [0047]     At block  626 , DM-B  114 B programs the orphaned I/O ports  128  with the unique IDs previously programmed into them by DM-A  114 A at block  602  and received from DM-A  114 A at block  602 . Flow proceeds to block  628 .  
         [0048]     At block  628 , DM-B  114 B issues a command to the orphaned I/O ports  128  to enable them to being receiving I/O requests again. Flow proceeds to block  632 .  
         [0049]     At block  632 , the adopted I/O ports  128 , i.e., the previously orphaned I/O ports  128 , begin receiving I/O requests from the host computers and in response generating IRQs  134  to DM-B  114 B. In response, DM-B  114 B processes the I/O requests. Flow ends at block  632 .  
         [0050]     In a typical configuration, the I/O ports  128  used to communicate with host computers are distinct from the I/O ports  128  used to communicate with the disk drives in order to prevent the host computers from directly communicating with the disk drives. In one embodiment, the orphaned I/O ports  128  adopted by the surviving DM-B  114 B include orphaned I/O ports  128  previously used by failed DM-A  114 A for transferring data with disk drives. An advantage of adopting the disk drive orphaned I/O ports  128  is that a substantial amount of the throughput may be maintained as when operating in normal active-active mode, i.e., prior to failure of DM-A  114 A.  
         [0051]     Referring now to  FIG. 7 , a flowchart illustrating failback of the storage controller  300  of  FIG. 3  according to the present invention is shown. Failback is the opposite of the failover described in  FIG. 6  and occurs when a DM blade  114  is put into operation, such as when the failed DM blade  114  (DM-A  114 A) is replaced with a new DM-A  114 A, and the surviving, or adopting, DM blade  114  (DM-B  114 B) returns the adopted I/O ports  128  back to the new DM blade  114 . Another scenario where a DM blade  114  is put into operation is by a user issuing a command to put an already physically installed DM blade  114  back into operation after having been taken out of operation. A portion of the failback operation is performed by the surviving DM blade  114 , and a portion is performed by the new DM blade  114 . Flow begins at block  702 .  
         [0052]     At block  702 , DM-B  114 B detects that the failed DM-A  114 A has been replaced with a new, properly functioning, DM-A  114 A. In one embodiment, each of the DM blades  114  receives signals from the backplane  108  indicating the presence/absence of a blade in each of the backplane  108  slots of the chassis enclosing the storage controller  300 , and DM-B  114 B detects that the failed DM-A  114 A has been replaced via the blade present/absent signals. Flow proceeds to block  704 .  
         [0053]     At block  704 , DM-B  114 B disables interrupts from the IRQs  134  of the adopted I/O ports  128 , i.e., from the I/O ports  128  adopted by DM-B  114 B according to  FIG. 6 . Flow proceeds to block  706 .  
         [0054]     At block  706 , DM-B  114 B ceases processing I/O requests associated with the adopted I/O ports  128 . That is, DM-B  114 B ceases to receive I/O requests from the adopted I/O ports  128 . Flow proceeds to block  708 .  
         [0055]     At block  708 , DM-B  114 B internally aborts all outstanding I/O requests previously received from the adopted I/O ports  128 . In one embodiment, the aborted I/O requests will be retried by the host computers and subsequently processed by the new DM-A  114 A. Flow proceeds to block  712 .  
         [0056]     At block  712 , the new DM-A  114 A resets the I/O ports  128  previously adopted by DM-B  114 B, which causes the previously adopted I/O ports  128  to de-assert their IRQs  134  and disables the previously adopted I/O ports  128  from receiving I/O requests from the host computers. Flow proceeds to block  714 .  
         [0057]     At block  714 , the new DM-A  114 A diagnoses the previously adopted I/O ports  128  to verify that the previously adopted I/O ports  128  are functioning properly. Flow proceeds to block  716 .  
         [0058]     At block  716 , the new DM-A  114 A registers an interrupt handler with its operating system to handle interrupt requests  134  from the previously adopted I/O ports  128 . Flow proceeds to block  718 .  
         [0059]     At block  718 , the new DM-A  114 A programs the bus bridges  312  to route the previously adopted I/O port  128  IRQs  134  to itself rather than to DM-B  114 B. Flow proceeds to block  722 .  
         [0060]     At block  722 , new DM-A  114 A program the previously adopted I/O ports  128  with the unique ID previously programmed into them by DM-B  114 B. Flow proceeds to block  724 .  
         [0061]     At block  724 , the new DM-A  114 A issues a command to the previously adopted I/O ports  128  to enable them to start servicing I/O requests again. Flow proceeds to block  726 .  
         [0062]     At block  726 , the previously adopted I/O ports, i.e., the I/O ports  128  that are now re-adopted by the new DM-A  114 A, begin receiving I/O requests from the hosts and generate interrupt requests  134  to the new DM-A  114 A. In response, the new DM-A  114 A processes the I/O requests, thereby accomplishing failback to the new DM-A  114 A. Flow ends at block  726 .  
         [0063]     Although the present invention and its objects, features, and advantages have been described in detail, other embodiments are encompassed by the invention. For example, although embodiments have been described in which the storage controller  300  includes two data gate blades  116 , the invention is not limited to such embodiments. Rather, the orphaned I/O port adoption described herein may be applied to configurations having one data gate blade  116 , or more than two data gate blades  116  for increased data availability and/or throughput. In addition, although adoption of orphaned I/O ports  128  has been described in a scenario in which DM-A  114 A has failed, the storage controller  300  is configured to perform a symmetric operation for adoption of orphaned I/O ports  128  in a scenario in which DM-B  114 B fails. Furthermore, although the local buses  112  have been described as PCI-X buses, the storage controller  300  may employ other local buses, including but not limited to a PCI, CompactPCI, PCI-Express, PCI-X2, EISA, VESA, VME, RapidIO, AGP, ISA, 3GIO, HyperTransport, Futurebus, MultiBus, or any similar local bus capable of transferring data at a high rate. Still further, although the storage controller  300  has been described as a RAID controller, the storage controller  300  may be any type of storage controller, including non-RAID controllers. Additionally, although the storage controller  300  has been described as controlling disk drives, the storage controller  300  may control other storage devices, such as tape drives, optical drives, and the like. Also, although embodiments have been described in which the I/O ports are FibreChannel I/O ports, the I/O ports may be any of various I/O port types, including but not limited to Ethernet, Infiniband, TCP/IP, Small Computer Systems Interface (SCSI), HIPPI, Token Ring, Arcnet, FDDI, LocalTalk, ESCON, FICON, ATM, Serial Attached SCSI (SAS), Serial Advanced Technology Attachment (SATA), iSCSI, and the like, and relevant combinations thereof. Furthermore, in one embodiment, each of the DG blades  116  also includes a FC port-bypass circuit (PBC) coupled to each I/O port  128  for coupling the I/O port  128  to an external connector for connecting to a FibreChannel link for connecting to the host computers and disk drives. In one embodiment, the PBCs may be hubbed together to create an FC arbitrated loop. In one embodiment, each of the DG blades  116  also includes a FC loop switch coupled to each of the I/O ports  128  and to the external connectors for connecting to the host computers and disk drives.  
         [0064]     Finally, those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for carrying out the same purposes of the present invention without departing from the spirit and scope of the invention as defined by the appended claims.