Storage system having plurality of flash packages

The storage system comprises a plurality of flash packages configuring one or more RAID groups, and a controller coupled to the plurality of flash packages. Each flash package comprises a plurality of flash chips configured from a plurality of physical blocks. The controller identifies a target area related to an unnecessary area, unmaps a physical block allocated to a logical block belonging to this target area from this logical block, and manages the unmapped physical block as a free block.

TECHNICAL FIELD

The present invention relates to a storage system.

BACKGROUND ART

A storage system that uses flash memory as a storage medium instead of a hard disk is conceivable. A flash memory (for example, a NAND flash memory) is configured from a plurality of flash memory chips (called flash chips below). Each flash chip is configured from a plurality of physical blocks.

The flash memory is advantageous in that it is capable of operating at higher speeds and consumes less power than the hard disk. However, by contrast, it also has the following limitations.

First is the fact that the updating of each bit of memory is limited to one direction, i.e., from 1 to 0 (or from 0 to 1). In a case where a reverse update is required, an erase process, in which all the cell bits configuring the physical block are set to 1 (or 0), must be carried out for a physical block.

Second, the erase count per physical block is limited. For example, in the case of a NAND flash memory, the limit of the erase count per physical block is between around 10,000 and 100,000.

For the above reasons, in a case where a flash memory is used instead of a hard disk as the storage medium in a storage system, there is the concern that the bias of the rewrite frequency for each physical block will result in only some of the physical blocks reaching the erase count limit and becoming unusable. For example, in an ordinary file system, since the rewrite frequency to a logical block allocated to either a directory or an i-node is higher than the rewrite frequency to another logical block, it is highly likely that the erase count for the physical block allocated to the logical block that has been allocated to either the directory or the i-node will reach the limit.

With regard to this problem, as shown in Patent Literature 1, technology for extending the service life of a storage apparatus by allocating a physical block (an alternate block) that will serve as an alternate for the physical block (the bad block) that has become unusable is known.

Further, as shown in Patent Literature 2, technology (wear-leveling) for leveling the erase counts of the physical blocks by dynamically changing the logical/physical mapping (for example, the corresponding relationship between a logical block and a physical block) is also known. Wear-leveling algorithms include dynamic wear-leveling and static wear-leveling. Dynamic wear-leveling is the migrating of data as much as possible to a free block with a low erase count when erasing a physical block in line with a data update. In static wear-leveling, data that is not to be updated (static data) may also become the target of a migration.

CITATION LIST

Patent Literature

SUMMARY OF INVENTION

Technical Problem

A bias in the erase count can generate a large number of unusable physical blocks (physical blocks whose service life has ended). When this happens, the physical blocks (free blocks) capable of being allocated to the logical blocks are exhausted, thereby making it impossible to store new data on the storage system.

Therefore, an object of the present invention is for wear-leveling to be carried out efficiently inside a storage system.

Solution to Problem

A storage system comprises a plurality of flash packages, which configure one or more RAID (Redundant Array of Independent (or Inexpensive) Disks) groups, and a controller, which is coupled to the plurality of flash packages. Each flash package comprises a plurality of flash chips configured from a plurality of physical blocks. The controller identifies a target area related to an unused area, unmaps a physical block that has been allocated to a logical block belonging to this target area from this logical block, and manages the unmapped physical block as a free block.

DESCRIPTION OF EMBODIMENTS

One embodiment of the present invention will be explained below.

First of all, the terminology used in this explanation will be explained.

Generally speaking, the smallest unit for reading and writing data in a so-called block storage is called a “block”, but in a flash memory, the flash memory erase unit is called a “block”. In order to distinguish between these in the explanation of this embodiment, the flash memory erase unit will be called a “block”, and the smallest data read/write unit will be called a “sector”. In this embodiment, one block includes a plurality of sectors. Specifically, for example, the flash memory is a NAND flash memory. For this reason, for example, the flash memory is configured from a plurality of flash chips, the flash chip is configured from a plurality of physical blocks, and the physical block is configured from a plurality of physical pages. In the NAND flash memory, the read/write unit is a “page”, and the erase unit is the “block”. However, the present invention is not limited to a storage system including this kind of flash memory, and is also applicable to a storage system including a flash memory having a different configuration.

Next, the term “chunk” will be explained. In managing a storage area, the storage controller (will be explained further below) is able to more flexibly control the allocation, unmapping and migration of the storage area by carrying out management in units that are smaller than the so-called logical unit. This storage area management unit will be called a “chunk” in the explanation of this embodiment. In the following embodiment, one logical unit includes a plurality of logical chunks, and in a case in which there is a write to any of the logical chunks, a physical chunk is allocated to this logical chunk. However, the present invention is not limited to a storage system including this kind of capacity virtualization function, and is also applicable to a storage system in which the storage area is managed in volume units. For example, one logical unit may be regarded as being configured from one chunk.

An overview of this embodiment will be explained next.

The storage system includes a storage controller, and a plurality of drives that use a flash memory as the storage medium. Each drive includes a drive controller.

The storage controller manages the corresponding relationship between a logical address of a logical unit and a logical address of each drive. The drive controller manages the corresponding relationship between the drive logical address and a physical address.

The storage controller identifies a target area related to an unused area, and sends an unmap instruction specifying the address of the identified target area to the drive. As used here, an unused area, for example, may be at least one of (1) through (5) below:(1) an area inside the host file system in which a host has stored an erased file;(2) an erased logical unit;(3) a physical chunk, which has been unmapped from any logical chunk inside a logical unit;(4) a migration-source area which contained data that was migrated from a certain drive to another drive; and(5) an area in which data of a specific pattern (for example, “0” data) is repeatedly written.

The target area may be the same as the above-described unused area, or it may be larger or smaller than this unused area. The target area, for example, is determined on the basis of the RAID type of the RAID group based on the unused area.

The drive controller, in response to this unmap instruction, manages the physical block portion corresponding to the logical block portion including the specified address as being able to be unmapped. In a case where the drive controller manages an entire physical block as being able to be unmapped, this physical block is unmapped from the logical block. That is, the drive controller unmaps the allocation of this physical block to the logical block. The drive controller carries out an erase process with respect to the unmapped physical block. The drive controller determines whether or not the erase count of this physical block up until this point exceeds a predetermined threshold. In a case where the result of this determination is negative, the drive controller manages this physical block as an allocatable physical block (a free block). Consequently, since it is possible to increase the free blocks, an improvement in wear-leveling efficiency may be expected. Furthermore, in a case where the above determination result is affirmative, the drive controller manages this physical block as an unallocatable physical block (a bad block).

Further, in a case where a write to a certain drive has failed, and, in addition, the cause of this failure is the fact that there is a shortage of free blocks inside this drive, the storage controller migrates the data from this certain drive to another drive. Then, the storage controller sends an unmap instruction specifying the address of the storage area in which the migrated data had been stored to the original drive.

Also, in a case where a failure has occurred in a flash chip inside a certain drive, the storage controller restores the data inside this bad chip based on the data inside the other drive, and writes the restored data to another flash chip inside the above-mentioned certain drive. In accordance with this, it is possible to efficiently utilize the storage area of one drive.

Further, in a case where there is little remaining storage area, the storage controller issues a warning to an administrator. Specifically, for example, the storage controller outputs information denoting a warning to the computer being used by the administrator when the unallocated physical chunks have diminished.

This embodiment will be explained in detail below by referring to the drawings. Furthermore, in the following explanation, a command received by the storage controller from an external device (for example, a host computer) will be called a “request”, and a command received by the drive from the storage controller will be called an “instruction”.

FIG. 1is a diagram showing an example of the configuration of a computer system related to the embodiment of the present invention.

A host computer2, which is one type of external device, and which issues I/O (Input/Output) requests, and a management server3, which is a computer for managing the storage system1, are coupled to a storage system1.

The storage system1includes a storage controller4and a plurality of drives5. The drive5(each of the drives5) may be a SSD (Solid State Drive).

A plurality of RAID (Redundant Array of Independent (or Inexpensive) Disks) groups are configured based on the plurality of drives5. A RAID group is configured by two or more drives5. The storage controller4stores data in a RAID group in accordance with a RAID type, which has been defined in advance for this RAID group.

A controller140, for example, is configured in accordance with the storage controller4and a drive controller220(refer toFIG. 4) inside each drive5.

The storage controller4includes one or more microprocessors (notated as MP below)6for controlling the storage system1, a control memory7for holding data and a program for carrying out control, a cache memory8, which is a memory for caching data, one or more host adapters9for exchanging data with the host computer2, one or more management ports10for communication with the management server3, and an internal network11for interconnecting the drive5, cache memory8, host adapter9, and MP6. The control memory7and the cache memory8may be the same memory. The data written to the drive5from the host computer2, and the data read from the drive5to the host computer2are temporarily stored in the cache memory8. In other words, the data that is written/read to/from the host computer2is input/output to/from the drive5by way of the cache memory8.

The control memory7stores logical unit management information12including information related to each logical unit, and pool management information13including information related to a storage pool.

The storage controller4manages a logical unit configured from a plurality of logical chunks, and a pool. The pool includes a plurality of physical chunks. The plurality of physical chunks is a plurality of logical storage areas based on a plurality of RAID groups. Specifically, for example, a pool is configured from a plurality of physical chunks, and each logical unit is configured from a plurality of physical chunks included in a pool. Each physical chunk is based on two or more drives5that configure any of the RAID groups. Two or more logical blocks, of the plurality of logical blocks of a RAID group that constitutes the basis of the physical chunk, are allocated to this physical chunk. In a case where the storage controller4receives a write request from the host computer2and a physical chunk has not been assigned to the logical chunk (write-destination logical chunk) identified from the address specified in this write request, the storage controller4allocates an unallocated physical chunk inside the pool to the write-destination logical chunk.

FIG. 2is a diagram showing an example of logical unit management information12.

The logical unit management information12exists for each logical unit. The logical unit management information12includes a pool allocation table21and a mapped sector bitmap23.

The pool allocation table21is for managing the allocation of a physical chunk to a logical unit corresponding to the logical unit management information12(called the “target logical unit” in the below explanation ofFIG. 2). Specifically, the table21denotes the corresponding relationship between the logical chunks configuring the target logical unit and the physical chunk allocated to the logical chunks. The information denoting the physical chunk, for example, is configured from a RAID group number24and a start address25. The RAID group number24and start address25corresponding to a logical chunk to which a physical chunk has not been allocated are invalid values (for example, NULL). The information24and25will be explained by giving a single physical chunk (called the “target physical chunk” below in this paragraph) as an example. The RAID group number24is the number of the RAID group that forms the basis of the target physical chunk. The start address25is the start address of the target physical chunk in the storage space of this RAID group. The storage controller4is able to calculate the address (the address in the logical block group) specified in the drive5by carrying out a predetermined computation based on (A) and (B) below:(A) the address specified in the access request from the host computer2; and(B) the RAID group number24and start address25of the physical chunk allocated to the logical chunk having the address of (A).

The mapped sector bitmap23is a bitmap denoting whether or not it is necessary to allocate a drive5storage area to each logical sector inside the target logical unit. Each logical chunk may comprise a plurality of sectors, and each sector may comprise a plurality of logical chunks. In other words, the logical chunk may be larger than the sector, or the sector may be larger than the logical chunk. For example, in a case where a write request specifying the address of sector 0 has been received from a higher-level device (the host computer2), the storage controller4updates the bit0(a bit inside the mapped sector bitmap23) corresponding to this sector 0 to ON (1). By contrast, in a case where an unmap request specifying the sector 0 address has been received from the host computer2, the storage controller4updates the above-mentioned bit0to OFF (0). A bit that is ON (1) will be referred to as the “ON bit” and a bit that is OFF (0) will be referred to as the “OFF bit” below.

FIG. 3is a diagram showing an example of the pool management information13.

The pool management information13exists for each pool. The pool management information13includes a free chunk list31for managing the free chunks (unallocated physical chunks) inside the pool (referred to as a “target pool” in the explanation ofFIG. 3below) corresponding to this information13, a free chunk counter32for storing the number of free chunks inside the target pool, and a total chunk counter33for storing the total number of physical chunks configuring the target pool. The free chunk list31juxtaposes a free chunk RAID group number34and start address35.

FIG. 4is a diagram showing an example of the configuration of the drive5.

The drive5includes a drive controller220and a flash package230. The flash package230includes a plurality of flash chips43.

The drive controller220includes one or more processors (drive processors)41for controlling the drive, a main memory42for holding data and a program for carrying out the control, and one or more ports44for exchanging data with the storage controller4.

The main memory42stores flash memory management information45including information related to the flash chip43(each of flash chips43). Furthermore, the main memory implementation method is not limited to the mode ofFIG. 4. For example, the main memory42may be built into the circuit including the drive processor41, or one part of the area of the flash package230may be used as the main memory42.

FIG. 5shows an example of the flash memory management information45. Furthermore, inFIG. 5, a logical block is abbreviated as “LB”, and a physical block is abbreviated as “PB”.

The flash memory management information45includes a block allocation table51, a free block list52, a free block counter53, an allocated block counter54, a bad block counter55, a block erase counter list56, a total erase counter57, and a mapped sector bitmap58.

The block allocation table51denotes the corresponding relationship between each logical block and the physical block allocated to each logical block. The physical block information, for example, is configured from a chip number59and a block number60. The information59and60, which corresponds to a logical block to which a physical block has not been allocated, is an invalid value (for example, NULL). The information59and60will be explained by giving a single physical block (called a “target physical block” below in this paragraph) as an example. The chip number59is the number of the flash chip43including the target physical chunk. The block number60is the number denoting the target physical block.

The free block list52juxtaposes a chip number61and a block number62of a free chunk (an allocatable physical block).

The free block counter53stores the number of free blocks.

The allocated block counter54stores the number of physical blocks that are allocated to logical blocks.

The bad block counter55stores the number of bad blocks (physical blocks that have become unusable and unallocatable due to a failure or end of service life).

The block erase counter list56is a block erase counter63list that stores the erase count for each physical block.

The total erase counter57is for storing the total erase count that has taken place inside the relevant drive. In other words, the value of the counter57(the total erase count) is the total of all the erase counters63(all the erase count). Each time an erase process is carried out with respect to any physical block inside the drive5, the drive controller220increments the value of the block erase counter63corresponding to this physical block by 1, and increments the value of the total erase counter57by 1. The value of the total erase counter57, for example, is one of the factors used in determining a migration-destination RAID group, which will be explained further below.

The mapped sector bitmap58is for denoting whether or not it is necessary to allocate a physical storage area to the respective logical sectors inside the drive5. Each logical block may comprise a plurality of sectors, and each sector may comprise a plurality of logical blocks. That is, the logical block may be larger than the sector, or the sector may be larger than the logical block. For example, in a case where a write instruction specifying the sector 0 address has been received from a higher-level device (the storage controller4), the drive controller220updates the bit0(a bit inside the mapped sector bitmap58) corresponding to this sector 0 to ON (1). By contrast, in a case where an unmap instruction specifying the sector 0 address has been received from the storage controller4, the drive controller220updates the above-mentioned bit0to OFF (0).

The flow of processing for accessing a physical block from the storage controller4will be explained below. Furthermore, the storage controller4manages the corresponding relationship (the pool allocation table21) as to which physical chunk is allocated to which logical chunk. The storage controller4may also manage the corresponding relationship (a chunk/block corresponding relationship) as to which two or more logical blocks are allocated to which physical chunk.

The storage controller4, upon receiving a write request from the host computer2, determines on the basis of the pool allocation table21whether or not a physical chunk is allocated to the logical chunk (the write-destination logical chunk) identified from this write request. When the result of this determination is negative, the storage controller4allocates a free chunk (an unallocated physical chunk) to the write-destination logical chunk, and writes the data appended to the write request to the allocated physical chunk.

The storage controller4, in a case where data is to be written to the physical chunk, sends a write instruction specifying the address identified on the basis of the information24and25with respect to this physical chunk to the drive controller220managing this address. The drive controller220, which receives this write instruction, determines based on the block allocation table51(that is, the corresponding relationship of the blocks), whether or not a physical block is allocated to the logical block (the write-destination logical block) having the address specified in this write instruction. When the result of this determination is negative, the drive controller220selects a free block on the basis of the free block list52, allocates this free block to the write-destination logical block, and writes the data targeted by this write instruction to the allocated physical block (the free block).

The storage controller4, upon receiving a read request from the host computer2, identifies on the basis of the pool allocation table21the physical chunk allocated to the logical chunk (the read-source logical chunk) identified from this read request. The storage controller4reads the data from the identified physical chunk, and sends the read data to the host computer2.

The storage controller4, upon reading out the data from the physical chunk, sends a read instruction specifying an address identified on the basis of the information24and25with respect to this physical chunk to the drive controller220managing this address. The drive controller220, which receives this read instruction, identifies on the basis of the block allocation table51the physical block that is allocated to the logical block having the address specified in this read instruction. The drive controller220reads the data from the identified physical block, and sends this data to the storage controller4.

The processing executed by this embodiment will be explained below. Furthermore, in the following explanation, the processing carried out by the drive controller220is executed by the drive processor41, and the processing carried out by the storage controller4is executed by the MP6.

FIG. 6is a flowchart showing an example of a sector unmap process.

The drive controller220receives an unmap instruction from the storage controller4(Step71). The unmap instruction includes a group of parameters denoting the address range of the unmap target. The group of parameters, for example, includes a first address (LBA (Logical Block Address)) of the region to be unmapped in the drive5, and the size (the number of sectors) of the region to be unmapped.

The drive controller220updates the bit (a bit inside the mapped sector bitmap58) corresponding to the logical sector included in the address range specified in this unmap instruction to OFF (0) (Step72).

The drive controller220determines whether or not all the logical sectors inside the logical block are in the unallocated state (OFF (0)) (Step73). When the result of this determination is affirmative (Step73: YES), the drive controller220carries out a block unmap process for unmapping the physical block (called the unmap-targeted block below) allocated to this logical block from this logical block (Step74).

Thereafter, the drive controller220sends a response to the storage controller4(Step75).

FIG. 7is a flowchart showing an example of a block unmap process (Step74ofFIG. 6).

The drive controller220carries out an erase process with respect to the unmap-targeted block (Step81). The erase process is not limited to this timing, and may be carried out at a different timing.

Next, the drive controller220clears the mapping information of the unmap-targeted block (Step82). Specifically, for example, the drive controller220updates the information59and60(the information inside the block allocation table51) corresponding to the unmap-targeted block to NULL. The drive controller220increments the erase count of the unmap-targeted block by 1.

Next, the drive controller220determines whether or not the erase count (the value of the erase counter63) of the unmap-targeted block exceeds an upper limit value (Step84).

When the result of the determination of Step84is affirmative (Step84: YES), the drive controller220manages the unmap-targeted block as a bad block. Specifically, the drive controller220adds the chip number and block number of the unmap-targeted block to a bad block list (Step85). Furthermore, the bad block list, although not shown in the drawing, is a list that is included in the flash memory management information45, and has the same configuration as the free block list52.

When the result of the determination in Step84is negative (Step84: NO), the drive controller220manages the unmapped physical block as a free block. Specifically, the drive controller220adds the chip number and block number of the unmapped physical block to the free block list52(Step86).

One example of a trigger for the storage controller4to send the unmap instruction to the drive5may be the management server3sending a logical unit removal request to the storage controller4. In accordance with this, the storage controller4unmaps all the physical chunks allocated to the removal request-targeted logical unit. Then, in this chunk unmap process, the storage controller4sends an unmap instruction to the drive5.

FIG. 8is a flowchart showing an example of a logical unit removal process.

The storage controller4, upon receiving a logical unit (LU) removal request (Step91), selects as the process-targeted logical chunk the first logical chunk of the logical unit (the target logical unit) specified in this request (Step92).

Next, the storage controller4carries out a chunk unmap process (refer toFIG. 9) for unmapping the physical chunk from the process-targeted logical chunk (Step93).

In a case where the physical chunk has been unmapped from all the logical chunks inside the target logical unit (Step94: YES), the storage controller4ends the processing. When this is not the case (Step94: NO), the storage controller4selects the next logical chunk as the process-targeted logical chunk (Step95), and repeats the processing from Step93.

FIG. 9is a flowchart showing an example of the chunk unmap process (Step93inFIG. 8).

The storage controller4determines the sector to be unmapped (Step101). The “sector to be unmapped” is a logical sector included in the process-targeted logical chunk, specifically, for example, the logical sector corresponding to the ON bit in the mapped sector bitmap23.

The storage controller4sends an unmap instruction specifying the address range in the drive5of the logical sector to be unmapped to the drive5managing this address range (Step102). In a case where the physical chunk spans a plurality of drives5configuring the RAID group on which this physical chunk is based, the storage controller4sends the unmap instruction to each of these plurality of drives5.

In response to this unmap instruction, the drive5carries out a sector unmap process (refer toFIG. 6), and the storage controller4receives a response from the drive5(Step103).

Then, the storage controller4manages the physical chunk allocated to the process-targeted logical chunk as unallocated. Specifically, the storage controller4updates the RAID group number24and the start address25(the information inside the pool allocation table21) corresponding to the process-targeted logical chunk to NULL (Step104). Then, the storage controller4adds the RAID group number and the start address of the physical chunk allocated to this logical chunk to the free chunk list31(Step105).

According to the above explanation, the present invention is not limited to the removal of a logical unit, and, for example, in a case where a physical chunk is dynamically unmapped from any logical chunk, it is also possible to unmap the physical block from the logical block belonging to this physical chunk.

Next, another example of a trigger for the storage controller4to send the unmap instruction to the drive5is a case in which the host computer2sends the unmap request specifying a certain address range to the storage controller4.

FIG. 10is a schematic diagram of an example in which the storage controller4sends the unmap instruction to the drive5in response to the unmap request from the host computer2.

Specifically, for example, it is supposed that the file has been removed from the storage space managed by the file system of the host computer2. In this case, the host computer2(for example, either the file system or the operating system) sends to the storage system1an unmap request specifying the address range of the area in which the removed file had been stored. That is, the host computer2includes a function (an interface) for sending an unmap request specifying the address range of a storage area that the host computer2does not need. Consequently, it is possible to let the storage system1know about the area that the host computer2does not need.

The storage controller4receives the unmap request from the host computer2, and, in response to this unmap request, determines the logical sector (that is, the sector to be unmapped) belonging to the address range specified in this unmap request. The storage controller4sends an unmap instruction specifying the address range in the drive5of the determined logical sector (that is, an unmap instruction specifying the address range corresponding to the removed file area) to the drive5managing this address range.

In response to this unmap instruction, the drive5carries out the sector unmap process (refer toFIG. 6). That is, the logical sector managed by the drive5is managed as an unmap target in accordance with the address range specified in the unmap instruction, and in a case where all the logical sectors inside the logical block are unmap targets, the physical block is unmapped from this logical block.

Furthermore, the storage system1, for example, may be a NAS (Network Attached Storage) system. In this case, the storage system1can determine the removed file area because the storage system1manages the file system.

FIG. 11is a flowchart showing an example of an area unmap process carried out by the storage controller4upon receiving an unmap request from the host computer2.

The storage controller4receives the unmap request from the host computer2(Step111).

Next, the storage controller4updates the bit (a bit inside the mapped sector bitmap23) corresponding to the address range specified in this unmap request to OFF (0) (Step112).

Next, the storage controller4determines the logical sector to be unmapped based on the address range specified in this unmap request (Step113). The logical sector determined here is not limited to the logical sectors of the entire area of the address range specified by the host computer2, but rather is determined on the basis of the RAID type (for example, RAID 5 (3D+1P), RAID 5 (4D+1P)) of the RAID group on which this address range is based. Specifically, in Step113, the storage controller4carries out an unmap region modification process, which will be explained by referring toFIGS. 19 and 20.

Next, the storage controller4sends to the drive5an unmap instruction specifying the address range in the drive of the logical sector determined in Step113(Step114). In response to this unmap instruction, the drive5carries out the sector unmap process (refer toFIG. 6), and the storage controller4receives a response from the drive5(Step115).

The storage controller4determines whether or not all the logical sectors inside the logical chunk are unmap targets (Step116). Specifically, the storage controller4determines whether or not the bits (bits inside the mapped sector bitmap23) corresponding to the all the logical sectors of the logical chunk are OFF (0).

When the result of the determination in Step116is affirmative, the storage controller4carries out the above-mentioned chunk unmap process (refer toFIG. 9) for this logical chunk (Step117).

Thereafter, the storage controller4sends a response with respect to the unmap request to the host computer2(Step118).

However, since the erase count of the flash memory is limited, bad blocks will increase during usage. The increase in bad blocks translates into a reduction of usable physical blocks.

Accordingly, in a case where the usable blocks inside a certain drive5have been exhausted, the data is migrated from this drive5to another drive, and the physical block is unmapped from the logical block belonging to the data migration-source area. The erase process is carried out for the unmapped physical block, and in a case where the erase count is less than the upper limit value, this physical block is regarded as a free block. Data is able to be written/read to/from a free block. Consequently, the service life of the drive5can be expected to lengthen.

FIG. 12is a schematic diagram of a data migration process carried out in response to a write error due to a shortage of free blocks.

For example, in a case where there is a shortage of free blocks in drive A of the drives A through D configuring the RAID group1, and a data write in drive A failed due to the shortage of free blocks, the drive controller220of drive A returns a response including the “error” status as the response to the write instruction from the storage controller4. In addition to the “error” status, the response includes information denoting that the cause of the error is a shortage of free blocks. Instead of the response including information denoting the cause of the error, the storage controller4may acquire the cause of the write error by querying the drive5separately.

The storage controller4allocates a second physical chunk instead of a first physical chunk to the logical chunk (called a “target logical chunk” in the explanation ofFIG. 12below) to which the physical chunk (the first physical chunk) including the write error range is allocated. The write error range is the address range (the write-destination range) specified in the write instruction corresponding to the write error response, and specifically, is the address range based on drive A. The first physical chunk is the physical chunk (source chunk) based on the RAID group1. The second physical chunk is the physical chunk (destination chunk) based on the RAID group2, which is a different RAID group from RAID group1.

The storage controller4migrates the data from the first physical chunk to the second physical chunk. Specifically, the storage controller4reads the data which does not remain on cache memory8among the data in the first chunk from the drives A through D, and writes to the second physical chunk the data (the data that should be written in the first physical chunk) including the read data and data that had not been written to drive A (for example, data remaining in the cache memory8).

When the migration has ended, the storage controller4sends a logical sector unmap instruction corresponding to the first physical chunk to the migration-source drives A through D. The drives A through D, which receive the unmap instruction at this time, manage the logical sector corresponding to the specified address range as the unmap target.

Furthermore, in this example, the RAID group1(the migration-source RAID group) is the RAID group including the write error range, but may also be the RAID group including the drive for which the total erase counter57exceeds a predetermined threshold.

FIG. 13is a flowchart showing an example of a write error handling process triggered by a write error. The send-source drive5of the write error response will be called the “error drive5”, and the RAID group including the error drive5will be called the “RAID group1” below.

The storage controller4receives the write error response from the error drive5, and determines the cause of the write error (Step132). For example, the storage controller4may either analyze the error cause information included in the response, or may identify the cause of the write error by issuing a separate query to the error drive5.

In a case where the cause of the write error is insufficient free blocks in the error drive5(Step132: YES), the storage controller4selects as the migration-destination a free chunk (an unallocated physical chunk) included in the RAID group2(Step133). The RAID group2includes more free blocks than (or includes free blocks as many as) the number of free blocks required for storing the data inside the physical chunk, and, in addition, is the RAID group that has the least total erase count of the RAID groups besides the RAID group1. Specifically, for example, the storage controller4checks the number of free blocks and the total erase count of the RAID groups other than the RAID group1, and from among the RAID groups having a number of blocks in excess of the required number of free blocks (the number of blocks needed to store the data that is inside the physical chunk), selects as the migration-destination the free chunk based on the RAID group having the smallest total erase count. Furthermore, the “number of free blocks in the RAID group” is the smallest value of the values in the free block counter53of the respective drives belonging to this RAID group, and is the value arrived at by multiplying the number of drives belonging to the RAID group. The “total erase count of the RAID group” is the largest value of the values in the total erase counter57of the respective drives5belonging to this RAID group.

Next, the storage controller4migrates the data from the physical chunk (migration-source chunk) including the write error range to the physical chunk (the migration-destination chunk) selected in Step133(Step134). The data to be migrated at this time also includes the data for which the write failed. The details are as explained by referring toFIG. 12.

The storage controller4updates the pool allocation table21(Step135). Specifically, the storage controller4updates the RAID group number24and the start address25corresponding to the logical chunk allocated to the migration-source chunk from the RAID group number and the start address of the migration-source chunk to the RAID group number and the start address of the migration-destination chunk.

Then, the storage controller4unregisters all the free chunks based on the RAID group1(the migration-source RAID group) from the free chunk list31(Step136). In accordance with this, it is possible to prevent the physical chunk based on the RAID group1from being allocated to a logical chunk in the future. Since the write error to the RAID group1was caused by insufficient free blocks, the processing of this Step136will make it possible to lessen the likelihood of a write failing again in the future due to insufficient free blocks. Furthermore, Step136corresponds to Step191ofFIG. 18. Therefore, when Step136is carried out, Step192and beyond ofFIG. 18are carried out. In accordance with this, it is possible to issue a warning to the administrator in a case where pool capacity has been exhausted in the wake of Step136.

Next, the storage controller4sends an unmap instruction specifying an address range in the drive5of the migration-source chunk and the unregistered chunk with respect to all the drives5(the drives5inside the RAID group1) based on the migration-source chunk and the free chunk that was unregistered in Step136(unregistered chunk) (Step137). In accordance with this, a sector unmap process (refer toFIG. 6) is carried out by the respective drives5, and the storage controller4receives the responses to the unmap instruction from these drives5(Step138).

The physical block, which has been unmapped and converted to a free block in the RAID group1is allocatable to any logical block based on the RAID group1. For example, in a case where a data rewrite is frequently carried out with respect to any allocated physical chunk based on the RAID group1, it is possible to allocate a free block inside the RAID group1to a logical block based on this physical chunk.

In this embodiment, in a case where the flash chip43inside a certain drive5fails, it is possible to restore the data stored in the bad flash chip43(called the “bad chip” below) in accordance with a chip failure handling process, which will be explained below.

FIG. 14is a schematic diagram of a flash memory data recovery process for a RAID group of RAID 5 (3D+1P).

In a case where a certain flash chip43inside drive D fails, the storage controller4carries out (a) through (c) below for each sector data (sector size data) stored in the bad chip:(a) reads data from the good chips (the chips for which the failure did not occur) inside the other drives A through C, which store the other data inside the dataset including the data inside the bad chip43;(b) restores the data inside the bad chip43by carrying out a parity operation that makes use of the read data; and(c) stores the restored data in any good chip inside the drive D including the bad chip43.

Furthermore, the “dataset” is the unit of data written to the RAID group. For example, in the case of RAID 5, it is the data including a plurality of user data and the parity data created based thereon.

However, since the corresponding relationship between the logical address (LBA) and the physical address (the flash memory chip number/block number) is managed inside the drive5, the storage controller4does not know which logical address data went missing at the point in time that a certain flash chip43fails. Accordingly, the storage controller4carries out a flash memory data recovery process in accordance with at least one of the below methods:(Method 1) Queries the drive5as to the range of the missing data, and carries out the data recovery process for the replied range;(Method 2) Carries out the data recovery process for the entire drive5; and(Method 3) Executes a read in order from the start of the drive5, and carries out the data recovery process for the location(s) that cannot be read.

FIG. 15is a flowchart showing an example of the flash memory data recovery process according to Method 1.

The storage controller4acquires from the drive (corresponds to drive D in the example ofFIG. 14, and will be called the “bad drive” below) including the bad chip a bad range in the logical address space, that is, an address range for the missing data (the first address and the length (the number of sectors)) (Step151). A scheme whereby a list of all the bad ranges is acquired at once at this time is conceivable, but in this example, the bad ranges are acquired one location at a time.

In a case where all the data inside the bad chip of the bad drive has been recovered (Step152: YES), the drive controller220inside the bad drive, for example, returns NULL in response to the query from the storage controller4. Upon receiving this, the storage controller4recognizes that data restoration has ended. When all of the data has been recovered, the storage controller4ends this flash memory data recovery process.

By contrast, in a case where a bad range remains (Step152: NO), the storage controller4reads the data (either the user data or the parity data) from the other drives inside the RAID group including the bad drive (Step153).

Next, the storage controller4restores the missing data by using the read data to carry out a parity operation (Step154).

Next, the storage controller4writes the restored data to the bad drive (Step155). The drive controller220inside the bad drive writes the restored data to a free block inside a good chip (a normal flash chip) at this time.

However, in a case where the free blocks required for this write do not exist inside the bad drive, there is the likelihood that the write will fail.

In a case where the write fails (Step156: YES), the write error handling process shown inFIG. 13is carried out (Step157). In so doing, it is possible to arbitrarily move the data to another RAID group.

FIG. 16is a flowchart showing an example of the flash memory data recovery process in accordance with Method 2. According to Method 2, data restoration is executed for the entire bad drive5.

The storage controller4sends to the bad drive an unmap instruction specifying the entire bad drive (Step162). In accordance with this, the sector unmap process (refer toFIG. 6) is carried out in the bad drive, and all the physical blocks allocated to the entire area of the bad drive (from logical address 0 to the last logical address) are unmapped as a result of this.

Next, the storage controller4selects the first logical block of the bad drive as the process target (Step163).

Next, the storage controller4reads the data (either the user data or the parity data) included in the dataset including the data inside the process-targeted logical block selected in Step163from the other drives inside the RAID group including the bad drive (Step164).

Next, the storage controller4restores the missing data (the data inside the process-targeted logical block selected in Step163) by using the read data to carry out a parity operation (Step165).

Next, the storage controller4writes the restored data to the bad drive (Step166). In a case where the write fails (Step167: YES), the write error handling process (refer toFIG. 13) is carried out (Step168).

The storage controller4selects the next logical block in the bad drive as the process target (Step169).

In a case where Steps164and beyond have been carried out for all the logical blocks in the bad drive (in a case where it is not possible to select a logical block in Step169) (Step170: YES), this flash memory data recovery process will end. In a case where a logical block to be processed still remains (a case where it is possible to select a logical block in Step169) (Step170: NO), the processing of Step164and beyond is carried out.

FIG. 17is a flowchart showing an example of the flash memory data recovery process in accordance with Method 3. According to Method 3, the storage controller4carries out a read in order from the start of the bad drive, and carries out a data restoration process for a location that could not be read.

The storage controller4acquires information denoting the block size from the bad drive (Step171).

Next, the storage controller4selects the first logical block of the bad drive as the process target (Step172).

Next, the storage controller4reads the data from the process-targeted logical block inside the bad drive (Step173).

In a case where the read fails (Step174: YES), the storage controller4carries out Steps175through177. That is, the storage controller4reads the data (either the user data or the parity data) included in the dataset including the data inside the process-targeted logical block selected in Step173from the other drives inside the RAID group including the bad drive (Step175). The storage controller4restores the missing data (the data inside the process-targeted logical block selected in Step173) by using the read data to carry out a parity operation (Step176). The storage controller4writes the restored data to the bad drive (Step177). In a case where this write fails (Step178: YES), the write error handling process (refer toFIG. 13) is carried out (Step179).

In the case of either Step174: NO or Step178: NO, the storage controller4selects the next logical block inside the bad drive as the process target (Step180). In a case where all the logical blocks have been processed (a case where it is not possible to select a logical block in Step180) (Step181: YES), this flash memory data recovery process ends. In a case where a logical block to be processed still remains (a case where it is possible to select a logical block in Step180) (Step181: NO), the processing of Steps173and beyond is carried out.

There are cases in which a free chunk will be unregistered from the free chunk list in line with insufficient free blocks or a flash chip43failure inside the drive5. For this reason, the capacity of the pool will decrease. When there are no longer any free chunks, physical chunk allocation becomes impossible, thereby raising the likelihood that data appended to a write request from the host computer2will not be able to be stored. It is preferable that the pool capacity be increased (the free chunks be increased) prior to this happening.

Accordingly, the storage controller4computes the pool utilization rate (=pool usage/pool capacity) when a free chunk is unregistered, and in a case where the calculated pool utilization rate exceeds a predetermined threshold, sends a warning to the management server3. Furthermore, the “pool capacity” is the total capacity of the physical chunks registered in the pool. The “pool usage” is the total capacity of the physical chunks allocated to the logical chunks from among the physical chunks registered in the pool. An opportunity of computing the pool utilization rate might also be the opportunity of increasing pool usage in addition to the above mentioned opportunity.

FIG. 18is a flowchart showing an example of the free chunk unregister process.

The storage controller4deletes the entry of the unregister-targeted physical chunk from the free chunk list31(Step191).

Next, the storage controller4subtracts the capacity of the unregistered physical chunk from the pool capacity (Step192).

Next, the storage controller4computes the pool utilization rate (Step193).

In a case where the calculated pool utilization rate exceeds a predetermined threshold (Step194: YES), the storage controller4sends a warning to the management server3(Step195).

In the storage system1, in a case where the data (the user data) of a plurality of drives is used to create parity data (for example, an error correction code) (for example, the case of a RAID 5 or a RAID 6), the following scheme is conceivable once the unmap region has been determined.

For example, it is supposed that parity data P1is created from certain user data D1, D2and D3, and the respective user data D1through D3and the parity data P1are stored in the four drives (a single RAID group). Further, it is supposed that in a case where the drive5receives a read instruction for an unmapped region, the data returned by this drive5is uncertain. Then, for example, there could be a case where only the area in which D1is stored is unmapped in accordance with the unmap request from the host computer2, and thereafter, the drive in which D2is stored fails. It is supposed that the storage controller4reads the user data D1and D3and the parity data P1from the three drives, and restores the user data D2at this time, but since the user data D1is uncertain, there is concern that erroneous data will be constructed.

Therefore, to maintain the integrity of the data, it is necessary to modify the unmap region such that the logical sector (the logical sector managed by the drive) in which the relevant dataset is stored is made the unmap target only in a case where the logical sector (the logical sector in the logical unit) in which all the user data included in the dataset is stored has been unmapped.

FIG. 19is a schematic diagram of an example of the modification of an unmap region. Furthermore, this drawing shows an example of a RAID 5 (3D+1P), but the same method may also be applied to another RAID type (the RAID level and/or the number of drives configuring the RAID group).

The RAID group storage space is configured by a plurality of rows of stripes. One row of stripes is configured from a plurality of stripes respectively corresponding to a plurality of drives configuring this RAID group. According to the example ofFIG. 19, one row of stripes is configured from four stripes. One stripe is based on one drive. Either user data or parity data is stored in each stripe.

An area corresponding to the plurality of stripes in which a plurality of user data that serves as the basis for the parity data is stored will be called the “parity cycle area” below. According to the example ofFIG. 19, since the parity data is created from three stripes, the size of the parity cycle area is three times the stripe size.

For example, in a case where the address range specified in the unmap request from the host computer2does not fit within the borders of the range of the parity cycle area, the storage controller4corrects this unmap region so that it fits within the borders of the parity cycle. That is, in a case where the unmap region specified by the host computer2is unmap region A, the drive5-specified unmap region B is from the first sector of the first parity cycle area inside the unmap region A to the last sector of the last parity cycle inside the unmap region A.

FIG. 20is a flowchart showing an example of an unmap region modification process.

First, the storage controller4corrects the start address so that this address matches the border of the parity cycle area (Step211). Specifically, when the start address of the unmap region specified by the host computer2is S and the size of the parity cycle area is P, the modified start address S′ is found using the following equation (1):
S′=int((S+(P−1))/P)×P(1)

In this regard, int (A) represents a maximum integer not exceeding A.

Next, the storage controller4corrects the end address such that it matches the border of the parity cycle area (Step212). Specifically, when the end address of the unmap region specified by the host computer2is E and the size of the parity cycle area is P, the modified end address E′ is found using the following equation (2):
E′=int((E+1))/P)×P−1  (2)

Next, the storage controller4selects as the sectors to be unmapped the sectors on each drive corresponding to the region from the modified start address S′ to the modified end address E′, and the sectors on each drive in which parity data corresponding to the data in this region is stored (Step213). The unmap instruction specifying the address corresponding to the sectors selected here is sent to the drive5from the storage controller4.

The flash memory data recovery process that is carried out when a flash chip43fails has been explained by referring toFIG. 14and so on, but in a case where the cause of the failure has been brought about by changes in the flash chip43over time (to include degradation resulting from block erasures) or is caused by common components inside the drive5, there is the danger of the failure reoccurring in a case where the restored data is stored in the bad drive5.

Accordingly, in a case where the failure of a flash chip43is other than random, the restored data may be stored in a different drive than the bad drive (for example, in a new drive such as a pre-mounted spare drive).

FIG. 21is a flowchart showing an example of a data recovery process.

In accordance with this data recovery process, a determination is made as to whether the already explained flash memory data recovery process should be carried out or whether a different process should be executed without carrying out this flash memory data recovery process.

First, the storage controller4determines whether or not the failure that occurred in the drive was a random failure of the flash chip43(Step221). Specifically, for example, the storage controller4determines that it was not a random failure in a case where the result of at least one of (X) and (Y) below is affirmative:(X) whether or not the erase count of the bad drive exceeded a predetermined threshold; and(Y) whether or not a fixed time period had elapsed since the date the bad drive was manufactured.

When the result of the determination of Step221is affirmative (Step221: YES), the above-described flash memory data recovery process (any of the processes ofFIGS. 15 through 17) is carried out (Step222).

By contrast, when the result of the determination of Step221is negative (Step221: NO), the storage controller4uses the data stored in the other drives inside the RAID group including the bad drive to restore all the data inside the bad drive, and writes the restored data to a new drive (Step223).

Now, according to the above explanation, there are a number of triggers for unmapping a physical block, but the present invention is not limited to the above-mentioned triggers, and other triggers are also applicable. For example, the present invention is not limited to the trigger of receiving an explicit request such as an unmap request from the host computer2, and the unmapping of a physical block may also be carried out upon receiving a non-explicit request signifying that data of a specific pattern (called “pattern data” below) is being written repeatedly. The non-explicit request referred to here may be an ordinary write request for the pattern data to be repeatedly written, or a write-same request (for example, a WRITE SAME command in a SCSI command) that clearly specifies the repeated writing of the pattern data. The write-same request causes a specified pattern data (for example, all 0-bits) to be written to the entire area that has been specified. For example, in a case where the storage controller4has decided to send back all 0-bit data relative to a read request specifying an address of a logical chunk to which a real chunk has not been allocated, the storage controller4is able to unmap a physical chunk when the data inside this physical chunk has become all 0-bits in accordance with the write-same request. The same is also possible for a block in a drive5. For example, the flash memory management information45may comprise the mapped sector bitmap58, but this mapped sector bitmap58may be omitted in a case where, instead of checking the mapped sector bitmap58in Step73, a check is executed as to whether or not the data inside the relevant block is all zeros.

According to this embodiment, free blocks are efficiently increased. Consequently, the efficiency of the wear-leveling can be expected to improve.

One embodiment of the present invention has been explained above, but this is merely an example for explaining the present invention, and does not purport to limit the scope of the present invention solely to this embodiment. The present invention may also be put into practice in a variety of other modes.

For example, the drive controller220may be disposed outside the drive5. In this case, the number of drive controllers220may be either larger or smaller than the number of flash packages230. Specifically, for example, one drive controller220may be provided for X number (where X is an integer of 2 or greater) of flash packages230. In accordance with this, one drive controller220will manage the corresponding relationships between the logical addresses and the physical addresses for each of X number of flash packages230.

Further, for example, a data migration (a data migration in chunk units) between RAID groups may be carried out without passing through the storage controller4. Specifically, for example, the storage controller4may notify the migration-source address and the migration-destination address to the drive controller220corresponding to the migration-source and/or the migration-destination, and may migrate the data inside the physical block allocated to the logical block corresponding to the migration-source chunk to the physical block allocated to the logical block corresponding to the migration-destination chunk between the drive controller220corresponding to the migration-source and the drive controller220corresponding to the migration-destination without going through the storage controller4.

REFERENCE SIGNS LIST