Bridge permitting access by multiple hosts to a single ported storage drive

A bridge comprises an interface to a plurality of hosts, an interface to a single-ported storage drive and arbitration logic. The arbitration logic controls and permits concurrent access by the hosts to the single-ported storage drive so that the bridge need not store read or write data being received from or provided to the storage drive.

BACKGROUND

Some types of storage drives are single-ported meaning that only one host at a time can access the drive. When one host has completed its read or write transaction with the drive, another host may then be granted access to the drive. A serial AT attachment (SATA) drive is an example of such a drive. While generally adequate for certain applications, a single-ported drive, as noted above, cannot be accessed by more than one host at a time, thereby providing a performance bottleneck in systems containing multiple hosts.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, computer companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ” Also, the term “couple” or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections. The term “system” refers broadly to a collection of two or more components and may be used to refer to an overall system (e.g., a computer system or a network of computers) as well as a subsystem provided as part of a larger system (e.g., a subsystem within an individual computer).

DETAILED DESCRIPTION

FIG. 1shows an embodiment of a system10comprising a plurality of hosts12and14, an expander16, and a storage device18. The hosts12,14(also designated herein as host A and host B), access the storage drive18through the expander16. Each host12,14may comprise a separate computer (e.g., a server), or a separate host bus adapter within a computer. A host bus adapter functions to couple a host to one or more expanders and/or one or more storage devices. For example, the hosts12,14may comprise two host bus adapter cards installed in a computer. In other embodiments, the hosts12,14may comprise separate host bus adapters resident within a single computer. The term “host” broadly refers to any hardware or software entity that can read data from and/or write data to the storage drive18independent of another host.

The storage drive18comprises any suitable type of non-volatile storage medium such as a hard disk drive, compact disc read only memory (CD ROM) drive, tape drive, etc. In some embodiments, the storage drive18comprises a single storage device, but in other embodiments, the storage drive comprises multiple storage devices. For purposes of this disclosure, the term “storage drive” includes one or more storage devices.

The storage drive18comprises a single-ported drive meaning that only one host at a time can access the drive. The single-ported nature of the storage drive18is denoted by the single arrow19coupling the expander16and storage drive18. In at least some embodiments, the storage drive18comprises a SATA drive. A SATA drive cannot determine the identity of a host that issues read or write transactions to the drive. So as not to confuse a SATA drive, only one host at a time typically can access the drive. In such systems, each host typically is granted exclusive access (sometimes referred to as an “affiliation”) to the storage drive. A host must release its affiliation before another host can access the storage drive. The drive18includes a task file register (TFR)30that a host can write with commands such as read commands, write commands, etc. Each of the hosts12and14includes a shadow copy of the drive's TFR as TFRs13and15which are synchronized to the drive's TFR30. Each host reads its own shadow TFR when determining when to communicate to the drive. In accordance with embodiments of the invention, the expander16includes a second set of shadow TFRs24and26. Each shadow TFR24,26is generally synchronized to a corresponding hosts TFR13,15. In at least one embodiment, the bridge22within the expander16includes storage for the TFRs24,26. The use of the TFRs24,26to coordinate communications between multiple hosts12,14and a single-ported drive will be explained in further detail below.

In accordance with conventional SATA rules (in systems that do not contain a bridge22as described herein), a drive sends updates of its TFR to a host by way of a “Device-to-Host Register FIS” (a FIS is a frame instruction structure and is discussed below), and the host sends updates of its TFR to the drive with a Host-to-Device Register FIS. To avoid race conditions, the devices (host or drive) that transmit TFR updates coordinate amongst themselves who “owns” the TFR at any time. For example, when communications between the host and drive are idle, the host “owns” the TFR. When the host sends a command to the drive, the host sends the Host-to-Device Register FIS which contains both the command details and changes a bit (e.g., a BSY bit) so that the drive now owns the TFR. The drive is now entitled to send a Register FIS when appropriate.

In accordance with embodiments of the invention, the bridge22is coupled between the drive18and host12,14. To the drive18, the bridge22functions as a host in terms of TFR coordination. Similarly, to the host, the bridge22functions as a drive18. When the host12,14sends a Register FIS to the drive18to update the TFR30in the drive, the bridge22receives the FIS and eventually forwards it to the drive18. When the drive18sends a Register FIS to the host to update the TFR13,15in the host, the bridge22receives the FIS and eventually forwards it to the host.

The embodiments of the present invention comprise logic that permits multiple hosts to access a single-ported drive18concurrently meaning that each such host may be granted exclusive access at the same time. The logic noted above coordinates access to the single-ported drive storage on behalf of multiple hosts in such a way that permits each of the multiple hosts to have an affiliation at the same time. As a result of the logic disclosed herein, the drive responds to concurrent access requests from multiple hosts without having to coordinate and ensure that responses are provided back to the correct host; the logic disclosed below takes care of that coordination.

Referring toFIG. 1, the expander16comprises a cross-bar switch20and a bridge22. The expander16may be packaged in a common housing with the storage18or in a separate housing from the storage drive. The expander16functions to permit two or more hosts to access the single-ported storage drive18. The cross-bar switch20enables one or the other host12,14to have access through the expander's bridge22to the host. The bridge22coordinates access to the single-ported storage drive18as explained below. In accordance with at least one embodiment of the invention, the hosts12,14and drive18communicate with each other passing frame information structures (FISes) back and forth. A FIS, also referred to as a “frame,” comprises various information that identifies the nature of the message (e.g., a DMA read, a DMA write, a data frame, etc.). FISes in accordance with the SATA specification may be used in the embodiments below.

FIG. 2illustrates the bridge22in accordance with an embodiment of the invention. As shown, bridge22comprises a Serial Attached Small Computer System Interface (SAS) link (SL) layer control31, a pair of FIS controls32,33, a pair of FIS buffers34,35, and an incoming task file arbiter control36. The bridge22also comprises multiplexers37and41, a drive FIS buffer control38, a drive FIS buffer39, and a drive FIS set aside buffer40. Frames are received from either of the hosts through the cross-bar switch20, over line29and are stored in a FIS buffer34,35associated with that host. The bridge22depicted inFIG. 2supports two hosts concurrently communicating with a drive, and thus the bridge includes two FIS buffers34,35which include the TFRs24and26discussed above. If it is desired to concurrently support more than two hosts, more than two FIS buffers could be provided.

After a frame is stored in a buffer34,35, the frame will be forwarded on to the drive18through the multiplexer37. The multiplexer37permits one frame at a time to be forwarded on to the drive in a controlled manner, as controlled by the incoming task file arbiter control36. The FIS buffer controls32and33contain information about the state of each host. That information will be used by the incoming task file arbiter control36as explained below to enable the bridge22to coordinate the concurrent communication to the single-ported drive on behalf of multiple hosts.

In response to a frame (FIS) provided to the drive18by a specific host, the drive eventually will provide back a status or other type of frame. The response frame should thus be provided to the corresponding host. At least some frames that are received by the bridge from the storage drive18to be provided to the corresponding host are stored in the drive FIS buffer39and from the buffer39over line41to the multiplexer41for transmission through the cross-bar switch20to the relevant host. Other frames are not stored in drive FIS buffer39and, instead, are provided directly to the multiplexer41over line43as shown. Still other frames are first stored in the drive FIS buffer39and then stored in the drive FIS set aside buffer40before being provided over line45to the multiplexer41. Drive FIS buffer control38comprises arbitration logic that determines when such response frames should be provided to the host and to which specific host to send such frames. The drive FIS buffer control38asserts a control signal42to the multiplexer41to have the desired frame, either from the drive directly, the drive FIS buffer39, or the drive FIS set aside buffer40, provided through the multiplexer41to the host.

The bridge22thus comprises buffers34and35that temporarily store frames from corresponding hosts so that the bridge can coordinate the transfer of such frames to the drive. The bridge also comprises arbitration logic comprising, for example, the incoming task file arbiter control36which reads status information from FIS buffer controls32and33to determine which host's frames can be forwarded on to the drive18. As for responsive communications (i.e., drive to host), the bridge22also comprises temporary buffers39,40that enable the bridge to temporarily store frames from the drive that are destined for a host. The temporary buffers allow the bridge to inspect the FIS header and determine the host to which it is to send the FIS. Arbitration logic, such as the drive FIS buffer control38, coordinates the transfer of responsive frames from the drive back to the corresponding host. Moreover, the bridge22comprises buffers and arbitration logic that enable the bridge to coordinate concurrent communications between multiple hosts and a single-ported drive18such that the drive need not be aware that it is communicating with multiple hosts concurrently. The arbitration logic is embued with, or otherwise makes arbitration decisions in accordance with, the logic illustrated in Table I discussed below. The buffers and logic also permit the multiple hosts to communicate in an efficient manner with a single drive18.

In accordance with an embodiment of the invention, the bridge22coordinates or controls the access by a host12,14to the bridge in such as way that the bridge need not store data being written to or read from the drive. Accordingly, the bridge22need not have storage capacity for such data. In such embodiments, for example, the FIS buffers34,35are used to store the FIS information, but not the data payloads being provided to the drive18. The bridge22operates in a manner that avoids the necessity of having sufficient memory for data payloads by controlling the hand-shaking that occurs between host and expander and between expander and drive to preclude the data from passing between drive and host until the arbitration logic determines that data frame can be passed through the bridge given communications that may be on-going between the drive and another host. In other embodiments, the expander16(e.g., the bridge22) does include sufficient memory for buffering data payloads in route between host12,14and drive18.

In the embodiment ofFIG. 1, the bridge22is implemented as part of the expander16.FIG. 3shows an alternative embodiment in which the bridge22is implemented separately from the expander16.

Table I below illustrates the behavior of the bridge22when a command is received from a host. The behavior of the bridge is based on the status information contained in the TFRs24and26associated with the hosts. Table I illustrates the reaction of the bridge upon receipt of a command from host A in various situations. The same or similar logic would apply as well to the bridge22upon receipt of a command from host B in such situations.

Table I below refers to “queued” and “non-queued” commands that can be provided by a host12,14to the drive18. A queued command is a command that a host can have stored in a buffer (e.g., FIS buffer34,35) with other queued commands for subsequent retrieval and execution by the drive18. A non-queued command is a command that is not permitted to be buffered with other commands and is provided directly the drive18. Non-queued commands are executed by the drive, one at time, meaning that the drive executes a first non-queued command provided to it by the host, executes a second non-queued commands provided to by the host after completion of the first non-queued command, and so on. Examples of queued commands include READ FPDMA EXT and WRITE FPDMA EXT as provided in the SAS specification. Example of non-queued commands include IDENTIFY DEVICE and READ LOG EXT as in the SAS specification.

TABLE IBridge BehaviorConditionHost ATask fileTask filecommandA statusB statusreceivedBehaviorEmptyEmptyNon-queuedSend command to the drivecommand XEmptyEmptyQueuedSend command to the drivecommand XEmptyRunningnon-queuedWait for task file B'snon-queuedcommand Xcommand to finish, then sendcommandcommand X to the driveEmptyRunningqueuedWait for task file B'snon-queuedcommand Xcommand to finish, then sendcommandcommand X to the driveEmptyRunningnon-queuedWait for task file B's queuedqueuedcommand Xcommand to finish, then sendcommandcommand X to the drive. Ifany of B's commands fail,wait for B to clear the errorand abort all the tasks.EmptyRunningqueuedSend command X to the drivequeuedcommand XcommandRunningEmptynon-queuedHost A expects all of itsqueuedcommand Xcommand to be aborted.commandSend command X to the driveand let host A respond on itsown to errorRunningRunningnon-queuedHost A expects all of itsqueuedqueuedcommand Xcommand to be aborted.commandcommand(s)Host B does not expectcommand(s) to abort. Let allof B's commands completebut refuse to send newcommands from B. When Bis finished, send commandX to the drive.

As can be seen from Table I above, if queued commands from host B are running to the storage drive18and host A attempts to perform its own queued command to the drive, the bridge18sends host A's queued command to the drive without requiring host B's FIS buffer35to empty of its queued commands. That is, the bridge22can send interleaved queued commands to the drive18from both hosts concurrently—a queued command stream from the bridge to the drive that comprises queued commands from multiple hosts. Although the drive is unable to distinguish one drive from another, the bridge keeps track of the source of each command so that it can provide return frames from the drive to the appropriate host. Referring again to Table I, if the bridge22receives a non-queued or queued command from host A while running non-queued commands from host B or receives a non-queued command from host A while running a queued command from host B, the bridge's arbitration logic causes the bridge to wait for host B's command(s) to finish before sending host A's commands to the drive. The bridge22causes any non-queued command from host A to wait by the bridge not completing an interaction with host A in which host A is attempting to provide the non-queued command. For example, host A may assert a signal indicating that it has a command to send to the drive and the bridge waits before responding with an acknowledgement to permit the command to be provided to the bridge.

FIG. 4illustrates a method200by which the storage drive18sends status information back to the initiating host (host A or host B in the example ofFIG. 1) following receipt by the drive of a frame from the host. The drive18, as noted above, comprises a single-ported drive in that the drive does not distinguish between multiple hosts. The bridge22, however, comprises logic that permits multiple hosts to access the single-ported storage drive.

Reference should be made to method200ofFIG. 4as well as to the bridge embodimentFIG. 2. Method200comprises actions202-226. Action202comprises the drive18signaling the bridge that the drive has a frame to send to the initiating host. The frame may contain status information for the initiating host based on a previous command sent to the drive18by the host. Action202may be performed by the drive asserting a signal such as an XRDY signal of the SATA specification, or equivalent signal of other specifications. The XRDY signal is a ready signal that indicates that the drive has a transaction to transmit. The references below to specific signal names are in accordance with the SATA specification, but these signals are merely exemplary of various embodiments. Other embodiments may include other signal names and logic implemented in accordance with specifications other than SATA. At204, the bridge22replies that the bridge is ready to receive the frame from the drive18. This action may be performed by the bridge asserting an RRDY signal. At206, the drive18begins to send the frame to the bridge and, at208, the bridge receives the frame and stores the frame in the appropriate FIS buffer. Once the bridge22has successfully received the frame, which may include checking for errors using cyclic redundancy check bits (CRC) in the communication of the frame to the bridge, the bridge signals the drive18(action210) that the frame has been successfully received by the bridge.

Once the frame has been received by the bridge22and stored in the FIS buffer, the bridge then forwards the frame on to the appropriate host, that is, the host that sent the command frame that prompted the drive to send back the frame. At212, arbitration logic, which at least in part comprises the STP SL layer control, arbitrates internally to decide when to forward the frame and to which host to forward the frame to. Once this arbitration is performed, the bridge22requests a connection to the appropriate host (action214). The host, at216, accepts the connection. The bridge then signals (action218) the host that the bridge has a frame (i.e., the frame received from the drive18) to send to the host. This action can be performed by the bridge asserting an XRDY signal to the host. The host replies at220(e.g., by asserting an RRDY signal) that the host is ready to receive the frame. The bridge then sends the frame to the host (222), the host receives the frame (224), and the host signals the bridge that the frame was received successfully received by the host (226).

FIG. 5illustrates a method300by which the host sends a frame to a drive. Method300comprises actions302-326as shown. At302, the host that has a frame to send, requests a connection by, for example, sending an OPEN address frame. The bridge22receives the connection request at304. At306, the host signals the bridge22(e.g., by asserting an XRDY signal) that the host has a frame to send. The bridge replies at308that the bridge is ready to receive the frame (e.g., by asserting an RRDY signal). At310, the host sends the frame to the bridge, which the bridge receives and stores (action312) in an appropriate FIS buffer. At314, the bridge signals the host that the bridge successfully received the frame.

The bridge22then begins the process of forwarding the frame received from the host on to the storage drive18. At316, the bridge22arbitrates to determine when to forward the frame on to the drive. This action may be performed by the incoming task file/arbiter control (FIG. 2) in accordance with the limitations, for example of Table I above. Once the bridge's logic has determined that it is appropriate to send the frame from the FIS buffer to the storage drive18, the bridge signals (action318) the drive that the bridge has a frame to send the drive. This action can be performed by the bridge asserting an XRDY signal. The drive replies at320(e.g., by asserting an RRDY signal) that the drive is ready is ready to receive the frame. Actions322-326comprise the bridge sending the frame to the drive, the drive receiving the frame, and the drive then signaling the bridge of successful receipt of the frame (e.g., by asserting an RRDY signal).

In some embodiments, host A may desire to provide a non-queued command to the drive while host B is running a series of queued commands. As shown in Table I above, such a scenario will cause the bridge22to force host B's FIS buffer to provide all of its queued commands to the drive18for execution before permitting host A's non-queued command to be provided to the drive. The incoming task file arbiter control36effectuates this response and controls the multiplexer37so as to provide the appropriate commands from the appropriate buffers34and35.