Network addressable storage controller with storage drive profile comparison

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This utility patent application is a Continuation-In-Part of U.S. patent application Ser. No. 14/266,603 filed on Apr. 30, 2014, issued as U.S. Pat. No. 8,935,567 on Jan. 13, 2015, entitled “NETWORK ADDRESSABLE STORAGE CONTROLLER WITH STORAGE DRIVE PROFILE COMPARISON,” the benefit of which is claimed under 35 U.S.C. §120, and which is further incorporated by reference in its entirety.

TECHNICAL FIELD

0002The present invention relates generally to storage drive controllers, but more particularly, but not exclusively, to a network-addressable-storage-drive controller that together with a non-specific storage drive physically fits into a driver carrier that is employed with a typical multi-storage-drive chassis.

BACKGROUND

0003The use of distributed storage systems has grown in abundance over the past few years. These systems often use a chassis that house multiple storage drives, where data can be distributed across the various storage drives. Typically, a single built-in chassis computer or stand-alone computer or is used as an interface between the chassis (and accordingly each storage drive) and other network computers. This master computer generally coordinates read and write operations, and sometimes data recovery operations. However, if this master computer fails, then access to the storage drives may be drastically reduced, slowed, or even blocked to all of the drives of the chassis. Thus, it is with respect to these considerations and others that the invention has been made.

BRIEF DESCRIPTION OF THE DRAWINGS

0004Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified.

0005For a better understanding of the present invention, reference will be made to the following Detailed Description, which is to be read in association with the accompanying drawings, wherein:

0006<figref idref="DRAWINGS">FIG. 1</figref> is a system diagram of an environment in which embodiments of the invention may be implemented;

0007<figref idref="DRAWINGS">FIG. 2</figref> shows an embodiment of a network computer that may be included in a system such as that shown in <figref idref="DRAWINGS">FIG. 1</figref>;

0008<figref idref="DRAWINGS">FIG. 3A-3B</figref> show embodiments of a controller that may be including in a system such as that shown in <figref idref="DRAWINGS">FIG. 1</figref>;

0009<figref idref="DRAWINGS">FIG. 3C</figref> shows an embodiment of a radio adapter;

0010<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate top perspective views of a storage drive and a controller in accordance with embodiments described herein;

0011<figref idref="DRAWINGS">FIGS. 4C and 4D</figref> illustrate side perspective views of a storage drive and a controller in accordance with embodiments described herein;

0012<figref idref="DRAWINGS">FIG. 4E</figref> illustrates a back perspective view of a storage drive and a controller in accordance with embodiments described herein;

0013<figref idref="DRAWINGS">FIG. 4F</figref> illustrates a top perspective view of a controller in accordance with embodiments described herein;

0014<figref idref="DRAWINGS">FIG. 4G</figref> shows a top perspective of a wireless controller;

0015<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> illustrate top perspective views of a storage-drive carrier, a storage drive, and a controller in accordance with embodiments described herein;

0016<figref idref="DRAWINGS">FIG. 6A</figref> illustrates an exploded perspective view of a multi-storage-drive chassis, a storage-drive carrier, a storage drive, and a controller in accordance with embodiments described herein;

0017<figref idref="DRAWINGS">FIG. 6B</figref> shows an exploded perspective view of a multi-storage-drive chassis, a storage-drive carrier, a storage drive, a radio adapter, a waveguide, and a wireless controller in accordance with embodiments described herein;

0018<figref idref="DRAWINGS">FIG. 7</figref> illustrates an embodiment of a use case example of a controller circuit board with first and second connectors in accordance with embodiments described herein;

0019<figref idref="DRAWINGS">FIG. 8</figref> illustrates an embodiment of a use case example of a system diagram of a controller in accordance with embodiments described herein;

0020<figref idref="DRAWINGS">FIG. 9</figref> illustrates an embodiment of a use case example diagram illustrating utilization of differential signal pairs in accordance with embodiments described herein;

0021<figref idref="DRAWINGS">FIG. 10</figref> illustrates a logical flow diagram generally showing an embodiment of a process for powering up a plurality of storage drives in accordance with embodiments described herein;

0022<figref idref="DRAWINGS">FIG. 11</figref> illustrates a logical flow diagram generally showing an embodiment of a process for managing a storage drive in accordance with embodiments described herein; and

0023<figref idref="DRAWINGS">FIG. 12</figref> illustrates a logical flow diagram generally showing an embodiment of a process for monitoring a storage drive in accordance with embodiments described herein.

DETAILED DESCRIPTION

0024Various embodiments are described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific embodiments by which the invention may be practiced. The embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the embodiments to those skilled in the art. Among other things, the various embodiments may be methods, systems, media, or devices. Accordingly, the various embodiments may be entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. The following detailed description should, therefore, not be limiting.

0025Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The term “herein” refers to the specification, claims, and drawings associated with the current application. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. Furthermore, the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment, although it may. Thus, as described below, various embodiments of the invention may be readily combined, without departing from the scope or spirit of the invention.

0026In addition, as used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.”

0027As used herein, the term “multi-storage-drive chassis” refers to a storage architecture that includes a chassis, backplane, and various other circuitry (e.g., power supply, a centralized chassis controller, or the like) for enabling use of a plurality of storage drives. In some embodiments, a multi-storage-drive chassis may be in a non-RAID (non-Redundant Array of Independent Disks) architecture, such as, for example, a JBOD (or “just a bunch of disks”) architecture. However, embodiments are not so limited, and in other embodiments, the multi-storage-drive chassis may be in a RAID architecture.

0028In various embodiments, the backplane of the chassis may include a plurality of connectors that are electrically coupled to the backplane. Some aspects of the connectivity may be in parallel; power for instance. Other connector connectivity can be star connected high speed serial. These connectors may be referred to as backplane connectors. In some embodiments, each backplane connector may be referred to as a storage-drive slot (or disk slot). The backplane connectors may enable a plurality of storage drives to electrically couple with the backplane. In at least one embodiment, the plurality of storage drives may receive power through the backplane connectors. In some embodiments, the backplane connectors may be SAS (Serial Attached SCSI (Small Computer System Interface)) connectors, SATA (Serial Advanced Technology Attachment) connectors, SCSI connectors, or other types of connectors that are compatible with a storage-drive connector, or controller, as described herein.

0029In various embodiments, the chassis may support storage-drive-access protocols. Often these protocols are dependent on the type of backplane connectors and/or the type of storage drive connector. For example, if the backplane connector is a SAS connector, then the chassis may be operative to support SAS protocols for accessing storage-drive data.

0030In at least one of various embodiments, the backplane may be modified such that at least a portion of the backplane connectors (i.e., storage-drive slots) can interface with an Ethernet switch fabric. In various embodiments, the chassis may include one or more Ethernet switches. These Ethernet switches may be integrated circuits with a plurality of ports that function by forwarding frames (or packets) between several ports. Each individual port may be serially connected to corresponding storage-drive slots (e.g., correspondingly coupled to the backplane connectors). In various embodiments, the Ethernet switch fabric in conjunction with the backplane connectors can support Ethernet protocols that can be provided over a SAS connector (or other backplane connector that can couple to a storage drive (or controller)). In some embodiments, the Ethernet switch fabric may include an Ethernet port/interface for enabling communication between the chassis (e.g., each controller) and at least one network and/or network device that is remote to the chassis. However, embodiments are not so limited; and in some other embodiments, the chassis may be modified to include a component that can detect differences between storage-drive-access protocols and Ethernet protocols. In some other embodiments, a traditional backplane may not be utilized, but rather the switch fabric may include connectors for coupling with storage drives, where these connectors include an Ethernet interface.

0031In various embodiments, multi-storage-drive chassis may utilize storage-drive carriers or trays to enable easy insertion and removal of the storage drives to and from the chassis. The storage-drive carriers can provide easy and consistent alignment of a storage-drive's output connector and a backplane input connector.

0032Also, in various embodiments, instead of wired connectors electronically coupled to a backplane, the multi-storage-drive chassis may use wireless communication to connect a plurality of storage drives to an external network. The wireless multi-storage-drive chassis embodiments may include one or more waveguides to facilitate secure and effective wireless communication with the storage drives. The one or more waveguides may be located in the chassis so that they extend from one, some, or all of the shelves of storage drives in the chassis. In various embodiments, one or more channels in the waveguides are provided. Each channel may be formed in a waveguide having a shape that facilitates the communication of wireless signals along its length, such as a substantially circular, oval, rectangular, square, triangular, or the like shape.

0033In various embodiments, antennas corresponding to one or more radio adapters and one or more antennas corresponding to one or more wireless controllers for the storage drives are able to wirelessly receive and transmit wireless communication signals with each other within the waveguide. The one or more radio adapters are also configured to facilitate communication between one, some or all of the wireless controllers and at least one network and/or network device that is remote to the chassis.

0034In various embodiments of the wireless multi-storage-drive chassis, multiple radio adapters may be located in one or more waveguides to at least facilitate system redundancy and flexible bandwidth allocation when wirelessly communicating with one or more wireless controllers. For example, in various exemplary embodiments, two or more radio adapters may be arranged in one waveguide to provide redundant wireless communication with each wireless controller in the multi-storage-drive chassis. Also, in other exemplary embodiments, multiple radio adapters may be separately located in different waveguides to provide greater wireless communication flexibility and increased communication bandwidth with different portions of the plurality of wireless storage drive controllers in the wireless multi-storage-drive chassis. For example, in various embodiments, one portion of a plurality of wave guides may be arranged to enable wireless communication between one portion of a plurality of wireless controllers. And another different portion of the plurality of wave guides may be arranged to enable wireless communication between another different portion of the plurality of radio adapters and another different portion of the plurality of wireless controllers located in the wireless multi-storage-drive chassis. Also, in various embodiments, the one or more radio adapters may be located along the length of each waveguide and/or at one or both ends of each waveguide.

0035Additionally, in various embodiments, one or more termination plates for wireless signals within a wave guide may be arranged at one or both ends of a waveguide to prevent reflections and standing waves of wireless communication signals within the waveguide. Also, the interior surface of one or more channels in a waveguide may be irregular to support MIMO spatial multiplexing operation based on multipath inducing geometry within the waveguide's channel. For example, the waveguide's interior surface may include symmetrical and/or non-symmetrical ridges, angles, shapes, folds, or protuberances that are placed at symmetrical and/or non-symmetrical locations along the interior surface of the waveguide's channel.

0036Additionally, in various embodiments, the wireless multi-storage-drive chassis is not limited for use with waveguides to provide wireless communication. Instead, the chassis may be provided without waveguides and employ one or more radio adapters that can wirelessly communicate with one or more wireless controllers separate from a waveguide. Further, in various embodiments, the chassis may be provided with waveguides for a portion of storage drives having wireless controllers, and wired connections for other storage drives having controllers with a second connector.

0037In various embodiments, the types of wireless communication protocols employed by the radio adapters and the wireless controllers may be a standard protocol or one of its variants, for example, WiFi (IEEE 802.11), Bluetooth (IEEE 802.15.1, WiMax (IEEE 802.16), WiMax MIMO, WiMax MISO, ZigBee (IEEE 802.15.4), MiWi (IEEE 802.15.4), or the like. The wireless communication signals may also be communicated with a modified standard wireless protocol, and/or a proprietary wireless protocol.

0038As used herein, the term “radio adapter” refers to an electronic component, device, computer, and the like, that is located in a wireless multi-storage-drive chassis and provides wireless communication with one or more wireless storage drive controllers. Also, in various embodiments, the radio adapter enables communication between the chassis' storage devices (i.e., each wireless controller) and at least one network and/or network device that is remote to the chassis. Also, in various embodiments, the communication with the at least one network and/or remote network device may be based on Ethernet, or the like. Additionally, in various embodiments, the radio adapter may employ a fiber optic connection, or some other high bandwidth connection, to communicate with the at least one network and/or remote network device, or the like.

0039In various embodiments, the radio adapter may include one or more antennas that enable communication with one or more wireless controllers and/or one or more radio adapters that are at least located in the wireless multi-storage-drive chassis. In various embodiments, the radio adapter may be configured to wirelessly communicate through a channel in a waveguide with one or more wireless controllers and/or one or more other radio adapters. In various embodiments, the radio adapter may include one or more antennas for enabling wireless communication with one or more wireless controllers and/or one or more other radio adapters that communicate outside of a waveguide.

0040As used herein, the term “storage drive” refers to a device for storing data. The various embodiments described herein can utilize most typical, non-specific, or general storage drive on the market (i.e., the storage drive itself does not need to include or be modified to include any circuitry, components, or the like to perform the various embodiments). Storage drives may include hard disk drives (HDD), solid state drives (SSD), optical drives, or the like.

0041In various embodiments, storage drives may include a housing that has two ends, a top, a bottom, and two sides. In various embodiments, a back end of the storage-drive housing may include a storage-drive connector. In at least one of various embodiments, the back end of the housing may include peripheral edges (e.g., the perimeter edges of the back end of the storage-drive housing).

0042Storage drives can come in many different form factors, such as, for example, 3.5 inch, 2.5 inch, 1.8 inch, 5.25 inch, 8 inch, or the like. It should be understood that the actual dimensions of the storage drive (including the housing and/or storage-drive connector) may be different that the form factor nomenclature based on industry standards. Some multi-storage-drive chassis may support only one form factor, while other multi-storage-drive chassis may support multiple form factors (e.g., backplane connectors may be compatible with storage drives having different factors and the storage-drive carriers may be adaptable for different form factors). Although the specification is primarily described in terms of storage drives having a 3.5 inch form factor, embodiments are not so limited. But, rather, other types of storage drives, form factors, and/or chassis may be employed.

0043Along with different form factors, storage drives can include different connectors for connecting to a multi-storage-drive-chassis backplane. These connectors may be referred to as storage-drive connectors and may be compatible with the backplane connectors. A storage-drive connector may be a SAS connector, SATA connector, universal serial bus (USB), firewire (or IEEE 1394), thunderbolt, PATA (Parallel Advanced Technology Attachment) connector, SCSI connector, Fibre Channel (FC) connector, Enhanced Integrated Drive Electronics (EIDE) connector, or the like.

0044Storage drives may have different power consumption profiles depending on various states of the storage drive, type of storage drive, or the like. Some of the different states of a storage drive may be an initial start-up power state; an idle state, an initial access state, and a sustained read/write state. The initial start-up power state may be when an initial amount of power is provided to the storage drive for the storage drive to provide basic communication with other devices. The idle state may be while the storage drive is awaiting a read/write request. The initial access state may be an initial amount of power required to make a read or write of the drive (e.g., an initial power required to start spinning the disk of a HDD). The sustained read/write state may be while a storage drive is fulfilling a read or write request after the initial read/write state.

0045As used herein, the term “controller” or “controller computer” refers to a computer or physical device that is separate from a typical/non-specific/general storage drive and separate from a multi-storage-drive chassis, but can be electrically coupled between an individual storage drive and the chassis backplane. Briefly, the controller can accept data in a storage drive supported protocol through a storage-drive connector and convert it into an Ethernet supported protocol for output through the backplane connector and over the Ethernet switch fabric interface to other network devices (or controllers). Similarly, the controller can accept data in an Ethernet supported protocol through the backplane connector and convert it to a storage drive supported protocol for output through the storage-drive connector to the storage drive. In various embodiments, each controller effectively makes each separate storage drive individually network accessible by other controllers and/or network computers.

0046In various embodiments, the controller may have a first connector, a second connector, a processor, memory, and other peripheral circuitry. In various embodiments, the processor and memory (and other peripheral circuitry) may be mounted on a circuit board, with the first connector and second connector positioned opposing each other on opposite sides of the board. In some embodiments, the first connector may be positioned on a first side of the board and the second connector may be positioned on a second side of the board, where the processor, memory, and periphery circuitry may be mounted to the first side, second side, or a combination thereof.

0047The first connector may be a connector that can couple with a storage-drive connector. And the second connector may be a connector that can couple with a backplane connector of a multi-storage-drive chassis. The first connector may be selected based on the storage-drive connector, so that the first connector and the storage-drive connector are compatible (e.g., the storage-drive connector may be a male connector, which can mate with a female first connector on the controller). In at least one of various embodiments, the first connector may be a SATA connector (but other connectors may be employed). Similarly, the second connector may be selected based on the backplane connector, so that the second connector and the backplane connector are compatible (e.g., the second connector may be a male connector, which can mate with a female backplane connector). In at least one of various embodiments, the second connector may be a SAS connector (but other connectors may be employed). In various embodiments, the types of connectors that may be utilized may include, for example, SAS connector, SATA connector, universal serial bus (USB), firewire (or IEEE 1394), thunderbolt, PATA (Parallel Advanced Technology Attachment) connector, SCSI connector, Fibre Channel (FC) connector, Enhanced Integrated Drive Electronics (EIDE) connector, or the like.

0048In some embodiments, the controller board may be a universal board that can accept different types of first connectors and/or second connectors. In at least one of various embodiments, a user may be enabled to affix the first connector and/or the second connector to the controller board. For example, assume a user has a multi-storage-drive chassis that includes SAS connectors as the backplane connectors, the user has three storage drives with SATA connectors and three storage drives with USB connectors. In this example, the user can put together six different controllers, three controllers with a SATA connector as first connector and a SAS connector as the second connector, and three other controllers with a USB connector as the first connector and a SAS connector as the second connector. This universal controller board can enable a user to use virtually any storage drive (with a controller-supported connector type) with virtually any multi-storage-drive chassis (with a controller-supported connector type), regardless of the storage drive and chassis having connectors that are compatible with each other.

0049In various embodiments, the controller may have dimensions that fit into the form factor shadow of the storage drive. As described in more detail herein, a circuit board of the controller may have a shape that fits within the dimensions of a lateral cross-section of the storage drive. Similarly, the overall size of the controller may be determined such that the controller and storage drive—when coupled together—is compatible with a drive carrier for the multi-storage-drive chassis. In various embodiments, “fitting into the form factor shadow of the storage drive” may refer to a physical shape of the controller being operative to fit adjacent to a correspondingly coupled storage drive connector and occupy less space than is bounded by peripheral edges of an end of a separate housing of a storage drive coupled to the storage drive connector. In some embodiments, this physical shape of the controller may fit into the peripheral edges of a lateral-cross second of the storage drive.

0050As described in more detail herein, a controller may be operative to control/manage a single storage drive. So, unlike a master computer that would control/manage a plurality of storage drives, each controller individually controls/manages its own corresponding individual storage drive. Although, in various embodiments, controllers may communicate with each other to coordinate and perform tasks between a plurality of storage drives. In some embodiments, controllers can communicate locally (without accessing the chassis interface for communication with external/remote devices) with other controllers through the Ethernet switch fabric interface of the chassis via Ethernet protocols.

0051In various embodiments, a controller can individually determine one or more power-up sequences and/or manage the voltage and/or power supplied to its corresponding storage drive (i.e., the storage drive that the controller is coupled to). In other embodiments, a plurality of controllers can coordinate with each other to schedule power-up sequences for a plurality of storage drives (e.g., to minimize the power spike effects of powering up multiple storage drives at the same time).

0052In other embodiments, the controller may monitor various performance characteristics of its corresponding drive (e.g., power consumption, temperature, response time/latency, or the like) to provide comprehensive storage drive analytics and diagnostics at the individual drive level. This type of monitoring can allow a controller to identify that its corresponding drive may be about to fail (e.g., changes in power consumption, temperatures above a threshold, increased latency, or the like), and coordinate with other controllers (or an administrator) to backup the potentially failing drive's data, halt future write operations to potentially failing drive, or the like.

0053In various embodiments, instead of a second connector providing a wired connection for communication to a backplane and the Ethernet switch fabric, the controller may instead provide wireless communication with one or more radio adapters located in a wireless multi-storage-drive chassis. In various embodiments, the wireless controller may include one or more wireless interfaces with antennas that enable communication with one or more radio adapters and/or one or more wireless controllers located in a wireless multi-storage-drive chassis. The wireless interfaces may be removed and exchanged and/or reprogrammed to accommodate at least a wireless communication protocol employed by a corresponding radio adapter. The wireless controller may be configured to wirelessly communicate through a channel in a waveguide, and/or outside of a waveguide, with one or more other wireless controllers and/or one or more other radio adapters. The wireless controller may include one or more antennas for wirelessly communicating. Also, the wireless controller may include a connector for receiving power from a wireless multi-storage-drive chassis. In various embodiments, the wireless controller enables communication between the chassis' storage devices and one or more radio adapters over a high bandwidth wireless connection, e.g., a WiFi 802.11 ad.

0054It should be noted that these examples of controller functionality are for illustration purposes and should not be construed as limiting, and that each controller may perform additional tasks and/or actions at the individual storage drive level and/or coordinate with each other to perform tasks and/or actions across a plurality of storage drives.

0055The following briefly describes embodiments of the invention in order to provide a basic understanding of some aspects of the invention. This brief description is not intended as an extensive overview. It is not intended to identify key or critical elements, or to delineate or otherwise narrow the scope. Its purpose is merely to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

0056Briefly stated, various embodiments are directed to a controller that provides individual network accessibility to a storage drive and provides individual control and management of the storage drive, while maintaining a form factor that is compatible with a typical multi-storage-drive chassis. In various embodiments, the controller (also referred to as a controller computer) may include at least a first connector, a second connector, a memory device, and a processor device. In various embodiments, a physical shape of the controller may be operative to fit adjacent to the storage drive connector and occupy less space than is bounded by peripheral edges of an end of a separate housing of the storage drive coupled to the storage drive connector.

0057The first connector may be operative to be coupled with a storage-drive connector of a storage drive. In some embodiments, the first connector may be a SATA connector. The second connector may be operative to be coupled with a backplane connector of a multi-storage-drive chassis. In some embodiments, the second connector may be a SAS connector. In various embodiments, at least one of the first connector or the second connector may be removably coupled to the controller computer.

0058The processor device may be operative execute instructions stored by the memory device to at least communicate with at least one other controller to cooperatively manage operation of the storage drive and at least one other storage drive correspondingly coupled to the at least one other controller computer. In at least one of the various embodiments, at least one storage drive may be a different type than another type of the storage drive.

0059In some embodiments, the controller may convert at least a portion of communication received through the first connector from a storage-drive protocol into an Ethernet protocol for output through the second connector. In other embodiments, the controller may convert at least a portion of communication received through the second connector from the Ethernet protocol into the storage-drive protocol for output through the first connector. In some embodiments, the controller computer enables the storage drive to be network addressable independent and separate from other storage drives.

0060In various embodiments, the controller may be operative to communicate—independent of a multi-storage-drive-chassis controller—with the at least one other controller to manage power-up sequences of the storage drive and the at least one other storage drive correspondingly coupled with the at least one other controller. In some embodiments, the controller may controller a power-up sequence of its correspondingly coupled storage drive. In some embodiments, the may determine a power supply of a multi-storage-drive chassis and at least one or more storage drive parameters of the storage drive. Based on the determined storage drive parameters and the determined power supply, the controller may determine at least one power-up sequence for the storage drive. The controller may employ one of the at least one power-up sequence that is optimal based on a request to access data on at least the storage drive.

0061In various other embodiments, the controller may be operative to communicate—independent of a multi-storage-drive-chassis controller—with the at least one other controller to manage distributed data storage and recovery between the storage drive and the at least one other storage drive correspondingly coupled with the at least one other controller.

0062In some embodiments, the controller may be operative to determine if the correspondingly coupled storage drive is potentially failing. In at least one embodiment, the controller may determine a profile of the storage drive, wherein the profile includes at least a history of at least one of power consumption, temperature, or latency of the storage drive. Based on a comparison of the profile to with other profiles of other storage drives, the controller may determine if the storage drive is exhibiting failure characteristics. In other embodiments, the controller may monitoring a performance of the storage drive and generate generating a profile for the storage drive based on the monitored performance. The controller may determine if the storage drive is potentially failing based on variations in the storage drive's profile as compared to profiles for the at least one other storage drive that is correspondingly coupled to the at least one other controller computer. In at least one embodiment, the controller may provide an alert regarding the determined potentially failing storage drive. In some other embodiments, the controller may provide alert and/or provide a request to backup the storage drive to an administrator of the storage drive, such as if the controller determines that the storage drive is potentially failing. In at least one of various embodiments, the controller may modifying an amount of power supplied to the storage drive, such as if it is determined to be potentially failing.

0000Illustrative Operating Environment

0063<figref idref="DRAWINGS">FIG. 1</figref> shows components of one embodiment of an environment in which various embodiments of the invention may be practiced. Not all of the components may be required to practice the various embodiments, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention. As shown, system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref> may include multi-storage-drive chassis <b>110</b>, network computers <b>102</b>-<b>105</b>, and network <b>108</b>.

0064Network computers <b>102</b>-<b>105</b> may communicate with multi-storage-drive chassis <b>110</b> via network <b>108</b>. Network <b>108</b> may be configured to couple network computers with other computing devices, including network computers <b>102</b>-<b>105</b>, multi-storage-drive chassis <b>110</b>, other networks, or the like. In various embodiments, information communicated between devices may include various kinds of information, including, but not limited to, processor-readable instructions, client requests, server responses, program modules, applications, raw data, control data, video data, voice data, image data, text data, or the like. In some embodiments, this information may be communicated between devices using one or more technologies and/or network protocols.

0065In some embodiments, network <b>108</b> may include various wired networks, wireless networks, or any combination thereof. In various embodiments, network <b>108</b> may be enabled to employ various forms of communication technology, topology, computer-readable media, or the like, for communicating information from one electronic device to another. For example, network <b>108</b> can include—in addition to the Internet—LANs, WANs, Personal Area Networks (PANs), Campus Area Networks (CANs), Metropolitan Area Networks (MANs), direct communication connections (such as through a USB port), or the like, or any combination thereof.

0066In various embodiments, communication links within and/or between networks may include, but are not limited to, twisted wire pair, optical fibers, open air lasers, coaxial cable, plain old telephone service (POTS), wave guides, acoustics, full or fractional dedicated digital lines (such as T1, T2, T3, or T4), E-carriers, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links (including satellite links), or other links and/or carrier mechanisms known to those skilled in the art. Moreover, communication links may further employ any of a variety of digital signaling technologies, including without limit, for example, DS-0, DS-1, DS-2, DS-3, DS-4, OC-3, OC-12, OC-48, or the like. In some embodiments, a router (or other intermediate network device) may act as a link between various networks—including those based on different architectures and/or protocols—to enable information to be transferred from one network to another. In other embodiments, network computers and/or other related electronic devices could be connected to a network via a modem and temporary telephone link. In essence, the network may include any communication technology by which information may travel between computing devices.

0067Network <b>108</b> may, in some embodiments, include various wireless networks, which may be configured to couple various portable network devices, remote computers, wired networks, other wireless networks, or the like. Wireless networks may include any of a variety of sub-networks that may further overlay stand-alone ad-hoc networks, or the like, to provide an infrastructure-oriented connection for at least network computers <b>103</b>-<b>105</b>. Such sub-networks may include mesh networks, Wireless LAN (WLAN) networks, cellular networks, or the like. In at least one of the various embodiments, the system may include more than one wireless network.

0068Network <b>108</b> may employ a plurality of wired and/or wireless communication protocols and/or technologies. Examples of various generations (e.g., third (3G), fourth (4G), or fifth (5G)) of communication protocols and/or technologies that may be employed by the network may include, but are not limited to, Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access 2000 (CDMA2000), High Speed Downlink Packet Access (HSDPA), Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (Ev-DO), Worldwide Interoperability for Microwave Access (WiMax), time division multiple access (TDMA), Orthogonal frequency-division multiplexing (OFDM), ultra wide band (UWB), Wireless Application Protocol (WAP), user datagram protocol (UDP), transmission control protocol/Internet protocol (TCP/IP), any portion of the Open Systems Interconnection (OSI) model protocols, session initiated protocol/real-time transport protocol (SIP/RTP), short message service (SMS), multimedia messaging service (MMS), or any of a variety of other communication protocols and/or technologies. In essence, the network may include communication technologies by which information may travel between network computers <b>102</b>-<b>105</b>, multi-storage-drive <b>110</b>, other computing devices not illustrated, other networks, or the like.

0069In various embodiments, at least a portion of the network may be arranged as an autonomous system of nodes, links, paths, terminals, gateways, routers, switches, firewalls, load balancers, forwarders, repeaters, optical-electrical converters, or the like, which may be connected by various communication links. These autonomous systems may be configured to self-organize based on current operating conditions and/or rule-based policies, such that the network topology of the network may be modified.

0070At least one embodiment of network computers <b>102</b>-<b>105</b> is described in more detail below in conjunction with network computer <b>200</b> of <figref idref="DRAWINGS">FIG. 2</figref>. Briefly, in some embodiments, network computers <b>102</b>-<b>105</b> may be configured to communicate with multi-storage-drive chassis <b>110</b> to enable distributed storage. In some embodiments, network computers <b>102</b>-<b>105</b> may communicate with individual controllers (e.g., controllers <b>114</b>) for each storage drive associated with multi-storage-drive chassis <b>110</b> (e.g., storage drives <b>116</b>) to perform reads and writes of data, access information and/or analytics, or the like. In various embodiments, network computers <b>102</b>-<b>105</b> may be remote and/or separate from chassis <b>110</b> and controllers <b>114</b>.

0071In some embodiments, at least some of network computers <b>102</b>-<b>105</b> may operate over a wired and/or wireless network (e.g., network <b>108</b>) to communicate with other computing devices and/or multi-storage-drive chassis <b>110</b>. Generally, network computers <b>102</b>-<b>105</b> may include computing devices capable of communicating over a network to send and/or receive information, perform various online and/or offline activities, or the like. It should be recognized that embodiments described herein are not constrained by the number or type of network computers employed, and more or fewer network computers—and/or types of network computers—than what is illustrated in <figref idref="DRAWINGS">FIG. 1</figref> may be employed.

0072Devices that may operate as network computers <b>102</b>-<b>105</b> may include various computing devices that typically connect to a network or other computing device using a wired and/or wireless communications medium. Network computers may include portable and/or non-portable computers. In some embodiments, network computers may include client computers, server computers, or the like. Examples of network computers <b>102</b>-<b>105</b> may include, but are not limited to, desktop computers (e.g., network computer <b>102</b>), personal computers, multiprocessor systems, microprocessor-based or programmable electronic devices, network PCs, laptop computers (e.g., network computer <b>103</b>), smart phones (e.g., network computer <b>104</b>), tablet computers (e.g., network computer <b>105</b>), cellular telephones, display pagers, radio frequency (RF) devices, infrared (IR) devices, Personal Digital Assistants (PDAs), handheld computers, wearable computing devices, entertainment/home media systems (e.g., televisions, gaming consoles, audio equipment, or the like), household devices (e.g., thermostats, refrigerators, home security systems, or the like), multimedia navigation systems, automotive communications and entertainment systems, integrated devices combining functionality of one or more of the preceding devices, or the like. As such, network computers <b>102</b>-<b>105</b> may include computers with a wide range of capabilities and features. In some embodiments, network computers <b>102</b>-<b>105</b> may be referred to as remote computers, because they access and/or store data on a different computer/device, such as multi-storage-drive chassis <b>110</b>. In some embodiments, multi-storage-drive chassis <b>110</b> may be maintained at a location that is separate from network devices <b>102</b>-<b>105</b> (e.g., cloud computing/storage that utilize distributed storage systems).

0073Network computers <b>102</b>-<b>105</b> may access and/or employ various computing applications to enable users of network computers to perform various online and/or offline activities. Such activities may include, but are not limited to, generating documents, gathering/monitoring data, capturing/manipulating images, managing media, managing financial information, playing games, managing personal information, browsing the Internet, or the like. In some embodiments, network computers <b>102</b>-<b>105</b> may be enabled to connect to a network through a browser, or other web-based application.

0074Network computers <b>102</b>-<b>105</b> may further be configured to provide information that identifies the network computer. Such identifying information may include, but is not limited to, a type, capability, configuration, name, or the like, of the network computer. In at least one embodiment, a network computer may uniquely identify itself through any of a variety of mechanisms, such as an Internet Protocol (IP) address, phone number, Mobile Identification Number (MIN), media access control (MAC) address, electronic serial number (ESN), or other device identifier.

0075Multi-storage-drive chassis <b>110</b> may include backplane <b>112</b> and may be configured to house a plurality of separate storage drives, such as storage drives <b>116</b>, which may include more or less devices than what is illustrated in the figure. In some embodiments, each storage drive may utilize (e.g., be fastened to) a storage carrier or tray (not shown) for insertion into the chassis. However, in some embodiments, the storage drives may be affixed directly to the chassis. As described herein, a separate controller (e.g., controllers <b>114</b>) may be coupled to each separate storage drive and the combination of the storage drive and controller may be coupled to backplane <b>112</b>. Each of controllers <b>114</b> may provide a separately addressable network interface for each of storage drives <b>116</b>.

0076In various embodiments, chassis <b>110</b> may be configured and/or modified to provide Ethernet access to backplane <b>112</b>. In at least one embodiment, backplane <b>112</b> may provide Ethernet access to each of controllers <b>114</b> through an Ethernet switch fabric interface that serially connects backplane connectors. In some embodiments, chassis <b>110</b> may include an Ethernet port and/or interface component for connecting chassis <b>110</b> to network <b>108</b>.

0077Controllers <b>114</b> may directly communicate with network computers <b>102</b>-<b>105</b>. In various embodiments, each of controllers <b>114</b> may convert data received from its corresponding storage drive <b>116</b> into an Ethernet protocol and communicated to network computers <b>102</b>-<b>105</b> via backplane <b>112</b> and network <b>108</b>. Similarly, each controller may convert data received from network computers <b>102</b>-<b>105</b> (via network <b>108</b> and the Ethernet connection supported by backplane <b>112</b>) into a storage drive protocol for accessing its own corresponding storage drive.

0078Since storage drives <b>116</b> can be of any typical/non-specific/general storage drive/agnostic, each of controllers <b>114</b> may perform different types of data protocol conversions depending on the type storage drive that it is coupled with. In this way, each storage drive can be individually addressable and network computers <b>102</b>-<b>105</b> can individually access each separate storage drive <b>116</b> via an Ethernet protocol without having to utilize a centralized/master controller—either a chassis controller or a standalone computer that centrally manages access to each storage drive <b>116</b>. So, in various embodiment, each separate controller (of controllers <b>114</b>), and thus each separate storage drive, is individually addressable and can be individually accessed by network devices <b>102</b>-<b>105</b>.

0079In various embodiments, controllers <b>114</b> may communicate with each other via the Ethernet connection of backplane <b>112</b> to employ various storage drive management actions, monitoring actions, or the like. So in some embodiments, controllers <b>114</b> may communicate with each other—independent of a chassis controller or other primary/main/master/coordinator computer—to perform various actions (some of which may be done in parallel), including, but not limited to, data reads, data writes, data recovery, or the like.

0080For example, in some embodiments, the controllers may communicate with each other to perform distributed data storage actions among a plurality of storage drives. In one non-limiting example, network computer <b>102</b> may provide a write request to controller <b>118</b> (in some embodiments, this request may go through a load balancer or other routing device). Controller <b>118</b> may work together with the separate controllers <b>114</b> to coordinate the write request across one or more of storage drives <b>116</b> (even if the network computer is unaware of the other controllers and/or storage drives). In this example, controller <b>118</b> may coordinate with the other controllers of controllers <b>114</b> to determine which controller/storage drives will store what data. Since each controller <b>114</b> is network accessible (e.g., IP addressable), in some embodiments, network computer <b>102</b> may be able to individually access each storage drive <b>116</b> and indicate which storage drives will store what data.

0081Similarly, the controllers may communicate with each other to recover lost data. For example, assume there are 20 storage drives that are logically separated into four clusters, and each drive is coupled to a controller, as described herein. If one of the drives in a single cluster fails and the other drives in the same cluster are configured to and able rebuild the lost data of the failed drive, then the controllers associated with the drives in that cluster can coordinate the rebuild of the lost data, while the other 15 drives continue to perform data reads, writes, or the like.

0082In some other embodiments, controllers <b>114</b> may manage and coordinate power utilization of storage drives <b>116</b>. In various embodiments, power consumption management and/or power management of a storage drive may include enabling and/or disabling various features of a storage drive. For example, a controller can manage the power consumption of its correspondingly coupled storage drive by providing different commands (e.g., through the command set) to the storage drive to enable/disable various features of the storage drive. In other embodiments, power management may include switching the power rails (e/g/. +3.3V, +5V and +12V) on and off.

0083In various embodiments, controllers <b>114</b> may communicate with each other to coordinate a schedule for powering up storage drives <b>116</b>. In some embodiments, each controller <b>114</b> may be operative to determine parameters and/or capabilities of its corresponding storage drive. This determination may be based on a type of connector that is coupled to the storage drive (i.e., the first connector), previously stored power consumption profile of the storage drive, drive identifier, or the like.

0084Based on the parameters and/or capabilities of each storage drive in the chassis, controllers <b>114</b> may determine an efficient way of powering up the storage drives to reduce spikes in power consumption by the storage drives (i.e., each controller may determine various power-up sequences for its correspondingly coupled storage drive). In particular, mechanical drives (e.g., HDDs) may have an initial spike in power consumption when they turn on due to the electrical properties of powering up the motor to drive the disk. This power consumption can be compared to that of SSDs, which typically is a more step function when the drive is powered up.

0085Since each controller can manage the power supplied to its corresponding storage drive, and since there is no need for the drives to be of a uniform type (or model, or from a same manufacturer), the controllers as a group can determine and employ a power-up schedule that can allow one or more of the storage drives to power up before other storage drives are powered up. For example, in some embodiments, each of the mechanical drives (e.g., HDD) may be power up before the SSDs on the same chassis. Similarly, each the power up of each drive may be slightly staggered to further reduce the issues that can arise from a spike in power consumption. By optimizing the schedule for powering storage drives <b>116</b>.

0086Similarly, a controller can individually and dynamically adjust the power of its corresponding drive at any given time. In this way, each controller can individually or collectively monitor the temperature of the various drives and adjust their power individually.

0087This type of drive-specific power control can enable a controller to reduce a drive's power—e.g., if the drive has a temperature above a threshold in an attempt to give the drive time to cool down. In other embodiments, a controller can increase or decrease the power supplied to its correspondingly coupled storage drive based on trade-offs between power consumption, speed of accessing data, regularity or frequency of access requests, or the like. In yet other embodiments, a plurality of controllers can coordinate to reduce power consumption on a per drive basis across a plurality of storage drives. So, in some embodiments, the controller may individually monitor and adjust the power supplied to an individual storage drive or may work collectively to manage/adjust the power supplied to the plurality of storage drives.

0088This type of control at the drive level can allow for reduced power consumption during various times of the day. For example, if some storage drives are idle for a predetermined time and the current time is at a peak price for energy (e.g., dollars per kilowatt used), then the controllers for those storage drives may individually reduce the power supplied to those storage drives—while other storage drives (that are accessed more recently) are maintained at a higher power. Therefore, a user of the chassis can save money on energy costs without greatly affecting performance.

0089Since each separate storage drive is managed by a separate controller, each controller can provide individualized management and/or monitoring of a corresponding storage drive. For example, in some embodiments, a controller can monitor power consumption, temperature, or other performance characteristics of the coupled storage drive and provide those monitored analytics to one of network computers <b>102</b>-<b>105</b> or to another controller. In at least one such embodiment, if a controller determines that its corresponding storage drive is operating at a temperature above a given threshold, the controller can reduce the power consumption of the drive or power it down completely (e.g., until the drive temperature falls below another threshold value).

0090In other embodiments, the controller may identify that its corresponding drive is exhibiting performance characteristics of a failing drive (e.g., extra power consumption, overheating, excessive latency (e.g., above a time threshold) while performing a read/write operation, or the like), then the controller can notify the other controllers (or one or more of network devices <b>102</b>-<b>105</b>) that its drive may be about to fail. Once notified of the possible failure, the controllers can take steps to anticipate the failure. Such anticipation may include employing other controllers to write to other non-failing drives, initiate copying of the failing drive to a spare drive (that also has a corresponding controller), or the like.

0091In various other embodiments, the combined/coupled storage drive and controller may utilize hot swap features of chassis <b>110</b>.

0092In some embodiments, controllers <b>114</b> may cooperatively coordinate with each other in a peer-to-peer architecture to control/manage operations of each correspondingly coupled storage drive <b>116</b>, as described herein. In other embodiments, controllers <b>114</b> may cooperatively coordinate storage-drive-operation control/management with each other as more of a server-to-peer architecture, where one of controllers <b>114</b> may operate as a master controller and one or more of the other controllers of controllers <b>114</b> may operate as slave controllers.

0093In at least one such architecture, the slave controllers may provide information (e.g., storage-drive characteristics, performance parameters, or the like) to the master controller. The master controller can determine storage-drive power-up sequences and/or schedules, identify potentially failing storage drives, coordinate backup and/or recovery of a potentially failing (or already failed) storage drive, or the like, as described herein. Based on these determinations, the master controller may provide instructions to one or more of the slave controllers for managing their correspondingly coupled storage drives. For example, the master controller may provide separate instructions to each slave controller, which may separately indicate when and/or how a slave controller is to power-up its correspondingly coupled storage drive (noting that the master controller may also have a correspondingly coupled storage drive that may be managed/controlled in conjunctions with the other storage drives). In other embodiments, the controllers may communicate information amongst each other without directly accessing, managing, or otherwise controlling the storage drives.

0094In various other embodiments, a network computer (e.g., one of network computers <b>102</b>-<b>105</b>, which may be remote to chassis <b>110</b>) and controllers <b>114</b> may operate in a server-to-peer architecture to control/manage operations of one or more storage drives <b>116</b> in chassis <b>110</b> (or storage drives in multiple chassis)—similar to that which is described above. In at least one such embodiment, the network computer may operate as a master network computer and controllers <b>114</b> may operate as slave controllers. In various embodiments, the network computer (e.g., a master network computer) may coordinate and/or instruct each of controllers <b>114</b> (e.g., slave controllers) to control/manage operations of each correspondingly coupled storage drive <b>116</b>. For example, controllers <b>114</b> may provide information (e.g., storage-drive characteristics, performance parameters, or the like) to the master network computer. The master network computer can determine storage-drive power-up sequences and/or schedules, identifying potentially failing storage drives, coordinate backup and/or recovery of a potentially failing (or already failed) storage drive, or the like, as described herein. Based on these determinations, the master network computer may provide instructions to one or more of controllers <b>114</b> for managing their correspondingly coupled storage drives. For example, the master network computer may provide separate instructions to each controller, which may separately indicate when and/or how a controller is to power-up a correspondingly coupled storage drive.

0095It should be noted that these architectures are not to be construed as exhaustive or limiting, but rather, other architectures may be employed in accordance with embodiments described herein. For example, in various embodiments, network computers <b>102</b>-<b>105</b> and/or controllers <b>114</b> may operate in various different architectures including, but not limited to, a peer-to-peer architecture, peer-to-server architecture, server-to-server architecture, or the like, to control/manage the operations of one or more of storage drives <b>116</b>. As described herein, the control/management of storage-drive operations may include, but is not limited to determining storage-drive power-up sequences and/or schedules, identifying potentially failing storage drives, coordinate backup and/or recovery of a potentially failing (or already failed) storage drive, or the like.

0000Illustrative Network Computer

0096<figref idref="DRAWINGS">FIG. 2</figref> shows one embodiment of a network computer <b>200</b> that may include many more or less components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Network computer <b>200</b> may represent, for example network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>, and/or other network devices.

0097Network computer <b>200</b> may be configured to operate as a server, client, peer, a host, or other computing device. In general, network computer <b>200</b> may be a desktop computer, mobile computer (e.g., laptop computers, smart phones, tablets, or the like), server computer, or any other network computer that can communicate through a network to access and/or store data at a remote/secondary location (i.e., multi-storage-drive chassis <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>).

0098Network computer <b>200</b> may include processor <b>202</b>, processor readable storage media <b>228</b>, network interface <b>230</b>, an input/output interface <b>232</b>, hard disk drive <b>234</b>, video display adapter <b>236</b>, and memory <b>226</b>, all in communication with each other via bus <b>238</b>. In some embodiments, processor <b>202</b> may include one or more central processing units.

0099Network interface <b>230</b> includes circuitry for coupling network computer <b>200</b> to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, protocols and technologies that implement any portion of the OSI model, GSM, CDMA, time division multiple access (TDMA), UDP, TCP/IP, SMS, MMS, GPRS, WAP, UWB, WiMax, SIP/RTP, EDGE, W-CDMA, LTE, UMTS, OFDM, CDMA2000, EVDO, HSDPA, or any of a variety of other wireless communication protocols. Network interface <b>230</b> is sometimes known as a transceiver, transceiving device, or network interface card (NIC). In various embodiments, network interface unit <b>230</b> may enable network computer <b>200</b> to access and/or store data on one or more storage drives associated with a multi-storage-drive chassis, such as multi-storage-drive chassis <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0100Network computer <b>200</b> may comprise input/output interface <b>232</b> for communicating with external devices, such as a keyboard, or other input or output devices not shown in <figref idref="DRAWINGS">FIG. 2</figref>. Input/output interface <b>232</b> can utilize one or more communication technologies, such as Universal Serial Bus (USB), infrared, WiFi, WiMax, Bluetooth™, wired technologies, or the like.

0101Memory <b>226</b> may include various types of storage technologies, which may include various types of non-volatile storage, volatile storage, or a combination thereof. Examples of memory <b>226</b> may include, but are not limited to Random Access Memory (RAM) (e.g., RAM <b>204</b>), dynamic RAM (DRAM), static RAM (SRAM), Read-only Memory (ROM) (e.g., ROM <b>222</b>), Electrically Erasable Programmable Read-only Memory (EEPROM), flash memory, hard disk drives, optical drives, magnetic computer storage devices, tape drives, floppy disk drives, or other processor-readable storage media. In some embodiments, memory <b>226</b> may include processor-readable transitory or non-transitory storage media. In various embodiments, memory <b>226</b> may include one or more caches.

0102Memory <b>226</b> may be utilized to store information, such as, but not limited to, processor-readable instructions (also referred to as computer-readable instructions), structured and/or unstructured data, program modules, or other data/information. In various embodiments, some of the data/information stored by memory <b>226</b> may be used by processor <b>202</b> to execute and/or perform actions. In some embodiments, at least some of the data/information stored by memory <b>226</b> may also be stored on another component of network computer <b>200</b>, such as, but not limited to, process-readable storage media <b>228</b>. Processor-readable storage media <b>228</b> may include one or more storage technologies, such as, but not limited to, those storage technologies described above for memory <b>226</b>. In various embodiments, processor-readable storage media <b>228</b> may also be referred to as computer-readable storage media, processor-readable storage devices, and/or computer-readable storage devices. In some embodiments, process-readable storage media <b>228</b> may be removable or non-removable from network computer <b>200</b>.

0103Memory <b>226</b> may include system firmware, such as BIOS <b>224</b>, which may store instructions for controlling low-level operations of network computer <b>200</b>. Memory <b>226</b> may also store operating system <b>206</b> for controlling the operation of network computer <b>200</b>. In some embodiments, operating system <b>206</b> may include a general purpose operating system (e.g., UNIX, LINUX™, Windows™, OSX™, Windows Phone™, iOS™, Android™, or the like). The operating system functionality may be extended by one or more libraries, modules, plug-ins, or the like.

0104Memory <b>226</b> may include one or more data storage <b>208</b>, which can be utilized by network computer <b>200</b> to store, among other things, applications <b>214</b> and/or other data. For example, data storage <b>208</b> may also be employed to store information that describes various capabilities of network computer <b>200</b>. The information may then be provided to another device based on any of a variety of events, including being sent as part of a header during a communication, sent upon request, or the like. Data storage <b>208</b> may also include a database, text, spreadsheet, folder, file, or the like, that may be configured to maintain and store user account identifiers, user profiles, email addresses, IM addresses, and/or other network addresses; or the like. Data storage <b>208</b> may further include program code, data, algorithms, and the like, for use by a processor, such as processor <b>202</b> to execute and perform actions. In one embodiment, at least some of data store <b>208</b> might also be stored on another component of network computer <b>200</b>, including, but not limited to processor-readable storage media <b>228</b>, hard disk drive <b>234</b>, or the like.

0105Applications <b>214</b> may include computer executable instructions that, when executed by network computer <b>200</b>, transmit, receive, and/or otherwise process instructions and data. Examples of application programs may include, but are not limited to, calendars, search programs, email client applications, IM applications, SMS applications, contact managers, task managers, transcoders, schedulers, database programs, word processing programs, encryption applications, security applications, spreadsheet applications, games, and so forth.

0106A mobile computer may include a browser application that is configured to receive and to send web pages, web-based messages, graphics, text, multimedia, and the like. The mobile computer's browser application may employ virtually any programming language, including a wireless application protocol messages (WAP), and the like. In at least one embodiment, the browser application is enabled to employ Handheld Device Markup Language (HDML), Wireless Markup Language (WML), WMLScript, JavaScript, Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML), eXtensible Markup Language (XML), HTML5, and the like.

0107Applications <b>214</b> may also include an application that can enable a user to individually access each separate controller (e.g., controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>) associated with each storage drive (e.g., storage drives <b>116</b> of <figref idref="DRAWINGS">FIG. 1</figref>) through a network. So, in some embodiments, each controller (i.e., each storage drive) may be individually network addressable by network computer <b>200</b>. This access can enable a user to employ control (e.g., power/voltage changes, temperature and other drive performance monitoring, or the like) over each individual drives within a multi-storage-drive chassis.

0108In various embodiments, network computer <b>200</b> may operate as a master network computer to cooperatively coordinate with at least one of controllers (e.g., controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>) to control/manage operations of one or more storage drives coupled to the controllers. In at least one such embodiment, network computer <b>200</b> may perform at least a portion of the operations described herein.

0000Illustrative Controller Computer

0109<figref idref="DRAWINGS">FIG. 3A</figref> shows one embodiment of a controller <b>300</b> that may include many more or less components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Controller <b>300</b> may represent, for example controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0110Controller <b>300</b> may be configured to enable individualized communication between a single storage drive (e.g., storage drives <b>116</b> of <figref idref="DRAWINGS">FIG. 1</figref>) and one or more network devices (e.g., network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>). It should be understood that although a single controller manages/controls a single storage drive, a plurality of controllers can work together to provide centralized management of a plurality of storage drives.

0111Controller <b>300</b> may include processor <b>302</b>, first connector <b>330</b>, second connector <b>332</b>, and memory <b>304</b>, all in communication with each other via bus <b>328</b>. In some embodiments, processor <b>302</b> may include one or more central processing units. First connector <b>330</b> may be a connector configured to couple with and/or accept a storage-drive connector. In at least one embodiment, first connector <b>330</b> may be a SATA connector—although other storage-drive-compatible connectors may be utilized, as described herein. Second connector <b>332</b> may be a connector configured to couple with and/or be accepted by a backplane connector of a multi-storage-drive chassis. In at least one embodiment, second connector <b>332</b> may be a SAS connector—although other backplane-compatible connectors may be utilized, as described herein.

0112Memory <b>304</b> may include various types of storage technologies, which may include various types of non-volatile storage, volatile storage, or a combination thereof. Examples of memory <b>304</b> may include, but are not limited to Random Access Memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), Read-only Memory (ROM), Electrically Erasable Programmable Read-only Memory (EEPROM), flash memory, or other processor-readable storage media. In some embodiments, memory <b>304</b> may include processor-readable transitory or non-transitory storage media. In various embodiments, memory <b>304</b> may include one or more caches.

0113Memory <b>304</b> may be utilized to store information, such as, but not limited to, processor-readable instructions (also referred to as computer-readable instructions), structured and/or unstructured data, program modules, or other data/information. In various embodiments, some of the data/information stored by memory <b>304</b> may be used by processor <b>302</b> to execute and/or perform actions.

0114Memory <b>304</b> may include system firmware, such as BIOS <b>308</b>, which may store instructions for controlling low-level operations of controller <b>300</b>. Memory <b>304</b> may also store operating system <b>306</b> for controlling the operation of controller <b>300</b>. In some embodiments, operating system <b>306</b> may include a general purpose operating system (e.g., UNIX, LINUX™, or the like) or a customized operating system. The operating system functionality may be extended by one or more libraries, modules, plug-ins, or the like.

0115Memory <b>304</b> may include one or more data storage <b>310</b>, which can be utilized by controller <b>300</b> to store, among other things, applications <b>320</b> and/or other data. Data storage <b>310</b> may further include program code, data, algorithms, and the like, for use by a processor, such as processor <b>302</b> to execute and Data storage <b>310</b> may be employed to store information associated with a storage drive that is connected to controller <b>300</b>, such as, for example, a history of temperatures, voltages, utilization, or the like. Memory <b>304</b> may also be utilized to store network traffic information to enable communication with other devices, such as network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref> or other controllers (e.g., controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>). Applications <b>320</b> may include various applications for managing a storage drive, including, for example, power scheduling/management, diagnostic recording and assessment tools, or the like. In any event, controller <b>300</b> may be configured to employ various embodiments, combinations of embodiments, processes, or parts of processes, as described herein.

0116<figref idref="DRAWINGS">FIG. 3B</figref> shows one embodiment of wireless controller <b>340</b> that may include many more or less components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Wireless controller <b>340</b> may represent, for example controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0117Controller <b>340</b> may be configured to enable individualized communication between a single storage drive (e.g., storage drives <b>116</b> of <figref idref="DRAWINGS">FIG. 1</figref>) and one or more network devices (e.g., network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>). It should be understood that although a single controller manages/controls a single storage drive, a plurality of controllers can work together to provide centralized management of a plurality of storage drives.

0118Controller <b>340</b> may include processor <b>302</b>, first connector <b>330</b>, second connector <b>332</b>, and memory <b>304</b>, all in communication with each other via bus <b>328</b>. In some embodiments, processor <b>302</b> may include one or more central processing units. First connector <b>330</b> may be a connector configured to couple with and/or accept a storage-drive connector. In at least one embodiment, first connector <b>330</b> may be a SATA connector—although other storage-drive-compatible connectors may be utilized, as described herein. Wireless interface <b>334</b> may include one or more antennas for communicating wireless signals with one or more other wireless controllers or one or more Radio Adapters. The wireless communication signals may be communicated with a standard wireless protocol, modified standard wireless protocol, and/or a proprietary wireless protocol.

0119Memory <b>304</b> may include various types of storage technologies, which may include various types of non-volatile storage, volatile storage, or a combination thereof. Examples of memory <b>304</b> may include, but are not limited to Random Access Memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), Read-only Memory (ROM), (Electrically Erasable Programmable Read-only Memory (EEPROM), flash memory, or other processor-readable storage media. In some embodiments, memory <b>304</b> may include processor-readable transitory or non-transitory storage media. In various embodiments, memory <b>304</b> may include one or more caches.

0120Memory <b>304</b> may be utilized to store information, such as, but not limited to, processor-readable instructions (also referred to as computer-readable instructions), structured and/or unstructured data, program modules, or other data/information. In various embodiments, some of the data/information stored by memory <b>304</b> may be used by processor <b>302</b> to execute and/or perform actions.

0121Memory <b>304</b> may include system firmware, such as BIOS <b>308</b>, which may store instructions for controlling low-level operations of controller <b>340</b>. Memory <b>304</b> may also store operating system <b>306</b> for controlling the operation of controller <b>340</b>. In some embodiments, operating system <b>306</b> may include a general purpose operating system (e.g., UNIX, LINUX™, or the like) or a customized operating system. The operating system functionality may be extended by one or more libraries, modules, plug-ins, or the like.

0122Memory <b>304</b> may include one or more data storage <b>310</b>, which can be utilized by controller <b>300</b> to store, among other things, applications <b>320</b> and/or other data. Data storage <b>310</b> may further include program code, data, algorithms, and the like, for use by a processor, such as processor <b>302</b> to execute and Data storage <b>310</b> may be employed to store information associated with a storage drive that is connected to controller <b>340</b>, such as, for example, a history of temperatures, voltages, utilization, or the like. Memory <b>304</b> may also be utilized to store network traffic information to enable communication with other devices, such as network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref> or other controllers (e.g., controllers <b>114</b> of <figref idref="DRAWINGS">FIG. 1</figref>). Applications <b>320</b> may include various applications for managing a storage drive, including, for example, power scheduling/management, diagnostic recording and assessment tools, or the like. In any event, controller <b>340</b> may be configured to employ various embodiments, combinations of embodiments, processes, or parts of processes, as described herein.

0000Illustrative Radio Adapter Computer

0123<figref idref="DRAWINGS">FIG. 3C</figref> shows one embodiment of radio adapter <b>350</b> that may include many more or less components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Radio Adapter <b>350</b> may represent, for example Radio Adapter <b>634</b> of <figref idref="DRAWINGS">FIG. 6B</figref>.

0124Radio Adapter <b>350</b> may be configured to enable individualized communication between wireless controller <b>340</b> and one or more network devices (e.g., network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>). It should be understood that although a single radio adapter may be employed, a plurality of radio adapters can work together to provide redundancy and flexible bandwidth to access a plurality of storage drives.

0125Controller <b>350</b> may include processor <b>352</b>, first connector <b>366</b>, wireless interface <b>368</b>, and memory <b>354</b>, all in communication with each other via bus <b>364</b>. In some embodiments, processor <b>352</b> may include one or more central processing units. First connector <b>366</b> may be a connector configured to couple to a remote network via a high bandwidth connection. In at least one embodiment, first connector <b>366</b> may be a fiber optic connector—although other high bandwidth connectors may be utilized. Wireless interface <b>368</b> may include one or more antennas for communicating wireless signals with one or more wireless controllers and/or one or more other Radio Adapters. The wireless communication signals may be communicated with a standard wireless protocol, modified standard wireless protocol, and/or a proprietary wireless protocol.

0126Memory <b>354</b> may include various types of storage technologies, which may include various types of non-volatile storage, volatile storage, or a combination thereof. Examples of memory <b>354</b> may include, but are not limited to Random Access Memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), Read-only Memory (ROM), Electrically Erasable Programmable Read-only Memory (EEPROM), flash memory, or other processor-readable storage media. In some embodiments, memory <b>354</b> may include processor-readable transitory or non-transitory storage media. In various embodiments, memory <b>354</b> may include one or more caches.

0127Memory <b>354</b> may be utilized to store information, such as, but not limited to, processor-readable instructions (also referred to as computer-readable instructions), structured and/or unstructured data, program modules, or other data/information. In various embodiments, some of the data/information stored by memory <b>354</b> may be used by processor <b>352</b> to execute and/or perform actions.

0128Memory <b>354</b> may include system firmware, such as BIOS <b>358</b>, which may store instructions for controlling low-level operations of radio adapter <b>350</b>. Memory <b>354</b> may also store operating system <b>356</b> for controlling the operation of radio adapter <b>350</b>. In some embodiments, operating system <b>356</b> may include a general purpose operating system (e.g., UNIX, LINUX™, or the like) or a customized operating system. The operating system functionality may be extended by one or more libraries, modules, plug-ins, or the like.

0129Memory <b>354</b> may include one or more data storage <b>360</b>, which can be utilized by controller <b>300</b> to store, among other things, applications <b>362</b> and/or other data. Data storage <b>360</b> may further include program code, data, algorithms, and the like, for use by a processor, such as processor <b>352</b> to execute and Data storage <b>360</b> may be employed to store information associated with accessing a network and/or a network device that is remote, managing communication with one or more wireless controllers, and managing communication with one or more other radio adapters. Memory <b>354</b> may also be utilized to store network traffic information to enable communication with other devices, such as network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref> or other radio adapters and wireless controllers. Applications <b>362</b> may include various applications for managing communication, or the like. In any event, radio adapter <b>350</b> may be configured to employ various embodiments, combinations of embodiments, processes, or parts of processes, as described herein.

0000General Operation

0130<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate top perspective views of a storage drive and a controller in accordance with embodiments described herein. Example <b>400</b>A may include storage drive <b>402</b> and a separate controller <b>406</b>. In various embodiments, storage drive <b>402</b> may be any of a number of typical, generic, or non-specific storage drive (e.g., one of storage drives <b>116</b> of <figref idref="DRAWINGS">FIG. 1</figref>) that may be compatible with a multi-storage-drive chassis (e.g., multi-storage-drive chassis <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>).

0131Storage drive <b>402</b> may be a hard disk drive, solid-state drive, optical drive, or other type of persistent (typically long-term) storage drives or devices. Storage drive <b>402</b> may include storage-drive connector <b>404</b>. In various embodiments, storage-drive connector <b>404</b> may be a SATA connector or a SAS connector. Although embodiments herein are described primarily in terms of SATA or SAS compliant, other types of storage-drive connectors or interfaces, now known or later developed, may be employed, such as, but not limited to, USB, firewire (or IEEE 1394), thunderbolt, PATA connector, SCSI connector, Fibre Channel (FC) connector, EIDE connector, or the like.

0132Controller <b>406</b> may be an embodiment of controller <b>300</b> of <figref idref="DRAWINGS">FIG. 3</figref>. Controller <b>406</b> may include first connector <b>408</b>, second connector <b>410</b>, and circuit board <b>412</b>. In various embodiments, the type of first and/or second connectors may be dependent on the type of connector of the storage drive and/or the type of connector on the backplane of the chassis. In some embodiments, first connector <b>408</b> may be a SATA connector, SAS connector, or other type of connector that is compatible with storage-drive connector <b>404</b>. In other embodiments, second connector <b>410</b> may be a SAS, SATA connector, or other connector compatible with a backplane of a multi-storage-drive chassis.

0133First connector <b>408</b> may be connected to a first side of board <b>412</b>, and second connector <b>410</b> may be connected to a second side of board <b>412</b> such that the connectors mirror each other. By mirroring each other, first connector <b>408</b> and second connector <b>410</b> may be directly lined up and on opposite sides of board <b>412</b>. In various embodiments, each pin of first convector <b>408</b> may directly line up with a corresponding pin of second connector <b>410</b> (i.e., the pins of first connector <b>408</b> may mirror the pins of second connecter <b>410</b>). This pin arrangement can enable controller <b>406</b> to be coupled with to storage drive <b>402</b> (e.g., as shown in <figref idref="DRAWINGS">FIG. 4B</figref>) such that second connector <b>410</b> acts as an extension of storage-drive connector <b>404</b>. By having first connector <b>408</b> and second connector <b>410</b> lined up, the combined storage drive and controller can be used in combination in a typical drive carrier that can be insert into a multi-storage-drive chassis.

0134In some embodiments, controller <b>406</b> may be manufactured with first connector <b>408</b> and/or second connector <b>410</b> affixed to board <b>412</b>. In other embodiments, controller <b>406</b> may be manufactured in a way that can enable a user to affix and/or remove first connector <b>408</b> and/or second connector <b>410</b> to/from board <b>412</b>, which is described in more detail below in conjunction with <figref idref="DRAWINGS">FIG. 4F</figref>.

0135Board <b>412</b> may also include memory, processor, wires, and other circuitry that may be operative to perform various actions and functionality of controller <b>406</b>, as described herein. For example, in some embodiments, controller <b>406</b> may perform or at least enable conversion of signals received through first connector <b>408</b> into an Ethernet compatible/supported signal that is output through second connector <b>410</b>. Similarly, controller <b>406</b> may perform or at least enable conversion of signals received through second connector <b>410</b> into a storage-drive compatible format/protocol that is output through first connector <b>408</b>.

0136In other embodiments, controller <b>406</b> may control accessibility of storage drive <b>402</b>, control power up or down of storage drive <b>402</b>, monitor various status performance or parameters (e.g., power consumption) of storage drive <b>402</b>, communicate with other controllers that are connected to other storage drives (e.g., to enable collaboration of controllers to schedule power up procedures of the storage drives; generate and compare drive profiles to identify potentially failing or malfunctioning drives; recovery of lost data, such as from a ‘dead’ storage drive), or the like.

0137In various embodiments, board <b>412</b> may have dimensions that are smaller than that of a lateral cross section or fit into the shadow of storage drive <b>402</b>, which is illustrated in <figref idref="DRAWINGS">FIG. 6</figref> (i.e., the controller fits into the lateral-cross-section shadow of the storage-drive form factor).

0138<figref idref="DRAWINGS">FIG. 4B</figref> illustrates connector <b>406</b> coupled to storage drive <b>402</b>. Example <b>400</b>B may be an embodiment of example <b>400</b>A of <figref idref="DRAWINGS">FIG. 4</figref>, but may illustrate controller <b>406</b> electrically coupled (or connected) to storage drive <b>402</b>. In various embodiments, when coupled together, a front (and back) of board <b>412</b> may be substantially parallel to a back of storage drive <b>402</b>. In some embodiments, the front of the board may refer to a side of the board with a majority of the circuitry and/or components. For example, the side with first connector <b>408</b> may be considered to be the front of board <b>412</b> of controller <b>406</b>.

0139In various embodiments, controller <b>406</b> may be removable and separable from storage drive <b>402</b>. In other embodiments, controller <b>406</b> may be fastened to storage drive <b>402</b>, such as, for example, by a screw, connector clamp, or other attachment mechanism. In at least one such embodiment, an additional brace may be employed to fasten controller <b>406</b> to storage drive <b>402</b>.

0140Since controller <b>406</b> may be a universal controller that can couple with a variety of different storage drives (e.g., different manufactures, types (e.g., HDD, SSD, or the like), form factors, connectors, or the like), controller <b>406</b> may be removed from a first storage drive and coupled to a second storage drive. The second storage drive may be a same or different model, made by a same or different manufacturer, have same or different capabilities/parameters, or the like, as the first storage drive, so long as both drives have storage-drive connectors (e.g., storage-drive connector <b>404</b>) that are compatible with the first connector of the controller (e.g., first connector <b>408</b>). However, embodiments are not so limited and in some embodiments, if the first storage drive and the second storage drive have different types of storage-drive connectors, then the first connector that is compatible with the first storage drive may be removed from the controller and a different first connector that is compatible with the second storage drive may be affixed to the controller. This universal interchangeability of the controller with different storage drives can enable a user to utilize most storage drives on the market (so long as the controller fits within the shadow of the storage drive form factor), without the need for extra hardware or software components built into the different storage drives or the chassis.

0141<figref idref="DRAWINGS">FIGS. 4C and 4D</figref> illustrate side perspective views of a storage drive and a controller in accordance with embodiments described herein. Example <b>400</b>C may illustrate an embodiment of controller <b>406</b> separate from storage drive <b>402</b>, similar to that of Example <b>400</b>A. And example <b>400</b>D may illustrate an embodiment of controller <b>406</b> coupled with storage drive <b>402</b>, similar to that of Example <b>400</b>B, but from a different perspective.

0142<figref idref="DRAWINGS">FIG. 4E</figref> illustrates a back perspective view of a storage drive and a controller in accordance with embodiments described herein. As described herein, controller <b>406</b> (e.g., board <b>412</b>) may have dimensions such that the perimeter of controller <b>406</b> (e.g., the perimeter of a front (and back) of board <b>412</b>) is within the lateral, cross-section perimeter of storage drive <b>402</b>, as illustrated. In some embodiments, a physical shape of the controller may be operative to fit adjacent to a correspondingly coupled storage drive connector and occupy less space than is bounded by peripheral edges of an end of a separate housing of a storage drive coupled to the storage drive connector (i.e., fitting into the form factor of the storage drive). By fitting into the form factor of the storage drive, the combined storage drive and controller to utilize a driver carrier for a typical multi-storage-drive chassis without modifications to the storage drive, drive carrier, and/or chassis.

0143<figref idref="DRAWINGS">FIG. 4F</figref> illustrates a top perspective view of a controller in accordance with embodiments described herein. As described above, controller <b>406</b> may be manufactured with first connector <b>408</b> and/or second connector <b>410</b> affixed to board <b>412</b>, or may be manufactured in a way that can enable a user to affix and/or remove (and replace) first connector <b>408</b> and/or second connector <b>410</b> to/from board <b>412</b>.

0144<figref idref="DRAWINGS">FIG. 4G</figref> illustrates a top perspective view of exemplary embodiment <b>400</b>G of wireless controller <b>420</b> in accordance with embodiments described herein. Wireless controller <b>420</b> may be manufactured with first connector <b>408</b> and wireless interface <b>422</b> affixed to board <b>412</b>, or may be manufactured in a way that can enable a user to affix and/or remove (and replace) first connector <b>408</b> and/or wireless interface <b>422</b> to/from board <b>412</b>. In various embodiments, different wireless interfaces may be installed on the board to accommodate various wireless communication protocols and/or antenna configurations.

0145In some embodiments, controller <b>406</b> and wireless controller <b>420</b> may be manufactured such that first connector <b>408</b>, second connector <b>410</b>, and/or wireless interface <b>422</b> are not removable from board <b>412</b>. While in other embodiments, either controller may be manufactured such that at least one of the connectors can be removed. For example, in at least one embodiment, first connector <b>408</b>, wireless interface <b>422</b>, and/or second connector <b>410</b> may be bonded (e.g., soldered) to board <b>412</b> in a way that they cannot be removed without damaging the connectors or the controller. In another embodiment, first connector <b>408</b>, wireless interface <b>422</b>, and/or second connector <b>410</b> may share mounting holes so that circuit/electrical component mounting screws can be used to affix the connectors to the board, while maintaining the correct position of the connectors (i.e., opposite each other). In at least one such embodiment, a user may be enabled to remove the mounting screws and the corresponding connector from the board; and in other embodiments, the mounting screws may not be removable. Various other mounting mechanisms may also be employed, such as clamps, friction fit, brackets, or the like.

0146In various embodiments, a user may be enabled to affix first connector <b>408</b>, wireless interface <b>422</b>, and/or second connector <b>410</b> to board <b>412</b>. For example, a user may be enabled to utilize component mounting screws, similar to what is described above, to affix and/or remove a connector from the board. These removable connectors may enable the board to be universal and compatible with different connectors, so that a user can mix and match connectors as necessary—depending on the storage-drive connector and backplane connector used.

0147In some embodiments, at least one of the connectors and/or wireless interface may be affixed to the board by a one-time-mounting mechanism. For example, a connector may include a mechanism such that when it is attached to the board (by either the manufacturer or a user), it cannot be removed from the board without destructive means. In at least one such embodiment, board <b>412</b> may include a mounting component (not illustrated) for affixing the connectors to the board. One such possible mounting mechanism may include a mounting component and connector that include opposing point and barb fasteners so that the points can pass next to each other upon coupling/affixing and the barbs engage each other to prevent removal.

0148It should be understood that these mounting-mechanism examples are for illustration purposes and should not be limiting. But rather, other mounting mechanisms may also be employed to mount, affix, or couple (either permanently or removably) first connector <b>408</b>, wireless interface <b>422</b>, and/or second connector <b>410</b> to board <b>412</b>.

0149<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> illustrate top perspective views of a storage-drive carrier, a storage drive, and a controller in accordance with embodiments described herein. Example <b>500</b>A may include storage-drive carrier <b>514</b> and storage drive <b>502</b>. Storage drive <b>502</b> may be an embodiment of storage drive <b>402</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>. As illustrated, storage-drive carrier <b>514</b> may be configured to hold/support storage drive <b>502</b>, so that storage drive <b>502</b> can be easily inserted and removed from a multi-storage-drive chassis. It should be understood that the shapes and dimensions of storage-drive carrier <b>514</b> and storage drive <b>502</b> are for illustration purposes; and other shapes and/or dimensions of these devices may be utilized with the various embodiments described herein. Example <b>500</b>B may be an embodiment of Example <b>500</b>A, but illustrates controller <b>506</b> coupled with storage drive <b>502</b> (as described herein). In various embodiments, the combined controller and storage drive may physically fit into the form factor of the storage drive associated with the drive carrier—which can enable the drive carrier to be properly inserted into a chassis without the need for modifications to the chassis, drive carrier, or storage drive itself (although in some embodiments, an additional bracket may be utilize to fasten the controller to the storage drive and/or the storage-drive carrier).

0150Although primarily described herein as embodiments employing a multi-storage-drive chassis, embodiments are not so limited. Rather, in some embodiments, a single drive (or single-drive chassis) may be employed. For example, various embodiments, storage-drive carrier <b>514</b> may be a self-contained device that can operate independent of a chassis. For example, storage-drive carrier <b>514</b> may include a power supply (e.g., a power cord) and a RJ45 jack (or other Ethernet compatible jack). In at least one such embodiment, controller <b>506</b> may be built into carrier <b>514</b>, but separate from storage drive <b>502</b>. By employing embodiments described herein, this configuration can allow an individual consumer to turn any typical storage drive (e.g., from an old household-desktop computer) into a network addressable storage drive, without the need of an additional server computer.

0151<figref idref="DRAWINGS">FIG. 6A</figref> illustrates an exploded perspective view of a multi-storage-drive chassis, a storage-drive carrier, a storage drive, and a controller in accordance with embodiments described herein. System <b>600</b> may include multi-storage-drive chassis <b>616</b> and storage-drive carrier <b>614</b>. Multi-storage drive chassis <b>616</b> may be an example of a JBOD or other chassis that can support a plurality of storage drives. In various embodiments, multi-storage-drive chassis <b>616</b> may include an Ethernet switch and a storage-drive-data bridge (e.g., a SAS bridge). In various embodiments, the Ethernet switch may provide access between controllers and/or from the chassis to other networks, and the storage-drive-data bridge may provide direct data access to a network computer without utilizing the Ethernet switch.

0152In some embodiments, storage-drive carrier <b>614</b> may be an embodiment of storage-drive carrier <b>514</b> of <figref idref="DRAWINGS">FIG. 5</figref>. Controller <b>606</b> may be embodiment of controller <b>406</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>. And storage drive <b>602</b> may be an embodiment of storage drive <b>402</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>. As illustrated, controller <b>606</b> may be coupled to a back of storage drive <b>602</b>. This combination of devices may be fastened to storage drive carrier <b>614</b>. The combined carrier <b>614</b>, drive <b>602</b>, and controller <b>606</b> may be inserted into slot <b>618</b> of chassis <b>616</b> in accordance with use instructions of chassis <b>616</b> for inserting a carrier into slot <b>618</b>.

0153<figref idref="DRAWINGS">FIG. 6B</figref> illustrates an exploded perspective view of a wireless multi-storage-drive chassis, a storage-drive carrier, a storage drive, and a controller in accordance with embodiments described herein. System <b>630</b> may include wireless multi-storage-drive chassis <b>630</b> and storage-drive carrier <b>624</b>. Wireless multi-storage drive chassis <b>630</b> may be an example of a JBOD or other chassis that can support a plurality of storage drives. In various embodiments, multi-storage-drive chassis <b>630</b> may include one or more radio adapters <b>632</b> and waveguide <b>634</b>. In various embodiments, the radio adapters may provide communication between wireless controllers and/or from the chassis to other networks.

0154In some embodiments, storage-drive carrier <b>624</b> may be an embodiment of storage-drive carrier <b>514</b> of <figref idref="DRAWINGS">FIG. 5</figref>. Wireless controller <b>626</b> may be embodiment of controller <b>420</b> of <figref idref="DRAWINGS">FIG. 4G</figref>. And storage drive <b>622</b> may be an embodiment of storage drive <b>402</b> of <figref idref="DRAWINGS">FIGS. 4A-4G</figref>. As illustrated, wireless controller <b>626</b> may be coupled to a back of storage drive <b>622</b>. This combination of devices may be fastened to storage drive carrier <b>624</b>. The combined carrier <b>624</b>, drive <b>622</b>, and wireless controller <b>626</b> may be inserted into slot <b>628</b> of chassis <b>630</b> in accordance with use instructions of chassis <b>630</b> for inserting a carrier into slot <b>628</b>. Once inserted, wireless controller <b>626</b> may wirelessly communicate via a channel in waveguide <b>634</b> with radio adapter <b>632</b> and other wireless controllers and/or radio adapters coupled to waveguide <b>634</b>.

0000Use Case Illustrations

0155<figref idref="DRAWINGS">FIG. 7</figref> illustrates an embodiment of a use case example of a controller circuit board with first and second connectors in accordance with embodiments described herein. Controller <b>700</b> may be an embodiment of controller <b>406</b> of <figref idref="DRAWINGS">FIG. 4</figref>. As illustrated, the front side of the controller board may include a processor DRAM, flash memory, SATA connector (i.e., first connector, such as first connector <b>408</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>) and various other circuit components, and the back side of the controller board may include a SAS connector (i.e., first connector, such as first connector <b>440</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>). The SATA connector may be the first connector for connecting the controller to a storage drive and the SAS connector may be the second connector for connecting to a backplane of a chassis. It should be understood that the SATA connector and the SAS connector be positioned so that a storage drive aligns with a backplane connector of a chassis.

0156<figref idref="DRAWINGS">FIG. 8</figref> illustrates an embodiment of a use case example of a system diagram of a controller in accordance with embodiments described herein. Controller <b>800</b> may be an embodiment of controller <b>300</b> of <figref idref="DRAWINGS">FIG. 3</figref>. As illustrated, controller <b>800</b> may include a processor, SAS connector (i.e., second connector), SATA connector (i.e., first connector), DRAM, flash memory, and other components. As described herein, the processor may control the power received through the SAS connector (i.e., provided by a backplane that the SAS connector is coupled with) and provided to the SATA connector (i.e., to the storage drive. This power control can enable the controller to determine when the storage drive (that is connected to the SATA connector) is turned on (e.g., relative to other storage drives in a chassis), change the power provided to a storage drive (e.g., if the storage drive's temperature climbs over a threshold value), or the like.

0157The processor may communicate (e.g., send and receive data) with remote devices (e.g., other controllers, network computers, or the like) through at least one of two SGMII connections (illustrated by SGMII0 and SGMII1) utilizing the SAS connector. The processor may also communicate (e.g., send and receive data) with a storage drive through the SATA data lines utilizing the SATA connector. In various embodiments, the processor may convert data received through the SATA connector in a SATA compliant protocol (i.e., storage drive protocol) into a differential pair SGMII compliant protocol (i.e., an Ethernet protocol) for output through the SAS connector. Similarly, the processor may convert data received through the SAS connector in a differential pair SGMII compliant protocol (i.e., an Ethernet protocol) into a SATA compliant protocol (i.e., storage drive protocol) for output through the SATA connector.

0158In at least one of various embodiments, the same pins used on the SATA connector to transfer data in the SATA compliant protocol may be the same pins used on the SAS connector to transfer data in an SGMII compliant protocol. <figref idref="DRAWINGS">FIG. 9</figref>, described below, illustrates an embodiment for utilizing differential pair signaling between the processor and SAS connector (i.e., in an Ethernet protocol), and between the processor and SATA connector (i.e., in a storage drive protocol).

0159Also illustrated are various data lines between the processor and memory, as well as various power lines and circuitry for obtaining the proper voltages for use by the processor and other circuitry.

0160<figref idref="DRAWINGS">FIG. 9</figref> illustrates an embodiment of a use case example diagram illustrating utilization of differential signal pairs in accordance with embodiments described herein. Controller <b>900</b> may be an embodiment of controller <b>800</b> of <figref idref="DRAWINGS">FIG. 8</figref>. For ease of illustration, only the processor, SAS connector (e.g., second connector <b>410</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>), and SATA connector (e.g., first connector <b>408</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>) are illustrated.

0161Briefly, the Rx receive pins of the SAS connector may be electrically coupled to a first set of Rx receive pins on the processor, and the Tx transmission pins of the SAS connector may be electrically coupled to a first set of Tx transmission pins on the processor. Additionally, the Rx receive pins of the SATA connector may be electrically couponed to a second set of Tx transmission pins on the processor, and the Tx transmission pins of the SATA connector may be electrically coupled to a second set of Rx receive pins on the processor.

0162In some embodiments, the data flow from the storage drive to the backplane (and then to another controller or network computer) may be as follows. Data may be received from the storage drive through the Tx transmission pins of the SATA connector. The processor may receive this data (or data signals) through the second set of Rx receive pins on the processor. The processor may perform any actions on the received data, such as convert the data from a SATA protocol into an Ethernet compliant protocol (e.g., differential Ethernet that utilizes IP packets). The processor may then output the converted data through the first set of Tx transmission pins on the processor. The converted data may be provided to the backplane through the Tx transmission pins of the SAS connector.

0163A component/interface on the backplane may then detect the presence of Ethernet frames on the Ethernet switch fabric and output them through an Ethernet port/interface to a remote network computer (or controller employed in a different chassis). In some embodiments, the controllers coupled to the backplane may communicate with each other by detecting the presence of the Ethernet frames on their interfaces with the Ethernet switch fabric of the chassis and inspecting them to determine if a response or action is needed. For example, a first controller may monitor the Ethernet frames on its interface (e.g., the backplane connector) with the Ethernet switch fabric of the chassis to determine if a second controller sent a message to the first controller.

0164In other embodiments, the data flow from the backplane to the storage drive may be as follows. In various embodiments, a component/Ethernet interface on the chassis may put Ethernet frames onto the Ethernet switch fabric interface for the controllers to detect, or another controller may put the Ethernet frames on the Ethernet switch fabric interface. Data may be received from the backplane through the Rx receive pins of the SAS connector. The processor may receive this data (or data signals) through the first set of Rx receive pins on the processor. The processor may perform any actions on the received data, such as convert the data from an Ethernet compliant protocol into a SATA compliant protocol for accessing the storage drive. The processor may then output the converted data through the second set of Tx transmission pins on the processor. The converted data may be provided to the storage drive through the Rx receive pins of the SATA connector. It should be noted that these data flows are for illustration purposes and other data paths may be employed depending on the connectors and/or processor utilized.

0000Illustrative Controller Functionality

0165<figref idref="DRAWINGS">FIG. 10</figref> illustrates a logical flow diagram generally showing an embodiment of a process for powering up a plurality of storage drives. Process <b>1000</b> may begin, after a start block, at block <b>1002</b>, where each of a plurality of controllers may be powered up. As described herein, each controller (e.g., controller <b>406</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>) may be coupled to a separate storage drive of a plurality of storage drives. In various embodiments, the plurality of storage drives may be employed in a single chassis or across multiple chassis.

0166In some embodiments, when the chassis is powered up, each controller may turn on. In various embodiments, the watts required by a plurality of controllers may be substantially less than the watts required to turn on all of their corresponding storage drives. And in some embodiments, the total controller wattage may be comparable to the wattage utilized by a centralized chassis controller.

0167Process <b>1000</b> may proceed to block <b>1004</b>, where—once powered up—each controller may separately and individually determine parameters of the corresponding storage drive that it is coupled with. For example, assume there is a first, second, third, and fourth controller coupled respectively to a first, second, third, and fourth storage drive. The first controller may determine the parameters of the first storage drive, the second controller may determine the parameters of the second storage drive, and so forth. The determined storage drive parameters may include, but are not limited to, a type of storage drive (e.g., a HDD, SSD, or the like), capabilities of the storage drive, how data is transmitted to the storage drive (e.g., a storage drive protocol), or the like.

0168In some embodiments, a plurality of controllers may coordinate with each other to determine the parameters of its correspondingly coupled storage drive. For example, in some embodiments, the controllers may take turns (e.g., each controller may perform actions separated from each other by a few millisecond (e.g., two milliseconds)) applying initial start-up power to its storage drive. By providing start-up power to a storage drive, the controller may communicate with the storage drive to obtain some of the parameters of the storage drive. These parameters may define the capabilities of the storage drive, power consumption profile of the storage drive, or the like.

0169A controller may determine these parameters based on the type of storage-drive connector (e.g., a SATA connector), a storage-drive identifier, previously stored power consumption data, other historical data regarding the storage drive (stored on the controller), or the like. In some embodiments, an administrator may provide the parameters of a storage drive to a correspondingly coupled controller.

0170Process <b>1000</b> may continue at block <b>1006</b>, where at least one controller may determine the capabilities of the chassis power supply. In some embodiments, each controller may determine the chassis-power-supply capabilities, but in other embodiments, one controller may determine the chassis-power-supply chassis and provide that information to other controllers.

0171In various embodiments, the capabilities of the chassis power supply may include, but is not limited to, one or more voltages supplied by the backplane of the chassis. In some other embodiments, the at least one controller may also determine other parameters of the chassis and/or backplane. These other parameters may include, for example, how many storage drives can the chassis hold, how many other chassis are being powered, what is the overall load on the power supply, an Ethernet protocol supported by the chassis (e.g., as described in more detail below in conjunction with <figref idref="DRAWINGS">FIG. 11</figref>), or the like.

0172Process <b>1000</b> may proceed next to block <b>1008</b>, where at least one power-up sequence may be determined for each storage drive in the chassis. In various embodiments, each controller may separately determine the power-up sequence(s) for its correspondingly coupled storage drive. In some embodiments, the power-up sequence(s) of a storage drive may be determined based on the parameters of that corresponding storage drive. Each separate power-up sequence can be optimized for different power-up scenarios and schedules, as described herein. In various embodiments, different power-up sequences may be for the different states of the storage drive, such as the initial power-up state, the initial read/write access state, or the like.

0173In some embodiments, one power-up sequence may be determined for a storage drive if only that storage drive is powered up or accessed, but not other storage drives. In at least one such embodiment, an example power-up sequence may be to fully power on the storage drive as soon as electrically possible (e.g., as soon as the controller receives an access request). In various embodiments, the power-up sequence of a storage drive may include an order for enabling various features of the storage drive (e.g., through the command set).

0174In other embodiments, one or more other power-up sequences may include ramping up the voltage provided to the storage drive over time, where each different sequence may include a different rate of ramping up the storage drive and/or variations in the ramp-up rate over time. For example, one sequence may be to power up the storage drive one volt per millisecond (i.e., increase the voltage to the storage drive by one volt per millisecond. In another example, another sequence may be to power up the storage drive to seven volts, wait two millisecond, and then increase the voltage to a full 12 volts. In various embodiments, the voltage supplied to the storage drive may be a step function (e.g., a ramp up and down may be trapezoidal in fashion), a linear increase, accelerating or decelerating increase, include multiple stages, include a wait time in between stages, or the like, or a combination thereof. It should be understood that these examples are for illustration and should not be construed as exhaustive or limiting.

0175In various embodiments, each of the plurality of controllers may communicate with each of the other controllers (e.g., via the Ethernet because each controller is IP addressable, as described herein) to determine and/or identify the other controllers of the plurality of controllers (as noted above, these controllers may be employed in a single chassis or in multiple chassis). In some embodiments, the controllers may send out various requests (e.g., via the backplane) to identify the other controllers.

0176Once identified, each controller can share their corresponding storage drive's power-up sequences and/or parameters with the other controllers. In some embodiments, the plurality of controllers may work together to determine a power-up schedule for at least a subset of the plurality of storage drives. In other embodiments, a single controller may determine the power-up schedule. In at least one such embodiment, the scheduling controller may receive the other storage drives' parameters from the other controllers (this may be performed locally to the chassis through the backplane without having to communicate to a master chassis controller or a remote master network computer). In various embodiments, the schedule may be for storage drives on a single chassis or for storage drive in a plurality of chassis.

0177In some embodiments, the schedule may be determined based on the parameters and/or the power-up sequence(s) (as previously determined by each separate controller) of each storage drive. In various embodiments, the schedule may be based on the scenario for powering-up one or more storage drives. Examples of different scenarios may include, but is not limited to, all storage drives powering up at once, one drive powering up, a subset of a plurality of storage drives powering up based on an access request, the states of the storage drives (e.g., an initial power-up state, idle state, initial read/write state, sustained read/write, or the like), or the like. The determined schedule can indicate—for each separate storage drive (or each separate storage drive of a subset of storage drives)—a power-up sequence to employ and a time for when to initiate that power-up sequence. In some embodiments, the schedule may be provided to each controller to instruct each corresponding controller when and what sequence to employ to power up its correspondingly coupled storage drive. In at least one such embodiment, a scheduling controller may inform each controller separately of a time (e.g., based on a system clock or a wait time) when it can power up its corresponding drive and a sequence particular to that drive (for that schedule) for how to power up the drive.

0178In various embodiments, the power-up sequence(s) and/or power-up schedule may be optimized to minimize the risks and/or issues created from spikes in power consumption as storage drives are powered on. In particular, mechanical drives (e.g., HDDs) may have an initial spike in power consumption when they turn on due to the electrical properties of powering up the motor to drive the disk. This power consumption can be compared to that of SSDs, which typically is more of a step function when the drive is initially powered up. Accordingly, in some embodiments, it may be beneficial to power up the HDDs prior to the SSDs. Similarly, it may be beneficial for some drives of one type (e.g., one or more) to power on before other drives (e.g., one or more) of the same type. This staggering of power ups can allow each power spike to subside before another storage drive is powered on, which can further reduce the issues that can arise from a spike in power consumption.

0179For example, assume a chassis has five storage drives, two HDD and three SSD (each of the same form factor—noting that different form factors may have different power consumption characteristics, which may change the power-up schedule (and/or sequence for each storage drive)). Based on the typical power consumption profile of the different storage drives, the schedule may indicate that the HDDs power up five milliseconds apart, followed by the SSD, each separated by two milliseconds, which may produce the power-up schedule HDD_1→five millisecond delay→HDD_2→five millisecond delay→SSD_1→two millisecond delay→SSD_2→two millisecond delay→SSD_3. In various embodiments, when each of these storage drive's is powered up according to the schedule, each may be powered up according to its own sequence (e.g., at different rates) as determined when the schedule is determined. It should be noted that this schedule and sequences is for illustration purposes and should not be limiting. Also, it should be noted that the power consumption profile of an individual drive may change over time, and in some embodiments, the corresponding controller may store the power consumption profile history so that this change can be tracked and employed to determine future power-up schedules and/or sequences.

0180In various embodiments, some schedules may indicate that a plurality of storage drives can power up at the same time (i.e., synchronous power ups). In some embodiments, the controllers may determine a number of storage drives that can be power up at the same time. In at least one of various embodiments, this number may be a predetermined number, such as determined by the chassis manufacturer, storage drive manufacturer, controller manufacturer, or the like. In other embodiments, the number of simultaneous drive power ups may be provided by a remove device, such as network computer <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In at least one embodiment, the number of simultaneous drive power ups may be dependent on an amount of total current that can be supplied by the chassis and/or the power source.

0181In various embodiments, the controllers may utilize the number of drives that can be simultaneously turned on to determine the order for turning on the drives. In some embodiments, the order may be based on a priority scheme (e.g., a drive being currently accesses (or repeatedly access) may be powered on before other drives, data drives may turn on before parity/backup drives, or the like), a physical location of each drive in the chassis, type of drive (as described above), randomly, or the like. Although embodiments are primarily described as controllers of a single chassis communicating with each other, embodiments are not so limited, but rather, controllers from a plurality of chassis may collectively communicate with each other to at least determine the power-up schedule for a plurality of storage drives in a plurality of chassis.

0182Other factors that may also impact the power-up schedule. For example, the controllers may detect that the backplane/chassis is not providing a constant power supply or at a lower level than desired (e.g., the power supply may be old and worn out, the facility housing the chassis may have fluctuating power, or the like). The controller may use this information to further stagger or alter the power-up sequence of the storage drives. In another example, the physical location of the storage drives in the chassis (or on another chassis) may be used to modify the power-up sequence. In one non-limiting example, the schedule may indicate that storage drives physically separated by a given number of other drives may be powered on at the same time, while storage drives physically next to each other may have an additional power up delay.

0183Since each controller can manage the power supplied to its corresponding storage drive, and since there is no need for the drives to be of a uniform type (or model, or from a same manufacturer), the controllers as a group can determine and employ a power-up schedule that can allow one or more of the storage drives to power up before other storage drives are powered up.

0184In any event, process <b>1000</b> may proceed to decision block <b>1010</b>, where a determination may be made whether an access request has been received by one or more controllers. If an access request has been received, then process <b>1000</b> may flow to block <b>1012</b>; otherwise, process <b>1000</b> may loop to decision block <b>1010</b> to wait for an access request.

0185At block <b>1012</b>, an optimal power-up sequence may be employed for each storage drive associated with the access request. In some embodiments, each controller that may be utilized to provide access to the data requests may separately employ the determined power-up sequence—in accordance with a power-up schedule—for its correspondingly coupled storage drive.

0186After block <b>1012</b>, process <b>1000</b> may return to a calling process to perform other actions. As described herein, once a controller is powered on, it may provide various diagnostics of its corresponding storage drive. Such diagnostics may include, but are not limited to, power consumption monitoring, temperature monitoring, or the like. Controllers may communicate this information to each other (to perform group-wide diagnostics and storage management) or to another network computer.

0187<figref idref="DRAWINGS">FIG. 11</figref> illustrates a logical flow diagram generally showing an embodiment of a process for managing a storage drive in accordance with embodiments described herein. Process <b>1100</b> may be employed by a controller (e.g., controller <b>406</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>) coupled to a storage drive and multi-storage-drive chassis, as described herein. In various embodiments, each separate controller may employ embodiments of process <b>1200</b>.

0188Process <b>1100</b> may being, after a start block, at block <b>1102</b>, where a protocol of the storage drive coupled to the first connector may be determined. In some embodiments, the controller may determine the storage drive protocol based on a type of storage-drive connector (or first connector <b>408</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>), type of storage drive, or the like.

0189Process <b>1100</b> may proceed to block <b>1104</b>, where an Ethernet protocol supported by the chassis backplane coupled to the second connector may be determined. In some embodiments, the controller may determine the Ethernet protocol based on a configuration of the controller's wireless interface. In other embodiments, the controller may determine the Ethernet protocol based on a type of a backplane connector (or second connector <b>410</b> of <figref idref="DRAWINGS">FIGS. 4A-4F</figref>). In some embodiments, the pin configuration of the backplane connector may determine the type of Ethernet protocol that can be supported by the chassis. In other embodiments, the connector may query the chassis to determine what its supported Ethernet protocol. In yet other embodiments, the Ethernet protocol may be hardcoded or pre-determined in the controller. In yet other embodiments, the Ethernet protocol may be determined by a radio adapter in communication with the wireless interface of the controller.

0190In various embodiments, the controller may self-configure by performing blocks <b>1102</b> and <b>1104</b> (in any order) upon power up.

0191Once configured, process <b>1100</b> may continue at decision block <b>1106</b>, where a determination may be made whether a communication has been received from the storage drive through the first connector. In various embodiments, this communication may be to access a resource(s) available over the wireless interface or the chassis backplane. In some embodiments, these resource(s) may be network computers (e.g., a client computer, administrator, master read/write coordinator, or the like), other controllers, other storage drives, or the like, or a combination thereof. In some embodiments, the received communications may be a response to a read request (e.g., read data), other information/data provided by the storage drive to the controller, or virtually any other type of communication that can be output from a storage drive. If a communication has been received through the first connector, then process <b>1100</b> may flow to block <b>1108</b>; otherwise, process <b>1100</b> may flow to decision block <b>1112</b>.

0192At block <b>1108</b>, the communication received from the storage drive may be converted from the determined storage drive protocol into the determined Ethernet protocol. In some embodiments, this conversion may include bundling the storage drive communication into the payload of one or more packets, or the like. In various embodiments, the controller may not convert the communication from the storage drive, but may simply forward it to a requesting resource/device.

0193Process <b>1100</b> may next proceed to block <b>1110</b>, where the converted communication may be forwarded (e.g., output) through the wireless interface or the second connector to the chassis backplane (i.e., the Ethernet switch fabric interface). In various embodiments, the chassis may intercept this converted communication and output it through an Ethernet port/interface to remote network computers. In other embodiments, other controllers may obtain/intercept the converted communication directly off the Ethernet switch fabric interface (and perform an action accordingly). In other embodiments, the radio adapter may wirelessly receive, from the controller's wireless interface, the converted communication which it forwards over an Ethernet interface to a network for one or more remote network computers.

0194After block <b>1110</b>, process <b>1100</b> may loop to decision block <b>1106</b> to wait for receipt of additional communications.

0195If, at decision block <b>1106</b>, a communication is not received through the first connector, process <b>1100</b> may flow from decision block <b>1106</b> to decision block <b>1112</b>, where a determination may be made whether a communication has been received through the wireless interface or the second connector over the chassis backplane. In various embodiments, the received communication may be from a resource available over the wireless interface or the chassis backplane that can communicate via an Ethernet protocol, including, but not limited to other controllers, network computers, chassis components, or the like.

0196In some embodiments, the received communication may be from another controller (e.g., storage drive parameters/power-up sequence(s) for determining a power-up schedule (e.g., as described in conjunction with <figref idref="DRAWINGS">FIG. 10</figref>); data reads/write requests; storage-drive monitoring information (e.g., as described in conjunction with <figref idref="DRAWINGS">FIG. 12</figref>); or the like). In other embodiments, this communication may be from a network computer (e.g., network computers <b>102</b>-<b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref>). In at least one such embodiment, the communication may include, but is not limited to, read/write requests, status checks, storage drive information (e.g., currently monitor performance information), or virtually any other type of communication that can be input to a storage drive, or the like. In yet other embodiments, this communication may be from a chassis component (e.g., a power-supply of the chassis). It should be noted that other types of communications may be received—through the second connector coupled to the chassis—from resources available over the chassis backplane. Also, it should be noted that other types of communications may be received—through the wireless interface—from resources available through the radio adapter, such as resources available through other radio adapters or controllers in the chassis. If a communication has been received through the second connector, then process <b>1100</b> may flow to block <b>1114</b>; otherwise, process <b>1100</b> may loop to decision block <b>1106</b> to wait for receipt of additional communications.

0197At block <b>1114</b>, the communication received from the chassis may be converted from the determined Ethernet protocol into the determined storage drive protocol. In some embodiments, this conversion may include removing packet information to obtain the payload. In some embodiments, the payload may include the read and/or write request from a remote network computer. In various embodiments, the controller may not convert the communication from the chassis, but may simply forward it to the storage drive.

0198Process <b>1100</b> may next proceed to block <b>1116</b>, where the converted communication may be provided (e.g., output) to storage drive through the second connector. In various embodiments, the converted communication may include instructions for accessing and/or writing to the storage drive, which can be provided to the storage drive through the second connector.

0199After block <b>1116</b>, process <b>1100</b> may loop to decision block <b>1106</b> to wait for receipt of additional communications.

0200<figref idref="DRAWINGS">FIG. 12</figref> illustrates a logical flow diagram generally showing an embodiment of a process for monitoring a storage drive in accordance with embodiments described herein. Process <b>1200</b> may be employed by a controller coupled to a storage drive and chassis, as described herein. In various embodiments, each separate controller may employ embodiments of process <b>1200</b>.

0201Process <b>1200</b> may begin, after a start block, at block <b>1202</b>, where the controller may monitor the performance of its correspondingly coupled storage drive. In some embodiments, the monitored performance may include, but is not limited to, power consumption, temperature, drive response latency (e.g., how long did it take to respond to a read request), or the like.

0202Process <b>1200</b> may proceed to block <b>1204</b>, where a profile of the drive performance may be determined. In some embodiments, this profile may include statistics, heuristics, trends, or the like, of the monitored performance.

0203Process <b>1200</b> may continue at decision block <b>1206</b>, where a determination may be made whether the storage drive is exhibiting characteristics of a failing drive based on its monitored profile. In some embodiments, a temperature above a predetermined threshold value for a given period of time may indicate that the drive is about to or prone to fail. In other embodiments, changes over time in power consumption behavior may indicate that the drive is exhibiting characteristics of a failing drive. In yet other embodiments, changes in latency can also indicate that a drive is failing. It should be understood that these performance measurements may be employed singularly, or in some combination thereof, to determine if the drive is exhibiting characteristics of a failing drive. In various embodiments, exhibiting characteristics of a failing drive may include irregularities with the drive, imminent failures, or the like.

0204If the drive is exhibiting characteristics of a failing drive, then process <b>1200</b> may flow to block <b>1212</b>; otherwise, process may flow to block <b>1208</b>. At block <b>1208</b>, the storage drive profile may be compared with other profiles of other storage drives. These other storage drives may be on a same chassis, different chassis, at a different data center facility in a different part of the country or world. In various embodiments, the profiles of similar storage drive types, models, manufacturers, or the like, or a combination thereof, may be compared. For example, in some embodiments, only profiles of a given storage drive type of a particular model may be compared. While in other embodiments, profiles of multiple different storage drive types of different models from different manufactures may be compared. However, embodiments are not so limited and other drive parameters may be employed to determine which profiles to compare.

0205Process <b>1200</b> may proceed next to decision block <b>1210</b>, where a determination may be made whether variations in the profile—compared to other profiles—exhibit characteristics of a failing drive. In some embodiments, a temperature of a given drive may not be above a threshold value (e.g., as determined at decision block <b>1206</b>), but when compared to other storage drives, it is continuously running at a higher temperature. This higher comparative temperature may indicate that the storage drive may be failing (or at least performing at a lower standard that the other storage drives), especially if the storage drive had less data accesses than the other storage drives (because the more data accesses, the more likely an increase in temperature). However, embodiments are not so limited, and other variations in the profile compared to other profiles may indicate that the drive is failing.

0206Similarly, storage drive profile comparisons across multiple chassis can indicate if a chassis may be experiencing issues. For example, if the voltage provided to each drive in a chassis is below other chassis, then the chassis may be experiencing issues with its power supply. It should be noted that these examples are not to be construed as limiting, and other storage drive profile comparisons may be made to determine if a storage drive and/or chassis has reduced performance, is having issues, or is potentially failing.

0207If variations in the profile indicate that the drive may be failing, then process <b>1200</b> may flow to block <b>1212</b>; otherwise, process <b>1200</b> may loop to block <b>1202</b> to continue to monitor the storage drive performance.

0208At block <b>1212</b>, a backup of the potentially failing storage drive may be requested. In some embodiments, this request may be provided to an administrator of the storage drive (and/or chassis). In other embodiments, the controller may request a backup and may coordinate with other controllers to back up the data onto other storage drives. In other embodiments, a chassis may include a spare storage drive (and controller, as described herein) to which the data from the failing drive may be automatically copied (without intervention by the administrator).

0209Process <b>1200</b> may continue at block <b>1214</b>, where an alert may be provided to the storage drive administrator. In various embodiments, this alert may notified the administrator of the potentially failing drive. In some embodiments, the administrator may be enabled to determine what to do with the failing drive. For example, the administrator may be provided all the profile performance characteristics and/or comparisons with other profiles, and may make the decision as to whether drive really is failing. In some embodiments, the administrator may provide the controller with instructions on how to proceed with the potentially failing drive (e.g., continue to monitor, copy the storage data to a spare drive or other drives in the chassis (or another chassis), or the like).

0210In some embodiments, the controller may instruct other controllers to halt future data writes to the potentially failing storage drive. In various embodiments, the controller may notify other controllers in the chassis (or associated with other chassis) of the potential problem with its storage drive, and the other controllers may modify writing procedures to divert future write requests away from the failing drive.

0211In various embodiments, blocks <b>1212</b> and/or <b>1214</b> may be optional and may not be performed. For example, in some embodiments, the controller may notify the administrator, but may not take any pre-failure steps (e.g., automatically backup of the potentially failing drive). In other embodiments, only the potentially failing storage drive may be backed up, but no other actions. However, embodiments are not so limited and other actions may be taken on the potentially failing drive.

0212After block <b>1214</b>, process <b>1200</b> may look to block <b>1202</b> to continue to monitor the storage drive's performance.

0213It will be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by computer program instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The computer program instructions may be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified in the flowchart block or blocks. The computer program instructions may also cause at least some of the operational steps shown in the blocks of the flowchart to be performed in parallel. Moreover, some of the steps may also be performed across more than one processor, such as might arise in a multi-processor computer system. In addition, one or more blocks or combinations of blocks in the flowchart illustration may also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention.

0214Accordingly, blocks of the flowchart illustration support combinations of means for performing the specified actions, combinations of steps for performing the specified actions and program instruction means for performing the specified actions. It will also be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be implemented by special purpose hardware based systems, which perform the specified actions or steps, or combinations of special purpose hardware and computer instructions.

0215The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.