Patent Application
20080040564
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
Many of the functional units described in this specification have been labeled as modules in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Reference to a signal bearing medium may take any form capable of generating a signal, causing a signal to be generated, or causing execution of a program of machine-readable instructions on a digital processing apparatus. A signal bearing medium may be embodied by a transmission line, a compact disk, digital-video disk, a magnetic tape, a Bernoulli drive, a magnetic disk, punch card, flash memory, integrated circuits, or other digital processing apparatus memory device.
The schematic flow chart diagrams included are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Turning to
In various mass storage embodiments such as DEBs and their associated HDDs, the mass storage components can include the appropriate functionality to communicate over various device located layers such as an application layer, a transport layer, a link layer, and/or a physical layer, in accordance with various industry specifications. For example, DEBs 104 can provide the functionality to communicate via layers in accordance with a Serial-ATA industry standard interface specification, such as the Serial-ATA I interface specification (SATA) promulgated by the Serial ATA Working Group, the Serial ATA II interface specification promulgated by the Serial ATA II Work Group, or the SAS specification promulgated by the Serial Attached SCSI Working Group, or any progeny of these specifications. As illustrated, subsystem 100 includes a series of external cables 10 which are daisy-chained between each respective DEB 104 and RCB 106. Cables 108 are attached to various interface cards (controllers) which are mounted at the top and bottom of each DEB 104. In addition, cables 108 are connected to interface devices which link DEBs 104 with RCBs 106. Finally, light path (Identify) indicators 110 are seen integrated into each DEB 104.
Enclosure 102 can integrate up to four (4) DEBs 104 as previously described. From a Human Factors and Industrial Design perspective, it is desirable for the Identify indicators 110 of all the DEBs 104 to be synchronized. Subsystem 100 can initiate an Identify process using one of two entities, which results in non-synchronized Identify status indicators. First, the RCB 106 can issue an In-band Identify command to all the DEBs 104. Secondly, a Management Module (MM) can issue an Identify command to all related storage blades via an RS485 interface. It is desirable to synchronize the Identify indicators 110 across all integrated DEBs 104. Having synchronized indicators 110 becomes increasingly important in blade-type storage subsystems 100 where DEBs 104 are visually tightly coupled.
Synchronization of indicators 110 becomes increasingly important as multiple independent storage subsystems (SAS domain) come to coexist in a rack-mount setting within the same rack and even within the same chassis within the same rack. At the most granular level, each DEB 104 can be its own subsystem, in which case the indicators 110 would only blink in that specific DEB 104. As such, synchronization of indicators 110 becomes important to identify specific subsystems in a larger overall domain.
In a SAS/SATA storage subsystem 100 that implements light path, either of two methods can be employed to synchronize the light path Identify indicators 110 across the entire SAS domain. Each of these methods makes use of “primitives”. Primitives are dwords, units of data 32 bits long on a 32-bit x86 platform. The use of primitives, and the primitive format, is defined in section 7.2 of the SAS specification document “Working Draft Serial Attached SCSI-1.1 (SAS-1.1)”, revision 9e, 24 Jul. 2005 and published by T10, a technical subcommittee of the International Committee for Information Technology Standards (INCITS) which is incorporated herein by reference.
The first of the two synchronization methods involves a broadcast method utilized to synchronize the blinking of the Identify indicators 110 across the SAS/SATA domain network (e.g., multiple DEBs 104). The broadcast method must provide for low latency broadcast primitive commands such that all DEBs 104 receive the “Identify” command at approximately the same time. The second of the two methods involves utilizing a vendor-unique SAS Notify primitive which is defined to allow timely synchronization of light path indicators 110. An SAS switch sequences Notify primitives to each DEB 104 in the domain.
Turning to
Again, a first implementation to allow timely synchronization of light path Identify indicators 110 utilizes a broadcast primitive command. In general, broadcasts are used to notify all SAS ports in a domain of a particular event. For example, under the T10 SAS standard previously described, the Broadcast (Change) command is utilized to provide notification of a configuration change to all SAS ports in a domain. A new SAS Broadcast (Identify) primitive command can be defined which indicates to SAS target device(s) that the device(s) should turn on (statically or blinking) their LightPath Identify indicator 110. To invoke the light path Identify function, a SAS/SATA initiator (e.g., RCB 106, 107) broadcasts the Identify command to all attached downstream DEBs 104.
Even though the Identify command is broadcast, there may be a small time lag amongst all the resultant downstream primitive commands. To clarify, the first component in the path of the command is typically an SAS switch module 114, 115 which can implement a queuing scheme for all downstream command/data transmission, be it payload transmission or unique commands such as broadcast primitives. Each SAS expander module 116, 117 supports such a queue and allows intermix of data and commands. Even if an incoming command (e.g., Identify command from the initiator) is received, it may have to “wait in line” until other in-progress traffic is finished. This traffic intermix varies from SAS port to SAS port.
Even though an SAS switch module 114, 115 broadcasts an Identify command to multiple downstream targets, the commands may arrive at different times. To better synchronize a broadcast command, a high priority queue can be implemented in each SAS expander module 116, 117 such that specialized broadcast commands can be quickly transmitted once they are received. In general, broadcast commands are non-time critical. In the case of a light path implementation, there is some desire for all the indicators to blink in apparent unison. Consequently, it is important to implement a high-speed queue in the SAS switch module 114, 115. Such a high-speed queue would prioritize the Identify command ahead of lower priority commands. Alternatively, a synchronizing queue can be implemented which waits until all the ports are available and then issues the broadcast command.
Turning to
A second implementation to allow timely synchronization of light path Identify indicators 110 utilizes a notify primitive command. Several notify primitives are also defined in the SAS T10 specification previously described, including Notify (Enable Spinup), which specifies to an SAS target device that the device may temporarily consume additional power while transitioning into the active or idle power condition state. In general, notify primitives cannot be broadcast. A new, vendor-unique Notify (Identify) primitive can be defined specifically for invoking a light path function. Because notify primitives are not broadcast, once notify primitives are issued, they are not required to wait for queued-up traffic to quiesce.
A Notify frame can be inserted in the data stream as an “Align” character, consistent with SAS standards. To invoke the light path Identify function using a Notify (Identify) primitive command, a SAS/SATA initiator (again, e.g., RCB 106, 107) issues the vendor-unique Notify (Identify) command to its downstream SAS switch module 114, 115. The SAS switch module 114, 115 receives the command, and, being a central point in the SAS topology, invokes an algorithm which serially distributes the Identify command to all downstream target devices in a high-priority fashion.
Even though the Notify (Identify) function operates in a serial manner, the process happens sufficiently fast to effectuate a synchronized light path indication scheme. More recently, newly defined notify primities such as Notify (Early Power Off Warning) have emerged from the SAS T10 standards committee. The Early Power Off Warning (EPOW) primitive is coupled with the power supply system and is unrelated to any light path functions.
Turning to
Utilizing either an implementation of a broadcast primitive or notify primitive command, synchronization of light path Identify indicators 110 can be seen using existing infrastructure (hardware and software) in a cost-effective and efficient manner.
While one or more embodiments of the present invention have been illustrated in detail, the skilled artisan will appreciate that modifications and adaptations to those embodiments may be made without departing from the scope of the present invention as set forth in the following claims.
