Implementing multiple raid level configurations in a data storage device

Embodiments of the present invention provide systems, methods, and computer program products for implementing multiple raid level configurations in a computer storage device. In one embodiment, performance or resiliency of application data being executed to a single computer storage device can be prioritized. Embodiment of the present invention provide systems, methods, and computer program products for a recovery operation, responsive to determining to prioritize performance of application data being executed to the single computer storage device.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of data storage devices, and more particularly to implementing multiple redundant array of disks (RAID) level configurations in a single data storage device.

Computer storage devices, such as hard disk drives (HDDs), and flash storage devices are used for storing and retrieving digital information. HDDs are often designed and implemented with platters and are paired with magnetic heads for storing and retrieving digital information. Multiple HDDs can be utilized in a data storage device environment and can implement various RAID level configurations. Flash storage devices are often designed and implemented with partitions, configured to store and retrieve digital information. Different RAID level configurations may correlate to different magnitudes of resiliency and performance of the data storage device environment. Furthermore, different RAID level configurations may also provide varying resiliency, availability, performance, and capacity for data stored in the data storage devices. Often, RAID level configurations implement parity, an error protection scheme, which is used to provide fault tolerance in a given set of data. Typically, a RAID level configuration prioritizing higher resiliency requires additional data storage devices to effectively distribute digital information and parity information among those data storage devices.

SUMMARY

Embodiments of the present invention provide systems, methods, and program products for implementing multiple raid level configurations in a computer storage device. In one embodiment of the present invention, a method is provided comprising: receiving an application transaction to be executed to a first portion of a computer storage device, wherein the first portion of the computer storage device is configured to store application data; generating at least one Redundant Array of Independent Disks (RAID) transaction associated with the application transaction to be executed to a second portion of the computer storage device, wherein the second portion of the computer storage device is configured to store parity data of the application data; storing the application transaction to be executed to the first portion of the computer storage device in a first buffer; responsive to determining that a storage capacity of a second buffer configured to store RAID transactions reaches a threshold, determining whether to prioritize execution of the application transaction to the first portion of the computer storage device or to prioritize execution of RAID transactions to the second portion of the computer storage device; responsive to determining to prioritize execution of the application transaction to the first portion of the computer storage device, performing a write-through operation for the application transaction to the first portion of the computer storage device; and responsive to determining to prioritize execution of RAID transactions to the second portion of the computer storage device, executing at least one RAID transaction stored in the second buffer to the second portion of the computer storage device.

DETAILED DESCRIPTION

Embodiments of the present invention provide methods, systems, and computer program products to manage one or more redundant array of independent disks (RAID) level configurations in a single storage device. Embodiments of the present invention provide methods, systems, and computer program products to help prioritize performance of the single storage device or resiliency of the single storage device. In this manner, as discussed in greater detail later in this specification, embodiments of the present invention can be used to determine a manner in which to process application data and parity data of the application data, responsive to determining whether to prioritize performance or resiliency of the single storage device.

FIG. 1is a functional block diagram of computing environment100in accordance with an embodiment of the present invention. Computing environment100includes computer system102and hard disk drive (HDD)110. Computer system102may be a desktop computer, laptop computer, specialized computer server, or any other computer system known in the art. In this embodiment, computer system102includes applications104and hard disk drive (HDD)110. In general, computer system102is representative of any electronic device, or combination of electronic devices, capable of executing machine-readable program instructions, as described in greater detail with regard toFIG. 6.

HDD110is a computer storage device for computer system102. In this embodiment, HDD110includes disk controller120, input buffer130, RAID buffer140, sector table150, and HDD platters160. HDD110and components therein store application data and parity data of the application data. Furthermore, HDD110is configured to support a plurality of RAID level configurations. For example, a RAID5level configuration may be implemented by HDD110. In this instance, RAID transactions are executed to a plurality of HDD platters160(i.e., distributed parity). In another example, multiple RAID level configurations may be implemented by HDD110(i.e., a RAID2and a RAID5configuration), such that at least one of HDD platters160contains one or more executed RAID transactions (e.g., dedicated parity, distributed parity, double distributed parity, byte-level striping, block-level striping, etc.).

Applications104generate application data to be written to HDD platters160. Furthermore, applications104use application data. In one embodiment, the application data used by applications104can be read from HDD platters160. In this embodiment, applications104transmit application data to and from HDD110and components therein.

Disk controller120manages processing of application data and parity data of the application data. In this embodiment, disk controller120contains RAID logic122to help manage execution of the one or more application transactions and one or more associated RAID transactions to HDD platters160. The term “transaction,” as used herein, refers to either an executable read or write operation to facilitate processing of data (e.g., application data, parity data, etc.). For example, processing application data involves executing one or more read/write operations that may be represented by one or more application transactions. Furthermore, disk controller120may generate parity data for the application data. Similarly, processing parity data involves executing one or more read/write operations that may be represented by one or more RAID transactions. In certain embodiments, disk controller120and components therein are configured to determine an operational status of HDD110(i.e., whether HDD110is under a large computational load, based, at least in part, on a number of unexecuted transactions stored in input buffer130and RAID buffer140). In another embodiment, disk controller120and components therein are configured to determine an operational status of computer storage devices other than HDD110, such as a flash storage device.

Input buffer130contains a plurality of entries storing incoming and outgoing application data, represented by one or more application transactions. In this embodiment, the one or more application transactions stored in input buffer130, are based, at least in part on, processing application data from applications104. For example, disk controller120may process the application data into one or more application transactions and store the one or more application transactions into input buffer130.

RAID buffer140contains a plurality of entries, wherein each entry may store incoming and outgoing parity data, represented by one or more RAID transactions. In an embodiment, disk controller120may generate parity data and store the one or more RAID transactions in RAID buffer140until a condition is met, as described in greater detail with regard toFIGS. 2-4. Furthermore, prior to the one or more RAID transactions executed to HDD platters160, disk controller120interacts with RAID buffer140. The one or more RAID transactions in RAID buffer140are executed to HDD platters160to ensure parity data is synchronized and resiliency is maintained in HDD110.

Sector table150is used to identify one or more RAID transactions to be executed to HDD platters160during a recovery operation. For example, a recovery operation may occur subsequent to performing a write-through operation (i.e., executing one or more application transactions without executing one or more associated RAID transactions to HDD platters160). In this instance, sector table150is referenced during the recovery operation to execute one or more RAID transactions to HDD platters160, as described in greater detail with regard toFIGS. 5 and 6. In general, sector table150can be implemented with any suitable storage architecture known in the art, such as a relational database, an object-oriented database, and/or one or more tables.

HDD platters160contain information in the form of binary units. In this embodiment, read/write heads are provided for each one of HDD platters160. Furthermore, application and/or RAID transactions can be executed to each one of HDD platters160independently. In general, HDD platters160are magnetic disks capable of storing machine-readable program instructions, as described in greater detail with regard toFIG. 6.

It should be understood that, for illustrative purposes,FIG. 1does not show other computer systems and elements which may be present when implementing embodiments of the present invention. For example, whileFIG. 1shows a number of HDD platters160. In other embodiments, a greater or lesser number of HDD platters160may be implemented by data storage environment100.

Similarly, in other embodiments, computing environment100can be implemented with different types of computer storage devices other than HDD110, including flash storage devices. In one embodiment, application and/or RAID transactions can be executed to one or more portions (e.g., partitions) of a flash storage device. For example, the flash storage device may be configured such that RAID logic122executes application transactions to a first partition of one or more partitions of the flash storage device, and RAID logic122may execute RAID transactions to a second partition of one or more partitions of the flash storage device. Furthermore, computing environment100may implement a table during a write-through and recovery operation for the flash storage device, other than sector table150. For example, the table may identify one or more partitions, or one or more logical block addresses (LBA), of application transactions executed to the one or more portions of the flash storage device during a write-through operation, as described in greater detail with regard toFIG. 4. In general, the table can be implemented with any suitable storage architecture known in the art, such as a relational database, an object-oriented database, and/or one or more tables.

FIG. 2is a flowchart200illustrating operational steps for processing RAID transactions, in accordance with an embodiment of the present invention. In this embodiment, disk controller120implements RAID logic122to help manage execution of application transactions and RAID transactions to HDD platters160. In one embodiment, RAID logic122may manage execution of application transactions and RAID transactions to one or more portions of a computer storage device, other than HDD110. For example, disk controller120may implement RAID logic122to help manage execution of application transactions and RAID transactions to one or more partitions of a flash storage device.

In step202, RAID logic122processes a request to execute one or more application transactions. In this embodiment, applications104transmit application data and a request to process the application data to HDD110and components therein. Furthermore, the application data may be represented by one or more application transactions stored in input buffer130. Accordingly, RAID logic122processes the request to execute the one or more application transactions, and generates one or more RAID transactions (i.e., the one or more RAID transactions represent parity data of the application data).

In step204, RAID logic122determines whether sufficient storage in RAID buffer140is available. In this embodiment, RAID logic122analyzes entries in RAID buffer140to determine whether sufficient storage is available. In another embodiment, RAID logic122may determine that sufficient storage in RAID buffer140is available, such that the one or more generated RAID transactions can be stored in RAID buffer140. Furthermore, RAID logic122may determine that a number of available entries in RAID buffer140are less than the number of entries required to store the one or more generated RAID transactions. In general, RAID logic122analyzes RAID buffer140to determine whether sufficient storage is available in RAID buffer140.

If in step204, RAID logic122determines that sufficient storage is available in RAID buffer140, then in step206, RAID logic122determines whether to prioritize performance of HDD110. In this embodiment, performance of HDD110is represented by a rate at which application data is processed in HDD110. For example, if the rate at which application data is written and/or read is decreased, then the performance of HDD110is decreased. Conversely, if the rate at which application data is written and/or read is increased, then the performance of HDD110is increased. In another embodiment, a user specification may specify whether to increase performance of HDD110.

If in step204RAID logic122determines that RAID buffer140does not have sufficient storage available, then in step205, RAID logic122stores the one or more RAID transactions in RAID buffer140. Subsequently, an operation may be performed to execute the one or more RAID transactions stored in RAID buffer140responsive to a condition (e.g., a schedule, low computational demand of HDD110, etc.).

If in step206, RAID logic122determines to prioritize performance of HDD110, then in step208, RAID logic122performs a write-through operation for the one or more application transactions. In this embodiment, the write-through operation involves executing the one or more application transactions to HDD platters160. Furthermore, RAID logic122executes the one or more application transactions to HDD platters160prior to processing any of the one or more RAID transactions. Stated differently, RAID logic122prioritizes executing application transactions to HDD platters160, in response to determining to prioritize performance of HDD110. In another embodiment, the write-through operation may involve executing one or more application transactions to one or more portions of a computer storage device, other than HDD110. For example, the write-through operation may involve executing the one or more the one or more application transactions to one or more partitions of a flash storage device.

If in step206, RAID logic122determines to not prioritize performance of HDD110, then in step210, RAID logic122executes one or more RAID transactions. In this embodiment, RAID logic122executes one or more RAID transactions to make sufficient storage available in RAID buffer140, based on certain criteria. For example, the criteria may indicate to make sufficient storage available in RAID buffer140for the one or more RAID transactions generated in step202, by executing older RAID transactions stored in RAID buffer140. In another example, the criteria may specify an amount of available storage on RAID buffer140necessary to proceed with subsequent operations. In certain embodiments, RAID logic122may provide an indication to throttle (i.e., suspends) incoming application data, as explained in greater detail with regard toFIG. 3.

In step212, RAID logic122stores the one or more RAID transactions associated with the request (i.e., generated in step202) in RAID buffer140. In this embodiment, the one or more RAID transactions are stored in RAID buffer140until RAID logic122executes the one or more RAID transactions to HDD platters160, in accordance with a configured RAID scheme (e.g., RAID1, RAID2, RAID3, etc. one or more of HDD platters160using one or more of the respective read/write heads) and a set of conditions (e.g., a schedule, low computational demand of HDD110, etc.). As previously discussed, one or more RAID transactions may be executed to one or more portions of a computer storage device, other than HDD110. For example, the one or more RAID transactions stored in RAID buffer140may be executed by RAID logic122to one or more partitions of a flash storage device.

FIG. 3is a flowchart300illustrating operational steps for executing one or more RAID transactions, in accordance with an embodiment of the present invention. For example, the operational steps of flowchart300can be performed at step210of flowchart200. In this embodiment, RAID buffer140does not have sufficient memory available, and RAID logic122determines not to prioritize performance of HDD110. Instead, RAID logic122prioritizes resiliency of HDD platters160by prioritizing execution of RAID transactions to HDD platters160. Accordingly, RAID logic122is implemented to effectively empty RAID buffer140, such that all of the one or more RAID transactions stored in RAID buffer140are executed to HDD platters160. In another embodiment, RAID logic122may be implemented, such that all of the one or more RAID transactions stored in RAID buffer140are executed to one or more portions of a computer storage device, other than HDD110. For example, the one or more RAID transactions stored in RAID buffer140may be executed by RAID logic122to one or more partitions of a flash storage device.

In step302, RAID logic122throttles (i.e., suspends) processing of incoming application data. In this embodiment, RAID logic122throttles processing of incoming application data to prevent input buffer130from overflowing. Accordingly, RAID logic122penalizes performance of HDD110because one or more application transactions are not prioritized for execution to HDD platters160. In certain embodiments, RAID logic122will not throttle processing of incoming application data if RAID buffer140is empty (i.e., each of the one or more RAID transactions are executed to HDD platters160). In other embodiments, RAID logic122may penalize performance of a computer storage device, other than HDD110, because one or more application transactions are not prioritized for execution to one or more portions of the computer storage device. For example, a flash storage device's performance can be penalized by RAID logic122, such that the one or more application transactions are not prioritized for execution one or more partitions of the flash storage device.

In step304, RAID logic122executes the one or more RAID transactions. In this embodiment, RAID logic122is implemented to determine a manner to execute the one or more RAID transactions. For example, tagged command queuing (TCQ) or native command queuing (NCQ) may be a technology utilized by RAID logic122and components therein to optimize scheduling for executing the one or more RAID transactions.

In step306, RAID logic122executes the one or more application transactions. In this embodiment, RAID logic122signals to continue processing new application data, so long that RAID buffer140does not overflow from storing one or more RAID transactions that are based on parity data of the new application data. As previously discussed, RAID logic122processes application data into one or more application transactions. Accordingly, RAID logic122executes the one or more application transactions to HDD platters160. In another embodiment, RAID logic122may be implemented, such that the one or more application transactions are executed to one or more portions of a computer storage device, other than HDD110. For example, the one or more application transactions may be executed by RAID logic122to one or more partitions of a flash storage device.

FIG. 4is a flowchart400illustrating operational steps for performing a write-through operation for one or more application transactions, in accordance with an embodiment of the present invention. For example, the operational steps of flowchart400can be performed at step208of flowchart200. In this embodiment, RAID buffer140does not have sufficient storage available, and RAID logic122determines to prioritize performance of HDD110by prioritizing execution of application transactions to HDD platters160. Accordingly, RAID logic122is implemented to effectively process application data, such that all of the one or more application transactions are executed to HDD platters160. In another embodiment, RAID logic122may be implemented to execute one or more application transactions to one or more portions of a computer storage device, other than HDD110. For example, the one or more application transactions may be executed by RAID logic122to one or more partitions of a flash storage device.

In step402, RAID logic122executes the one or more application transactions. In this embodiment, RAID logic122executes the one or more application transactions to HDD platters160. Furthermore, RAID logic122and components therein may utilize TCQ or NCQ technologies to ensure efficient execution scheduling for the one or more application transactions. As previously discussed, RAID logic122may execute the one or more application transactions to one or more portions (e.g., partitions) of a type of computer storage device different from HDD110, such as a flash storage device.

In step404, RAID logic122records information in sector table150for one or more sectors of HDD platters160involved in the executed application transactions of step402. In this embodiment, the information recorded in sector table150indicates the location of application data for the executed application transactions and allows RAID logic122to later (i.e., during recovery) execute RAID transactions associated with the previously executed one or more application transactions to achieve parity of that data. For example, during a write through, two application transactions may be executed to one or more sectors of HDD platters160without executing associated RAID transactions. In this instance, RAID logic122records in sector table150location information about application data in the sectors involved in the application transactions such that the associated RAID transactions can later be executed to achieve parity of that application data. In step406, RAID logic122determines whether a load peak has finished. In one embodiment, the load peak is finished when RAID logic122determines that there as an idle time during processing of application data. For example, RAID logic122may determine that a load peak has finished when all of the one or more application transactions are executed to HDD platters160. Furthermore, RAID logic122may determine that a load peak has finished when a recovery operation can initiate without impacting (i.e., decreasing) performance of HDD110. In one embodiment, a computer storage device different from HDD110may implement a table, other than sector table150, to record information for one or more portions of the computer storage device involved in the executed application transactions of step402. For example, a flash storage device may implement a table to record information for one or more partitions of the flash storage device involved in the executed application transactions. Furthermore, in this instance, the table may record one or more LBAs to identify the one or more partitions of the flash storage device involved in the executed application transactions.

If in step406RAID logic122determines that the load peak has finished, then in step408RAID logic122performs a recovery operation. In this embodiment, the recovery operation is used to synchronize the data of the one or more sectors recorded in sector table150with parity data. In another embodiment, the recovery operation may be used to synchronize one or more portions recorded in a table, other than sector table150, with parity data. For example, performing the recovery operation may synchronize the data of one or more partitions recorded in a table with parity data. Accordingly, RAID logic122performs the recovery operation by executing the one or more associated RAID transactions, as described in greater detail with regard toFIG. 5.

If in step406logic122determines that the load peak has not finished, then in step402, RAID logic122continues to execute one or more application transactions, as previously discussed. Furthermore, RAID logic122may continue to process application data (i.e., by executing the one or more application transactions to HDD platters160) until RAID logic122determines that the load peak has finished (step406).

FIG. 5is a flowchart500illustrating operational steps for performing a recovery operation, in accordance with an embodiment of the present invention. For example, the operational steps of flowchart500can be performed at step408of flowchart400. In this embodiment, RAID logic122initiates the recovery operation responsive to determining that a load peak has finished (step404ofFIG. 4). Furthermore, performing the recovery operation synchronizes parity data of application data to HDD110by executing one or more RAID transactions associated with application transactions that were previously written through to HDD platters160. Accordingly, by performing the recovery operation, parity data of the application data is synchronized in HDD110and resiliency of the application data in HDD110is maintained. In one embodiment, parity data of the application data may be synchronized in a computer storage device, other than HDD110, and resiliency of the application data in the computer storage device is maintained by performing the recovery operation. For example, resiliency application data executed to of one or more partitions of a flash storage device may be maintained by performing the recovery operation.

In step502, RAID logic122initiates the recovery operation. In this embodiment, RAID logic122is implemented to determine a manner to initiate the recovery operation. For example, RAID logic122may determine to interleave the recovery operation (i.e., execution of one or more RAID transactions indicated by sector table150) with execution of one or more application transactions, such that performance of HDD110is not impacted (i.e., decreased). In another example, RAID logic122may determine to interleave the recovery operation with execution of one or more application transactions, such that performance of another computer storage device, such as a flash storage device, is not impacted.

In step504, RAID logic122executes one or more RAID transactions associated with the one or more application transactions. In this embodiment, the one or more application transactions were previously executed to HDD platters160during a write-through operation. In one embodiment, the one or more application transactions may have been previously executed to one or more partitions of a flash storage device during a write-through operation.

In step506, RAID logic122determines whether sector table150is empty, indicating that all associated RAID transactions have been performed. In one embodiment, RAID logic122may determine whether a table, other than sector table150, as implemented by a computer storage device, such as a flash storage device, is empty.

If in step506RAID logic122determines that the entries in sector table150are not empty, then in step504, RAID logic122executes one or more RAID transactions associated with the one or more application transactions. Accordingly, the recovery operation will be performed as long as the number of entries in sector table150is not zero. In one embodiment, the recovery operation may be performed, such that a number of entries in a table, other than sector table150, as implemented by another type of computer storage device (e.g., a flash storage device), is not zero.

If in step506RAID logic122determines that the entries in sector table150are empty, then in step508, RAID logic122indicates that the recovery operation is complete. In this embodiment, RAID logic122signals computing environment100and components therein to continue processing application data. In one embodiment, RAID logic122may determine that entries in a table, other than sector table150, as implemented by another type of computer storage device (e.g., a flash storage device), are empty.

FIG. 6is a block diagram of internal and external components of a computer system600, which is representative of the computer systems ofFIG. 1, in accordance with an embodiment of the present invention. It should be appreciated thatFIG. 6provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. In general, the components illustrated inFIG. 6are representative of any electronic device capable of executing machine-readable program instructions. Examples of computer systems, environments, and/or configurations that may be represented by the components illustrated inFIG. 6include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, laptop computer systems, tablet computer systems, cellular telephones (e.g., smart phones), multiprocessor systems, microprocessor-based systems, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

Computer system600includes communications fabric602, which provides for communications between one or more processors604, memory606, persistent storage608, communications unit612, and one or more input/output (I/O) interfaces614. Communications fabric602can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric602can be implemented with one or more buses.

Memory606and persistent storage608are computer-readable storage media. In this embodiment, memory606includes random access memory (RAM)616and cache memory618. In general, memory606can include any suitable volatile or non-volatile computer-readable storage media. Software is stored in persistent storage608for execution and/or access by one or more of the respective processors604via one or more memories of memory606.

Persistent storage608may include, for example, a plurality of magnetic hard disk drives. Alternatively, or in addition to magnetic hard disk drives, persistent storage608can include one or more solid state hard drives, semiconductor storage devices, read-only memories (ROM), erasable programmable read-only memories (EPROM), flash memories, or any other computer-readable storage media that is capable of storing program instructions or digital information.

The media used by persistent storage608can also be removable. For example, a removable hard drive can be used for persistent storage608. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer-readable storage medium that is also part of persistent storage608.

Communications unit612provides for communications with other computer systems or devices via a network. In this exemplary embodiment, communications unit612includes network adapters or interfaces such as a TCP/IP adapter cards, wireless Wi-Fi interface cards, or 3G or 4G wireless interface cards or other wired or wireless communication links. The network can comprise, for example, copper wires, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. Software and data used to practice embodiments of the present invention can be downloaded through communications unit612(e.g., via the Internet, a local area network or other wide area network). From communications unit612, the software and data can be loaded onto persistent storage608.

One or more I/O interfaces614allow for input and output of data with other devices that may be connected to computer system600. For example, I/O interface614can provide a connection to one or more external devices620, such as a keyboard, computer mouse, touch screen, virtual keyboard, touch pad, pointing device, or other human interface devices. External devices620can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. I/O interface614also connects to display622.

Display622provides a mechanism to display data to a user and can be, for example, a computer monitor. Display622can also be an incorporated display and may function as a touch screen, such as a built-in display of a tablet computer.