System and method to keep parity consistent in an array of solid state drives when data blocks are de-allocated

A method comprises sending a first command to a solid state drive (SSD), the first command indicating that the SSD can de-allocate a first plurality of logical block addresses (LBAs), and calculating first parity data for a redundant array of independent disks (RAID) array that includes the SSD in response to receiving a first reply from the SSD indicating that the first LBAs were de-allocated by the SSD. The first parity data is calculated based upon the first LBAs including all logical zeros.

FIELD OF THE DISCLOSURE

This disclosure relates generally to information handling systems, and relates more particularly to keeping parity consistent in an array of solid stated drives when data blocks are de-allocated.

BACKGROUND

A solid-state drive (SSD) is a data storage device that uses integrated circuit memory such as a flash memory to provides persistent data storage. A redundant array of independent disks (RAID) array combines multiple data storage devices into a logical unit to provide improved performance and redundancy. A RAID array can include SSDs.

DETAILED DESCRIPTION OF DRAWINGS

In a particular embodiment, information handling system100includes a host adapter110, a RAID controller120, and a RAID array130. RAID array130includes SSDs132,134, and136. Host adapter110represents a data storage adapter of information handling system100, and operates to receive data storage and retrieval requests from the information handling system, and to provide the requests to RAID controller120. As such, host adapter110is configured to receive requests from information handling system100in a protocol associated with the information handling system, and to provide the requests to RAID controller120in a protocol associated with the RAID controller. For example, host adapter110can include a front-end interface such as a Peripheral Component Interconnect (PCI) interface, a PCI-X interface, a PCI-Express (PCIe) interface, or another front-end interface, and a back-end interface such as an AT attach (ATA) interface, a Parallel-ATA (PATA) interface, a Serial-ATA (SATA) interface, a Small Computer System Interface (SCSI) interface, a Serial Attach-SCSI (SAS) interface, a Fibre Channel interface, or another back-end interface. Host adapter110can include a device on a main-board of information handling system100, an add-in card of the information handling system, an external device, another data storage adapter, or a combination thereof.

RAID controller120represents a disk control device of information handling system100, and that operates to receive data storage and retrieval requests from host adapter110, and to manage disk storage devices such as SSDs132,134, and136. In particular, RAID controller120operates to combine SSDs132,134, and136into a logical unit (that is, as RAID array130). In this way, host adapter110makes data storage and retrieval requests that are directed to RAID array130, and RAID controller120distributes the requests among SSDs132,134, and136. As illustrated, RAID controller120operates RAID array130in a RAID 5 configuration using block level striping and with parity information distributed across SSDs132,134, and136. RAID 5 is used herein for illustrative purposes, and the systems and methods described are not intended to be limited to RAID 5 applications only, but can be applied to other parity-based RAID levels, such as RAID 2, RAID 3, RAID 4, RAID 6, or other non-standard RAID levels or architectures. RAID controller120receives requests from host adapter110and provides the requests to SSDs132,134, and136in a common protocol associated with the back-end protocol of the host adapter. For example, RAID controller120can include front-end and back-end interfaces such as ATA interfaces, PATA interfaces, SATA interfaces, SAS interfaces, SCSI interfaces, Fibre Channel interfaces, or other front-end and back-end interfaces. In a particular embodiment, RAID controller120initializes SSDs132,134, and136by performing device discovery, including issuing a READ_CAPACITY command. In response, SSDs132,134, and136will reply with a Logical Block Provisioning Read Zeros (LBPRZ) bit set to a logical one (1), indicating that a read operation to a de-allocated block will return data with all bits set to a logical zero (0).

RAID array130is configured as a RAID 5 array using block level striping and distributed parity. RAID array130stores data in stripes140,150, and160across SSDs132,134, and136. Stripe140includes a first data strip142on SSD132, a second data strip144on SSD134, and a parity strip146on SSD136. Stripe150includes a first data strip152on SSD132, a parity strip154on SSD134, and a second data strip156on SSD136. Stripe160includes a parity strip162on SSD132, a first data strip164on SSD134, and a second data strip166on SSD136. Note that the logical view presented by RAID array130to host adapter110and to an operating system of information handling system100differs significantly from the physical storage of the data in stripes140,150, and160on SSDs132,134, and136. This is due to the characteristics of the solid state memory devices that make up SSDs132,134, and136, and the control of data storage within the SSDs. For example, the controller on SSDs132,134, and136may place data within contiguous physical blocks when the data is first provided to the SSDs, but due to factors such as wear leveling and garbage collection, the data may move to different physical blocks over time. In order to represent the data stored on SSDs132,134, and136in the same logical view as it was provided to the SSDs by the operating system, the SSDs each include a Flash Translation Layer (FTL) that maintains an updated map between the logical view of RAID controller120and the physical blocks where the data is stored on the SSDs.

In a particular embodiment, the operating system determines that some blocks of data are no longer in use, and that the data blocks can be de-allocated from the data storage devices associated with the operating system. For example, a particular file can be deleted and the operating system can de-allocate the blocks associated with the file from a data storage device that stores the file. In a particular embodiment, the operating system is aware that the data storage includes SSDs and issues a command to inform the SSDs that the blocks of data can be de-allocated. For example, where the SSDs operate in accordance with an ATA protocol, the TRIM bit of the DATA SET MANAGEMENT command can be set to a logical one (1) to inform the SSDs that data blocks associated with the command can be de-allocated. In another example, where the SSDs operate in accordance with a SCSI protocol, the UNMAP command can be sent to inform the SSDs that data blocks associated with the command can be de-allocated. Note that as disclosed herein, the SCSI UNMAP command is provided as an exemplary illustration but that the disclosure is not limited thereby, and that the teachings herein are also applicable within the ATA protocol or within other protocols for managing SSDs.

In a particular embodiment, an UNMAP command is issued to host adapter120by the operating system, the host adapter forwards the UNMAP command to RAID controller120, and the RAID controller modifies and forwards the UNMAP command to one or more of SSDs132,134, and136, depending on which SSD includes the data associated with the logical block addresses (LBAs) provided by the UNMAP command. RAID controller120also determines the parity data associated with any stripes that are affected by the UNMAP command.

The UNMAP command is an advisory command to SSDs132,134, and136. As such, there are cases when SSDs132,134, and136take no action in response to receiving an UNMAP command. For example if SSDs132,134, and136allocate the physical blocks of the solid state memory devices on a fixed granularity, but the UNMAP command is for only a portion of the allocated granularity, then SSDs132,134, and136may keep physical blocks that include de-allocated logical blocks allocated. Further, the UNMAP command operates on each logical block independently of the operation on other logical blocks included in the UNMAP command, such that, in response to a single UNMAP command, some logical blocks become de-allocated, while others remain allocated.

FIG. 2illustrates a portion200of an SSD similar to SSDs132,134, and136, including physical blocks210,220, and230. Physical block210includes LBAs1-4, physical block220includes LBAs5-8, and physical block230includes LBAs9-12. LBAs1-3include data associated with first user data (UD)240, LBAs4-9include data associated with second UD242, and LBAs10-12include data associated with third UD244.

FIG. 3illustrates a table250showing various UNMAP scenarios associated with portion200. For example, an UNMAP command can be issued by an operating system to the SSD device that includes portion200. The UNMAP command can include UD240, as shown in the first entry of table250. Although the data associated with UD240resides in physical block210, physical block210remains allocated because physical block210also includes a portion of UD242. Physical blocks220and230also remain allocated because no portion of the data associated with UD240are included therein. When the UNMAP command includes UD242, as shown in the second entry of table250, only physical block242is de-allocated, because only physical block242exclusively stores data associated with UD242. Physical blocks210and230remain allocated because in addition to portions of the data associated with UD242, physical blocks210and230also include the data associated with UDs240and244, respectively. The third entry of table250illustrates that physical blocks210,220, and230all remain allocated in response to an UNMAP command that includes UD244, because the data associated with UD244is stored in physical block240, along with a portion of the data associated with UD242. The fourth entry of table250illustrates that physical blocks210and220are de-allocated, and physical block230remains allocated in response to an UNMAP command that includes UDs240and242. The fifth entry of table250illustrates that physical block210remains allocated, and physical blocks220and230are de-allocated in response to an UNMAP command that includes UDs242and244. Finally, the sixth entry of table250illustrates that physical blocks210,220, and230are all de-allocated in response to an UNMAP command that includes UDs240,242, and244.

In a particular embodiment, in response to an UNMAP command, SSDs132,134, and136issue a reply to RAID controller120. Because the UNMAP command is an advisory command, no error conditions are associated with the UNMAP command. However, the reply can be a GOOD reply that indicates that the UNMAP command was successfully executed, and that all physical blocks associated with the LBAs of the UNMAP command were de-allocated, or the reply can be a GOOD_WITH_SENSE reply that indicates that not all of the physical blocks were de-allocated. In another embodiment, a CHECK_CONDITION reply indicates that the UNMAP command encountered an error. In response to the CHECK_CONDITION reply, RAID controller120issues a REQUEST SENSE command, and the SSD132,134, or136issues an Additional Sense Code reply that includes an ADDITIONAL_SENSE_CODE/ADDITONAL_SENSE_CODE_Qualifier (ASC/ASCQ) code that indicates NOT_ALL_LOGICAL_BLOCKS_UNMAPPED.

When RAID controller120detects a GOOD reply, then the RAID controller determines that all of the LBAs associated with the UNMAP command have been de-allocated, and the RAID controller assumes that all de-allocated blocks include logic zeros (0), determines new parity data for each affected stripe, and writes the new parity data to RAID array130. However, when RAID controller120detects a GOOD_WITH_SENSE reply or receives the KEY_CODE_QUALIFIER reply with the NOT_ALL_LOGICAL_BLOCKS_UNMAPPED ASC/ASCQ code, the RAID controller is unaware of which physical blocks have been de-allocated, and which have not. As such, in response to a GOOD_WITH_SENSE reply, RAID controller120issues a GET_LBA_STATUS command to whichever SSD132,134, or136provided the GOOD_WITH_SENSE reply. The GET_LBA_STATUS command includes the LBAs that were included in the UNMAP command. In response to the GET_LBA_STATUS request, SSD132,134, or136provides the current status of each LBA that is included in the GET_LBA_STATUS request. If the status returned for a particular LBA is “allocated”, then RAID controller120determines that the parity associated with the particular LBA is unchanged. However, if the status returned for another LBA is “de-allocated”, then RAID controller120assumes that the LBA includes logic zeros (0), determines new parity data for the LBA, and writes the new parity data for the stripe to RAID array130.

FIG. 4illustrates a method of keeping parity consistent in an array of SSDs when data blocks are de-allocated, starting at block302. A RAID controller or a host adapter performs device discovery, including issuing a READ_CAPACITY command and receiving a reply with a LBPRZ set to a logical 1 in block304. In this way, for example, SSDs132,134, and136can be set to issue logical zeros (0) in response to a read to a de-allocated logical block. A parity-based RAID array is configured, and parity data (PD) is generated for data stored in the RAID array during write operations in block308. For example RAID array130can be configured as a RAID 5 array. An UNMAP command for one or more LBAs is received from a host system in block308. For example, an operating system of information handling system100, or host adapter110can issue the UNMAP command. The UNMAP command is issued from the RAID controller to an associated SSD in block310. For example, RAID controller120can send the UNMAP command to one or more of SSDs132,134, or136.

A determination is made as to the command completion status returned by the SSDs in decision block312. If the command completion status is a GOOD reply, the “GOOD” branch of decision block312is taken, thereby indicating that all LBAs identified by the UNMAP command were de-allocated, the data parity for the de-allocated LBAs is calculated and updated on the relevant strip based upon the return of logical zeros (0's) within the de-allocated LBAs in block314, and the method ends in block316. If the command completion status is a GOOD_WITH_SENSE reply, or an Additional Sense Code reply is received that indicates NOT_ALL_LOGICAL_BLOCKS_UNMAPPED, the “GOOD_WITH_SENSE” branch of decision block312is taken, and the RAID controller issues a GET_LBA_STATUS command to the appropriate SSDs, and a decision is made as to whether all LBAs are indicated to be de-allocated in decision block320. If so, the “YES” branch of decision block320is taken, the data parity for all LBAs is calculated and updated based upon the return of logical zeros (0's) within the de-allocated LBAs in block324, and the method ends in block316. If not all LBAs are indicated to be de-allocated, the “NO” branch of decision block320is taken, and the parity for the successfully de-allocated blocks is calculated and updated in block324, and the method ends in block316.

FIG. 5is a block diagram illustrating an embodiment of an information handling system400, including a processor410, a chipset420, a memory430, a graphics interface440, an input/output (I/O) interface450, a disk controller460, a network interface470, and a disk emulator480. In a particular embodiment, information handling system400is used to carry out one or more of the methods described herein. In another embodiment, one or more of the systems described herein are implemented in the form of information handling system400.

Chipset420is connected to and supports processor410, allowing the processor to execute machine-executable code. In a particular embodiment, information handling system400includes one or more additional processors, and chipset420supports the multiple processors, allowing for simultaneous processing by each of the processors and permitting the exchange of information among the processors and the other elements of the information handling system. Chipset420can be connected to processor410via a unique channel, or via a bus that shares information among the processor, the chipset, and other elements of information handling system400.

Memory430is connected to chipset420. Memory430and chipset420can be connected via a unique channel, or via a bus that shares information among the chipset, the memory, and other elements of information handling system400. In another embodiment (not illustrated), processor410is connected to memory430via a unique channel. In another embodiment (not illustrated), information handling system400includes separate memory dedicated to each of the one or more additional processors. A non-limiting example of memory430includes static random access memory (SRAM), dynamic random access memory (DRAM), non-volatile random access memory (NVRAM), read only memory (ROM), flash memory, another type of memory, or any combination thereof.

Graphics interface440is connected to chipset420. Graphics interface440and chipset420can be connected via a unique channel, or via a bus that shares information among the chipset, the graphics interface, and other elements of information handling system400. Graphics interface440is connected to a video display442. Other graphics interfaces (not illustrated) can also be used in addition to graphics interface440as needed or desired. Video display442includes one or more types of video displays, such as a flat panel display, another type of display device, or any combination thereof.

I/O interface450is connected to chipset420. I/O interface450and chipset420can be connected via a unique channel, or via a bus that shares information among the chipset, the I/O interface, and other elements of information handling system400. Other I/O interfaces (not illustrated) can also be used in addition to I/O interface450as needed or desired. I/O interface450is connected via an I/O interface452to one or more add-on resources454. Add-on resource454is connected to a storage system490, and can also include another data storage system, a graphics interface, a network interface card (NIC), a sound/video processing card, another suitable add-on resource or any combination thereof. I/O interface450is also connected via I/O interface452to one or more platform fuses456and to a security resource458. Platform fuses456function to set or modify the functionality of information handling system400in hardware. Security resource458provides a secure cryptographic functionality and includes secure storage of cryptographic keys. A non-limiting example of security resource458includes a Unified Security Hub (USH), a Trusted Platform Module (TPM), a General Purpose Encryption (GPE) engine, another security resource, or a combination thereof.

Disk controller460is connected to chipset420. Disk controller460and chipset420can be connected via a unique channel, or via a bus that shares information among the chipset, the disk controller, and other elements of information handling system400. Other disk controllers (not illustrated) can also be used in addition to disk controller460as needed or desired. Disk controller460includes a disk interface462. Disk controller460is connected to one or more disk drives via disk interface462. Such disk drives include a hard disk drive (HDD)464, and an optical disk drive (ODD)466, and can include one or more disk drive as needed or desired. ODD466can include a Read/Write Compact Disk (R/W-CD), a Read/Write Digital Video Disk (R/W-DVD), a Read/Write mini Digital Video Disk (R/W mini-DVD, another type of optical disk drive, or any combination thereof. Additionally, disk controller460is connected to disk emulator480. Disk emulator480permits a solid-state drive484to be coupled to information handling system400via an external interface482. External interface482can include industry standard busses such as USB or IEEE 1394 (Firewire) or proprietary busses, or any combination thereof. Alternatively, solid-state drive484can be disposed within information handling system400.

Network interface device470is connected to I/O interface450. Network interface470and I/O interface450can be coupled via a unique channel, or via a bus that shares information among the I/O interface, the network interface, and other elements of information handling system400. Other network interfaces (not illustrated) can also be used in addition to network interface470as needed or desired. Network interface470can be a network interface card (NIC) disposed within information handling system400, on a main circuit board such as a baseboard, a motherboard, or any combination thereof, integrated onto another component such as chipset420, in another suitable location, or any combination thereof. Network interface470includes a network channel472that provide interfaces between information handling system400and other devices (not illustrated) that are external to information handling system400. Network interface470can also include additional network channels (not illustrated).

Information handling system400includes one or more application programs432, and Basic Input/Output System and Firmware (BIOS/FW) code434. BIOS/FW code434functions to initialize information handling system400on power up, to launch an operating system, and to manage input and output interactions between the operating system and the other elements of information handling system400. In a particular embodiment, application programs432and BIOS/FW code434reside in memory430, and include machine-executable code that is executed by processor410to perform various functions of information handling system400. In another embodiment (not illustrated), application programs and BIOS/FW code reside in another storage medium of information handling system400. For example, application programs and BIOS/FW code can reside in HDD464, in a ROM (not illustrated) associated with information handling system400, in an option-ROM (not illustrated) associated with various devices of information handling system400, in storage system490, in a storage system (not illustrated) associated with network channel472, in another storage medium of information handling system400, or a combination thereof. Application programs432and BIOS/FW code434can each be implemented as single programs, or as separate programs carrying out the various features as described herein.

In the embodiments described herein, an information handling system includes any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or use any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an information handling system can be a personal computer, a consumer electronic device, a network server or storage device, a switch router, wireless router, or other network communication device, a network connected device (cellular telephone, tablet device, etc.), or any other suitable device, and can vary in size, shape, performance, price, and functionality. The information handling system can include memory (volatile (e.g. random-access memory, etc.), nonvolatile (read-only memory, flash memory etc.) or any combination thereof), one or more processing resources, such as a central processing unit (CPU), a graphics processing unit (GPU), hardware or software control logic, or any combination thereof. Additional components of the information handling system can include one or more storage devices, one or more communications ports for communicating with external devices, as well as, various input and output (I/O) devices, such as a keyboard, a mouse, a video/graphic display, or any combination thereof. The information handling system can also include one or more buses operable to transmit communications between the various hardware components. Portions of an information handling system may themselves be considered information handling systems.

When referred to as a “device,” a “module,” or the like, the embodiments described herein can be configured as hardware. For example, a portion of an information handling system device may be hardware such as, for example, an integrated circuit (such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a structured ASIC, or a device embedded on a larger chip), a card (such as a Peripheral Component Interface (PCI) card, a PCI-express card, a Personal Computer Memory Card International Association (PCMCIA) card, or other such expansion card), or a system (such as a motherboard, a system-on-a-chip (SoC), or a stand-alone device). The device or module can include software, including firmware embedded at a device, such as a Pentium class or PowerPC™ brand processor, or other such device, or software capable of operating a relevant environment of the information handling system. The device or module can also include a combination of the foregoing examples of hardware or software. Note that an information handling system can include an integrated circuit or a board-level product having portions thereof that can also be any combination of hardware and software.