Managed reliability of data storage

Systems and methods are provided herein that can facilitate the managed reliability of data storage, including management of device remanufacturing and masking from an operating system a failure or predicted failure of a device running on a computer or a networked cluster of computers having access to the device. The systems and methods may facilitate removal of a device by coordinating among computers or controllers in a network cluster the logical removal of a device. At a later time, a coordinated logical re-introduction of the device to the systems or computers from which the device was logically removed can be performed. This can be accomplished via a virtualization system that may include a device function driver (DFD), a device virtualization bus driver (DVBD), and a device management service (DMS).

BACKGROUND

This application relates to systems, devices, and methods for managed reliability of data storage devices and systems.

DETAILED DESCRIPTION

In some embodiments, the systems and methods may facilitate the managed reliability of data storage, including management of device remanufacturing and masking from an operating system a failure or predicted failure of a device running on a computer or a networked cluster of computers having access to the device. If there are indications that a device is failing or about to fail, the systems may respond to operating system requests for the health status of the device by returning an indication that no failure is predicted. If deemed appropriate, the device may be taken offline functionally for servicing without interrupting the operating system, or without having to power down the computer or networked cluster of computers having access to the device.

In other embodiments, the systems and methods may facilitate removal of a device by coordinating among computers or controllers in a network cluster the logical removal of a device, such as for remanufacturing. At a later time, such as when remanufacturing is complete, the system may coordinate the logical re-introduction of the device to the systems or computers from which the device was logically removed. Further, once a device has been logically removed from a system, it could also be physically removed if desired.

In some embodiments, the systems and methods for managed reliability of data storage can include a device function driver (DFD), a device virtualization bus driver (DVBD), and a device management service (DMS) for facilitating the management of devices in a system. Detailed embodiments and variations of systems and methods utilizing a DFD, DVBD, and a DMS are described below with respect toFIGS. 1 through 13.

FIGS. 1 and 2each show a diagram of an illustrative embodiment of an environment in which aspects of a system for managed reliability may be implemented, generally designated100and200, respectively. In some embodiments, the environments100,200may comprise a plurality of nodes104,108that form a networked cluster. The nodes104,108may communicate with each other via a network connection112. For example, the network connection112may be a multiple Gigabit Ethernet connection.

Each node104,108may be a computing device connectable to a network or to another computing device. The computing device could be a server, a desktop computer, a laptop computer, a tablet computer, a phone, another electronic device, a communications device, any other structure having a processing capability, or any combination thereof. Each node104,108may have a unique network address, such as a Data Link Control (DLC) address or a Media Access Control (MAC) address.

In some embodiments, each node104,108may comprise a server having at least one computer processor236as well as a computer memory218that can include volatile random access memory (RAM′) and some form of non-volatile computer memory. The computer memory could include electrically erasable programmable read-only memory (also known as ‘EEPROM’), volatile solid state memory (such as Dynamic Random Access Memory, also known as “DRAM”), non-volatile solid state memory (such as ‘Flash’ memory), a hard disk drive, an optical disk drive, or any combination thereof. The computer memory218may be connected through a system bus to the processor236and to other system components, such as a storage controller240.

Each node104,108may further comprise an operating system (OS)214, a device function driver (DFD)202, a device virtualization bus driver (DVBD)206, and a device management service (DMS)210. The OS214, DFD202, DVBD206, and DMS210may comprise computer program instructions stored in computer memory218and processed by central processing unit (CPU)236to perform the methods and functions described in embodiments herein.

The environments100,200may further comprise an array of data storage devices (DSDs)116. The DSDs116may include any device that can transmit or receive data over an interface120. For example, one or more of the DSDs116may be any device capable of data storage, such as a hard drive or any other data storage device. The array of DSDs116may be various types and varied capacities of data storage devices, or the DSDs116could include data storage devices that are all of the same type and storage capacity.

Each of the DSDs116may be connected to one or more nodes104,108. The nodes104,108may share read access, write access, or any combination thereof to one or more of the DSDs116. For example, in some embodiments, the array of DSDs116may comprise 24 data storage devices. Any combination of the DSDs116may be read from or written to by any combination of the nodes104,108via an interface120. Stated another way, the nodes104,108may transmit data to or receive data from one or more of the DSDs116across the interface120. The interface120may transfer data between the nodes104,108and the DSDs116.

The interface120can be any type of interface120capable of transmitting data between devices. The interface120may be in the form of a computer bus interface standard or other interface protocol for transferring data between systems or components, such as USB 2.0, USB 3.0, IEEE 1394, SATA, SAS, Fiber Channel, or Ethernet. Other embodiments of the interface120may include wireless interfaces, such as IEEE 802.11 protocols, Bluetooth, infrared, cellular, or satellite mobile telecommunication protocols. Hardware necessary to implement the interface120may be added to the nodes104,108and the DSDs116.

In one or more embodiments, the interface120may comprise a bridged interface (not shown) between the nodes104,108and the DSDs116. The bridged interface may comprise a node interface (not shown), an interface bridge (not shown), and a device interface (not shown). The nodes104,108may transmit data to or receive data from the DSDs116across the bridged interface.

In a particular embodiment, data may be transferred between the nodes104,108and the DSDs116by way of the node interface, the interface bridge, and the device interface. The node interface and the device interface can represent any means of transmitting data between devices. The node interface and the device interface may be a computer bus interface standard or other interface protocol for transferring data between systems or components, such as USB 2.0, USB 3.0, IEEE 1394, Compact Flash, SATA, eSATA, PATA, SCSI, SAS, Fiber Channel, PS/2, serial cable, HDMI, or Ethernet. Other embodiments of the interfaces may include wireless interfaces408,416, such as IEEE 802.11 protocols, Bluetooth, infrared, cellular, or satellite mobile telecommunication protocols. Hardware necessary to implement the node interface or the device interface may be added to the nodes104,108and the DSDs116.

The interface bridge may comprise any method of connecting the node interface and the device interface, such as a male-to-male adapter; an interface protocol adapter such as USB-to-SATA, a device such as a server, a router, a personal computer, a drive capable of integration into a daisy-chain network arrangement; or any type of network. The interface bridge may function as a wireless-to-wired interface protocol adapter, so that one of the node interface or the device interface may be a wired interface protocol, and the other may be a wireless interface protocol.

A storage controller240may be able to communicate with any or all of the DSDs116via an interface120and may handle the movement of data as well as other functions such as RAID. Moreover, the storage controller240of a first node104may be capable of managing the movement of data with respect to any or all of the DSDs116via the interface120of a second node108, and vice-versa.

In some embodiments, each of the DSDs116may only have one node104,108serving as the DSD's116management owner at any given time. The management owner may be responsible for monitoring the health of the DSD116, and for initiating remanufacturing if the DSD's116health is degraded.

In one particular embodiment, the nodes104,108and the array of DSDs116may be disposed within a single, shared enclosure124. One or more other devices132may have access to the nodes104,108via a network connection128. Devices132may not know to which node104or108it is connecting at any given time. Nodes104and108can be formed as a cluster and node104can be a backup for node108, and vise-versa. Each device132may be a computer, such as a server, a desktop computer, a laptop computer, a tablet computer, another electronic device, a communications device, or the like, or any combination thereof.

FIGS. 3 and 4will be discussed in conjunction.FIG. 3shows a diagram of an illustrative embodiment of virtualization system device objects that can be used for managed reliability of data storage, generally designated300.FIG. 4shows a diagram of an illustrative embodiment of virtualization system communications that can be used for managed reliability of data storage, generally designated400.

The virtualization system400may comprise a device function driver (DFD)202, a device virtualization bus driver (DVBD)206, and a device management service (DMS)210. In various embodiments, the DFD202, DVBD206, and DMS210may be software modules comprising computer program code. Referring also toFIG. 2, computer program code for the software modules of some embodiments may reside in the node104, storage controller240and in the DSDs116. Various functions in implementing embodiments of the virtualization system400may be resident in different portions of the environment200or may be downloaded to various components as needed. Such downloading may comprise reading computer program code from memory of a storage controller240or DSD116, storing the computer program code, and executing the computer program code.

The DFD202may be designed for use with a specific operating system214. When one or more of the DSDs116is connected to a first node104via an interface120, the hardware discovery process (e.g., a process implemented by a system configured in accordance with the Plug and Play standard) may cause the DFD202to be loaded. In some embodiments, the DFD202may be loaded in response to the DSD(s)116being physically connected to the node104and enumerated with a hardware ID. The DFD202may create a functional device object (FDO)314on each physical device object (PDO) (not shown) representing a physical DSD116.

When the current node (first node104) is the management owner of one or more of the DSDs116, the DFD202may be responsible for monitoring the health of the DSD and managing remanufacturing operations on the DSD if deemed necessary.

The DFD202may also be responsible for “spoofing” the DSD's storage capacity to implement trivial overprovisioning. Overprovisioning is the practice of providing more storage capacity in the physical DSD than is visible to the operating system214, so that limited amounts of remanufacturing do not result in a loss net storage capacity. Trivial overprovisioning is overprovisioning implemented on a per-DSD basis by hiding a pre-defined percentage of a DSD's storage capacity from the operating system214. For example, an implementation of trivial overprovisioning of 25% means that a DSD with an initial storage capacity of 100 GB would be reported to the operating system214by the DFD202as having a storage capacity of 75 GB.

The DVBD206may be a root enumerated bus driver that communicates with the DFD202and creates a physical device object (PDO)320for each FDO314created by the DFD202. The PDO320may represent a virtual DSD324to the operating system. Each virtual DSD324may be reported to the operating system as a generic DSD type320and may be subsequently controlled by the operating system's corresponding DSD class driver. The DVBD206may be responsible for deleting the PDO320representing the virtual DSD324when the associated physical DSD undergoes remanufacturing. Similarly, when remanufacturing is complete, the DVBD206may be responsible for re-creating the PDO320representing the virtual DSD324to the operating system214.

The DMS210may be a user-mode service that is responsible for tracking how physical DSDs116and their corresponding virtual DSDs324are configured into one or more abstract DSD groups340via the operating system's214logical volume manager (LVM). The DMS210may be responsible for logically removing individual virtual DSDs324from the abstract DSD group(s)340before the corresponding physical DSDs116undergo remanufacturing. Each virtual DSD324may be represented by one or more unnamed partition PDOs332comprising a resource pool336at the LVM. A virtual storage port driver328may allow for selection of one or more of the unnamed partition PDOs332from the resource pool336to be grouped into an abstract DSD group340. Thus, an abstract DSD group340may be one or more virtual DSDs324(and therefore one or more physical DSDs116) represented as a single virtual DSD to a user or administrator of the OS214.

The DMS210may communicate with the DFD202to gather information and learn when a DSD owned by the current node (first node104) will undergo remanufacturing. The DMS210of a management owner first node104may further communicate with the DMS210of a non-management owner second node108(and any other nodes) in a cluster to inform the second node108of the intention to remanufacture the DSD or to inform the second node108of the completion of remanufacturing operations on the DSD. Similarly, the DMS210of a non-management owner first node104may communicate with the DMS210of a management owner second node108such that the non-management owner first node104may become aware of the intention to remanufacture the DSD or become aware of the completion of remanufacturing operations on the DSD.

In a particular embodiment, the DFD202of the first node104may determine that one of the DSDs116requires remanufacturing, at404. Determining whether the DSD requires remanufacturing may be based on certain characteristics exhibited by the DSD indicating that the DSD is either failing or predicted to fail.

The DFD202of the first node104may communicate its intent to remanufacture the DSD to the DMS210of the first node104, at408. Communication between the DFD202of the first node104and the DMS210of the first node104may be carried out using an input and output control (IOCTL) interface. In some embodiments, the IOCTL interface may allow the DMS210to send a control message. The control message may include a control code representing an operation for the DFD202to perform. For example, the DMS210may send a control message asking the DFD202to return information about the corresponding DSD.

In response to being informed of the DFD's202intent to remanufacture the DSD, the DMS210of the first node104may logically remove the DSD from its abstract DSD group340, at412. The DMS210of the first node104may further broadcast the intent to remove the DSD to the DMS210of the second node108, at416. The second node108may be using the DSD as a non-management owner in its abstract DSD group340. Although the illustrative embodiment shown byFIG. 4is described herein as comprising two nodes (first node104and second node108), other embodiments may comprise a cluster having more than two nodes. The various nodes and their respective DMS210may communicate with each other via a network connection426.

The DMS210of the second node108, upon being informed of the intent to remanufacture the DSD, may in turn inform the DFD202of the second node108of the intent to remanufacture the DSD. It is to be understood that, although communication among the DFD202, DVBD206, DMS210, DSD(s)116, OS214, and software applications or modules of computer program code may be described herein as certain information provided by the sender to the recipient, the communication may include any type of information that would achieve the desired outcome. For example, by relaying via various interfaces the intent to remanufacture the DSD, the desired outcome is for appropriate measures to be taken to prepare for the remanufacturing. Therefore, this series of communication may comprise, for example, a request for the DFD202of the second node108to disable its device interface with the DVBD206of the second node108.

The DFD202of the second node108may notify the DVBD206of the second node108of the interface departure, at624. In response, the DVBD206of the second node108may remove the PDO320representing the virtual DSD324associated with the physical DSD, thereby logically removing the virtual DSD324.

The DFD202of the second node108may communicate with the DMS210of the second node108to indicate success of the logical removal of the DSD, at428. The DMS210of the second node108use one or more application programming interfaces (APIs) to logically remove the virtual DSD320from its abstract DSD group340.

The DMS210of the second node108may communicate with the DMS210of the first node104to indicate successful removal of the DSD from the second node108, at432. Upon receiving this information from the DMS210of the second node108, the DMS210of the first node104may relay to the DFD202of the first node104of an indication that the DFD202may thereafter properly cause the virtual DSD320to be logically removed from the first node104. The DFD202of the first node104may disable the device interface with the DVBD206. The DFD202of the first node104notifies the DVBD206of the first node104of the interface departure, at440. In response, the DVBD206of the first node104may logically remove the PDO320representing the virtual DSD324associated with the physical DSD.

The DFD202may then initiate remanufacturing operations on the DSD, at444. The DFD202may enable its interface with the DVBD206when remanufacturing is complete, thereby commencing a reversal of the actions described above in order to logically re-introduce the virtual DSD324to the abstract DSD group340of the first node104and the abstract DSD group340of the second node108.

FIGS. 5 and 6show a flowchart of an illustrative embodiment of a method for managed reliability of data storage, generally designated500. The flowchart represents steps performed by a loaded device function driver (DFD) in accordance with some embodiments.

Nodes and interfaces between a node and a DSD have been described above with reference toFIGS. 1-4. In some embodiments, one or more of the data storage devices (DSDs)116may be connected to a node104via an interface120. A storage port miniport driver (not shown) and/or a storage port driver (not shown) may enumerate the DSD with a certain manufacturer hardware ID via an operating system214hardware discovery, or Plug and Play, process. The DFD202may be loaded via the operating system214hardware discovery process in response to a storage port miniport driver and/or a storage port driver enumerating the DSD and in response to the port driver creating a physical device object (PDO) (not shown) representing the physical DSD.

The DFD202may create a functional device object (FDO)314for each port driver-reported PDO having a certain hardware ID, at504. Referring also toFIG. 10, the DFD202may register and enable a device interface1004for each FDO314that it creates. The device interface1004may be used to notify the device virtualization bus driver (DVBD)206of the arrival of a new DSD. The device interface1004may also be used to inform the DVBD206that a DSD is pending the initiation of remanufacturing or has completed remanufacturing. To inform the DVBD206that a DSD is intended to be remanufactured, the DFD202may disable the device interface1004. Conversely, the DFD202may inform the DVBD206that a DSD has completed remanufacturing by enabling the device interface1004.

In some embodiments, the method500may further involve the DFD202deciding whether the current node104is the management owner of the DSD, at508. The DFD202may make this management owner determination for each FDO314created. Each DSD may only have one node104serving as the DSD's management owner at any given time.

To determine whether the current node104is the management owner of the DSD, the DFD202may intercept the completion status of periodic persistent reserve out operations (hereinafter referred to as “reserve request”) sent by operating system214software to the each DSD that is under the current node's104control. Management ownership status be acquired by a node104based on the first success-indicating response (i.e., a successful reserve request) intercepted by the DFD202. Ownership of the DSD may change, and the DFD202may track the results of subsequent reserve requests. In some embodiments, any time a reserve request is successful, the current node104may become management owner of the DSD116to which the reserve request was directed.

The DFD202may further provide a standard upper-edge device input and output control (IOCTL) interface1006used to receive input and output (I/O) operations destined to a DSD. The DVBD206may use this interface1006to forward to the DFD202I/O operations (via IOCTL messages) from the operating system's214corresponding device class driver(s). In turn, the DFD202may provide a lower-edge IOCTL interface1010to forward to the underlying PDO (representing the physical DSD) certain I/O operations the DFD202receives from the DVBD206.

Of the current node104is determined to be the management owner of the DSD, then the DFD202may monitor the health of the DSD, at512. The management owner of the DSD may also be responsible for ensuring that the operating system214only perceives the DSD as healthy. By intercepting the results of health status-inquiring IOCTL requests periodically sent by the operating system's214corresponding device class driver(s) to the underlying storage port miniport driver and/or the storage port driver, the DFD202may determine whether failure is predicted, at516. For example, the device class driver(s) may periodically send an IOCTL request message to the underlying storage port miniport driver and/or the storage port driver inquiring whether the DSD is predicted to fail.

The DFD202may acquire and monitor one or more DSD parameters. DSD202parameters may be acquired in a periodic or continuous manner. Monitoring of parameters may include comparison with optimal usage models or other device parameters and thresholds and may include calculation of rates, trends and other representations of system and component activity and condition. Monitoring may employ elements of Self Monitoring and Reporting Technology (SMART). SMART is an industry-adopted standardized specification for failure warnings, which are based on monitoring for excessive internal drive errors, such as bit-read errors and track-seek errors. SMART employs a failure-warning algorithm running in a processor that checks whether error rates exceed a threshold value and if such condition exists, a warning is sent to the node's104CPU236. While SMART is a reactive approach to possible drive failure, aspects of SMART may be employed in connection with parameters acquired as part of the monitoring the health of the DSD.

In some embodiments, the acquired DSD parameters may comprise at least one parameter selected from the following group: bit error rate, number of uncorrectable errors, number of grown-in errors, number of bad sectors, number of spare sectors used, number of failed reads, temperature, humidity, other environmental conditions, amplitude of a read signal, quality of a read signal, percent of total capacity used, number of reads, and number of writes. However, any parameter suitable evaluating the health of the DSD may be acquired. The parameter(s) may be monitored per sector, track, zone, or DSD, or any combination thereof.

A current health state value may be calculated based on the acquired DSD parameter(s). The current health state value may be compared to a failure-indicating state value representing a threshold value above which the DSD is predicted to fail. Calculation of the failure-indicating state value may also be based on the acquired DSD parameter(s). The failure-indicating state value may be predetermined, or it may be determined on-the-fly. In one particular embodiment, the current health state value may be compared with the failure-indicating state value. Failure may be predicted if the current health state value exceeds the failure-indicating state value.

If failure is predicted and the current node104is management owner of the DSD, then the DFD202may note the predicted failure but return to the operating system214an indication that no failure is predicted, at520, thereby ensuring that the operating system214only sees the DSD as healthy. In some examples the DFD202may note the predicted failure via a registry entry for each DSD, which can have an entry for its status indexed by each DSD's serial number. If failure is not predicted, then the DFD202may continue to monitor the health of the DSD if the current node104is the DSD's management owner.

The periodic health status-inquiring IOCTL request messages may return a health indicator to the operating system214. The health indicator may indicate that the DSD to which the health status-inquiring IOCTL request message was directed is either healthy (i.e., no failure is predicted) or unhealthy (i.e., failure is predicted). The health indicator may indicate a failure is predicted when the current health state value exceeds the failure-indicating state value. The DFD202may intercept a first status of the health indicator that indicates a failure is predicted, and modify the first status to reflect a second status of the health indicator to indicate that no failure is predicted. The second status may be reported to the operating system214. In this manner, the DFD202may mask from the operating system214the predicted failure of the DSD.

The DFD202of the management owner may also be responsible for determining whether to initiate remanufacturing operations if the DSD's health is degraded (i.e., failure is predicted), at524. A service state value may also be determined based on the acquired DSD parameter(s). The service state value may represent a threshold value above which the DSD is determined to require remanufacturing (servicing). The current state value may be compared to the service state value. In one particular embodiment, remanufacturing may be initiated in response to the current health state value exceeding service state value.

If the DFD202determines that remanufacturing should be initiated on the DSD, then the DFD202may inform the DMS210of its intent to remanufacture the DSD, at528. To communicate with the DMS210, the DFD202may provide a device input and output control (IOCTL) interface1008. In some embodiments, the IOCTL interface1008may allow the DMS210to send an IOCTL request message including a control code to the DFD202. The control code may represent an operation for the DFD202to perform. For example, the DMS210may send a control code asking the DFD202to return information about the corresponding DSD.

In one particular embodiment, an IOCTL code used for communicating with the DFD202may take the form of IOCTL_[DFD NAME]_MESSAGE, or a similar variation, such as IOCTL_DFD_MESSAGE. Each IOCTL code may be used to send information from the caller to the DFD202and to allow the DFD202to provide information, or notifications, to the caller.

The IOCTL_DFD_MESSAGE control code may use the same message buffer for both input and output.FIG. 11shows a diagram of an illustrative embodiment of a message1100. The message1100may include fields providing information regarding the version1104and the size1108of the message1100. This may be done to allow DFD202not to have to create a message itself. The fields InCommand1116and OutCommand1124each may encode a command. Incommand1116may be the command being sent from user-mode to the DFD202. OutCommand1124may be the command being sent from the DFD202to the user-mode requestor. Each command may have an associated sequence number1112,1120, which may be used by the requestor to match a command with an associated response. The DMS210may set the InSequence1112, and the DFD202may preserve the InSequence1112set by the DMS210. The DFD202may set the OutSequence1120.

On some embodiments, the IOCTL_DFD_MESSAGE control code may be designed to work as part of an “inverted call” system between the DMS210and the DFD202. The DMS210may initially send an IOCTL_DFD_MESSAGE to the DFD202with an InCommand1116field set to a command indicating “No Operation” (e.g., [DFD NAME]_COMMAND_NOP) or the like. The DFD202may hold the “No Operation” command until either: (1) the DFD202receives a new IOCTL_DFD_MESSAGE, or (2) the DFD202wishes to provide information to the DMS210.

In the event the DFD202receives a new IOCTL_DFD_MESSAGE, the DFD202may set the OutCommand field1124to DFD_COMMAND_NOP and set the Argument field1132to a parameter indicating a success of the command (e.g., STATUS_SUCCESS).

In the event the DFD202wishes to provide a notification to the DMS210, the DFD202may set the OutCommand field1124to the corresponding command indicating the subject matter of the notification. For example, the DFD202may wish to inform the DMS210that a DSD owned by the current node104is scheduled to begin remanufacturing. The DFD202may fill the OutCommand field1124with DFD_COMMAND_REMANUFACTURE, set the OutSequence field1120to a unique value, and set the Argument field1132to a parameter indicating success of the command (e.g., STATUS_SUCCESS).

Referring back toFIGS. 3-6, the device function driver (DFD)202may inform the device management service (DMS)210of the DFD's202intent to initiate remanufacturing of the data storage device (DSD). The DFD202may wait for confirmation from the DMS210that remanufacturing may begin, at532. The DMS210of the first node104may communicate to the DMS210of the second node108the intent to initiate remanufacturing so that that the second node108may take measures to ensure that the DSD may be remanufactured while remaining physically connected to the nodes104,108.

Upon receiving confirmation from the DMS210that the DFD202may proceed to initiate remanufacturing, the DFD202may note in the registry that the first node104is the owner of the DSD undergoing remanufacturing, at536. This registry information may be used in the event a reboot occurs while remanufacturing is in progress. To inform the device virtualization bus driver (DVBD)206that a DSD is pending the initiation of remanufacturing, the DFD202may disable the device interface1004, at540. In response to the device interface1004being disabled, the DVBD206may delete the associated PDO320, thereby logically removing the associated virtual DSD324from the node104. The DFD202may then initiate remanufacturing on the DSD, at544.

In some embodiments, the DFD202may monitor the progress of the DSD during the remanufacturing process, at548. When remanufacturing is complete, the DFD202may remove the entry it previously created in the registry, at552.

The DFD202may inform the DMS210that the DSD has completed remanufacturing and/or is available for use, at556. Further, the DFD202may enable the device interface1004, triggering the DVBD206to logically re-introduce the associated virtual DSD324to the node104.

Returning to step508, in the event the DFD202determines that the current node104is not the management owner of the DSD, the DFD202may determine whether a DSD owned by any other node is expected to start remanufacturing, at564. The DFD202may make this determination based on communication with the DMS210via the device input and output control (IOCTL) interface1008. The DMS210may be in communication with other nodes' respective DMS210via a status interface1034.

If any other node is expected to start remanufacturing, the DFD202may disable the device interface1004, at568. In response to the device interface1004being disabled, the DVBD206may delete the associated PDO320, thereby logically removing the associated virtual DSD324from the current node104.

The DFD202may wait for the DMS210to confirm that remanufacturing of a DSD owned by another node has ended, at572. Upon being informed of completion of remanufacturing, the DFD202may enable the device interface1004, triggering the DVBD206to logically re-introduce the associated virtual DSD324to the node104.

FIG. 7shows a flowchart of an illustrative embodiment of a method700for managed reliability of data storage. The flowchart represents steps performed by a loaded device function driver (DFD)202in accordance with some embodiments.

In some embodiments, one or more of the data storage devices (DSDs)116may be physically connected to a node104via an interface120. A storage port miniport driver (not shown) and/or a storage port driver (not shown) may enumerate the DSD with a certain manufacturer's hardware ID via an operating system214hardware discovery, or Plug and Play, process. The DFD202may be loaded via the operating system214hardware discovery process in response to a storage port miniport driver and/or a storage port driver enumerating a DSD and in response to the port driver creating a physical device object (PDO) (not shown) representing the physical DSD.

The DFD202may create a functional device object (FDO)314for each port-reported PDO having a certain hardware ID, at704. Further at step704, the DFD202may register and enable a device interface1004for each FDO314that it creates.

The DFD202may also provide a standard upper-edge device input and output control (IOCTL) interface1004. The upper-edge IOCTL interface1004may be used to receive IOCTL operations from an OS214destined to a DSD. The DVBD206may use this interface1004to forward to the DFD202I/O operations from the operating system's214corresponding device class driver(s). In turn, the DFD202may provide a lower-edge IOCTL interface1204to forward to the underlying PDO I/O operations it receives from the DVBD206.

In some embodiments, the DFD202may, for each DSD, determine whether an operation is querying the capacity of the DSD, at708. If so, the DFD202may intercept the query, at712, and change the DSD's reported storage capacity to reflect the target storage capacity of the DSD, at716. For example, the DSD may initially have a storage capacity of 100 GB, but, with the implementation of trivial overprovisioning of 25%, the target storage capacity may be 75 GB. Remanufacturing of the DSD may decrease the DSD's storage capacity, and therefore a remanufactured DSD may have an actual capacity less than 100 GB, but not necessarily 75 GB. Regardless of the current actual capacity of the DSD, the DFD202may intercept and return queries for the storage capacity of the DSD with 75 GB, the target capacity in this illustrative example.

FIG. 8is a flowchart of an illustrative embodiment of a method800for managed reliability of data storage. The flowchart represents steps performed by a loaded device virtualization bus driver (DVBD)206in accordance with some embodiments.

The DVBD206may be a root-enumerated bus driver that instantiates physical device objects (PDOs)320, each of which may represent a single virtual DSD324. During initialization the DVBD206may register for device interface1004change notifications from the device function driver (DFD)202, at804.

If the DVBD206is notified of a device interface1004change, at808, the DVBD206may determine whether the device interface1004change indicates a device interface1004arrival (i.e., the device interface1004is enabled) or a device interface1004departure (i.e., the device interface1004is disabled), at812. If notified of a device interface1004arrival, then the DVBD206may retrieve and store a reference pointing to the functional device object (FDO)314corresponding to the enabled device interface1004, at816. The DVBD206may further create a PDO320that represents a virtual data storage device (virtual DSD)324, at820. The virtual DSD324may correspond to the physical data storage device (DSD) on which the FDO314was created. The DVBD206may associate the PDO320with a hardware ID and a compatible ID, at824.

If the DVBD206is notified of a device interface1004departure, then the DVBD206may release the reference pointing to the FDO314, at828. The DVBD206may further delete the PDO320representing the virtual DSD324, at832, and inform the operating system's214hardware discovery manager of the DSD's departure, at836.

FIG. 9is a flowchart of an illustrative embodiment of a method900for managed reliability of data storage. The flowchart represents steps performed by a loaded device management service (DMS)210in accordance with some embodiments. The DMS210may be a user-mode service that is initiated during a node's104boot process.

Referring also toFIG. 10, the DMS210may publish an information interface1036and communicate with the DFD202via input and output control (IOCTL) messages to gather information about the node's104DSD configuration, and discover and report the initiation of DSD remanufacturing.

In some embodiments, the DMS210may communicate with the DFD202to identify the physical DSDs116connected to the node104, at step904. The DMS210may correlate the identified DSDs116with the node's104virtual DSDs324, at908. Further, the DMS210may use one or more application programming interfaces (APIs) to obtain DSD resource pool332and/or abstract DSD group336information. For example, the DMS210may use the operating system's214failover cluster APIs and the operating system's214abstract DSD group332APIs to obtain the DSD resource pool332and/or the abstract DSD group336information. The DMS210may also correlate the physical DSDs116with the obtained DSD resource pool332and/or abstract DSD group336information, at912.

The method900may further involve the DMS210maintaining in the registry a mapping of abstract DSD groups336to virtual DSDs324and/or physical DSDs116, at916. The mapping may be used to re-establish the membership of the abstract DSD group(s)336if the node104is rebooted during remanufacturing of a DSD. The mapping information may be made available to other local applications via an interface provided by a service contract, such as, for example, a Windows Communication Foundation (WCF) service contract.

The DMS210may be informed by DFD202of the intent to remanufacture a DSD, at920. When so informed, the DMS210may remove the DSD from its associated abstract DSD group(s)336, at924. The DMS210may further communicate the intent to remanufacture the DSD to the DMS210instance(s) running on one or more other nodes in the cluster (not shown), if any, at928. The DMS210instance(s) running on one or more other nodes may confirm receipt of the notification of intent to remanufacture the DSD. Upon receiving this confirmation from the one or more other nodes, the DMS210may notify the DFD202of the confirmation, at932.

The DMS210may be informed of the intent to remanufacture a DSD by a DMS210instance running on another node in the cluster (not shown), at936. When so informed, the DMS210may inform the DFD202that the DSD should be logically removed, at940. The DFD202may subsequently disable the device interface1004for the DSD, causing the DVBD206to delete the virtual DSD324corresponding to the physical DSD.

When informed, by either the DFD202or a DMS210instance running on another node in the cluster, that remanufacturing of a DSD is complete, the DMS210of the current node104may virtually re-introduce the DSD to its appropriate abstract DSD group336.

The method steps described above with reference to each ofFIGS. 4-9are presented in a specific order. However, it should be apparent to one of skill in the art that additional steps may be included, or that some steps may be excluded or performed in a different order than that depicted in each ofFIGS. 4-9.

In accordance with various embodiments, the methods described herein may be implemented as one or more software programs or modules running on a computer processor or controller. In accordance with other embodiments, the methods described herein may be implemented as one or more software programs running on a computing device, such as a personal computer or server that is using one or more data storage devices, such as a disc drive. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays, and other hardware devices can likewise be constructed to implement the methods described herein. Further, the methods and systems described herein may be implemented as a computer readable storage medium, such as a storage device or memory, including instructions that when executed by a processor, cause the processor to perform the methods.

The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown.