WO2014170984A1 - ストレージシステム及び記憶制御方法 - Google Patents

ストレージシステム及び記憶制御方法 Download PDF

Info

Publication number
WO2014170984A1
WO2014170984A1 PCT/JP2013/061485 JP2013061485W WO2014170984A1 WO 2014170984 A1 WO2014170984 A1 WO 2014170984A1 JP 2013061485 W JP2013061485 W JP 2013061485W WO 2014170984 A1 WO2014170984 A1 WO 2014170984A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
storage
fmpk
input
redundant code
Prior art date
Application number
PCT/JP2013/061485
Other languages
English (en)
French (fr)
Inventor
匡人 仁科
弘明 圷
講平 鑪
紀夫 下薗
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US14/241,784 priority Critical patent/US9122399B2/en
Priority to PCT/JP2013/061485 priority patent/WO2014170984A1/ja
Publication of WO2014170984A1 publication Critical patent/WO2014170984A1/ja
Priority to US14/828,912 priority patent/US9465561B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0658—Controller construction arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data

Definitions

  • the present invention relates to storage control of a storage system having a storage device capable of executing predetermined processing on data to be stored.
  • the storage controller controls the IO for the storage device that is the final storage device for data.
  • the cost for storing data has increased due to an increase in storage devices necessary for storing data. For this reason, reduction of the data retention cost in a storage system is required.
  • One of the technologies that answer this need is a technology that reduces the amount of data stored by compressing data stored in a storage device (for example, HDD (Hard Disk Drive) or SSD (Solid State Drive)). Due to the increase in data volume, data compression technology is required to be applied not only to backup volumes but also to volumes used in normal business (primary volumes).
  • Patent Document 1 discloses a technique in which a flash device performs data compression processing in order to reduce a data capacity stored in a flash device such as an SSD using a flash memory having a high bit cost as a storage medium. Is disclosed.
  • a RAID (Redundant Array of Independent Disks) group may be configured to generate parity (redundant code) for the purpose of speeding up IO processing and improving fault tolerance.
  • parity generation method in a RAID group there are a conventionally known method in which a controller of a storage system generates parity, and a method in which a storage device disclosed in Patent Document 2 generates parity.
  • the compression technique is applied to such a system, at the time of random writing, it is necessary to expand old data and old parity and compress new data and new parity for one host write. That is, since the compression / decompression process is performed twice, the performance deterioration rate is further increased.
  • a storage system includes a storage device having a storage medium for storing data, a device controller for executing an additional process involving a change in the data state on the data, and a storage for controlling input / output of data to the storage device And a controller.
  • the storage controller transmits to the storage device determination information that can be used to determine whether or not the device controller executes the additional processing in accordance with the input / output processing related to the input / output target data.
  • the device controller controls the execution of the addition process for the input / output target data based on the determination information transmitted from the storage controller.
  • the flash device determines whether or not compression processing is necessary based on information transmitted from the storage controller. As a result, the data storage amount can be reduced and the cost can be reduced, and the write performance can be improved as compared with the case where all data is compressed.
  • FIG. 1 is a hardware configuration diagram of the computer system according to the first embodiment.
  • FIG. 2 is a hardware configuration diagram of the FMPK according to the first embodiment.
  • FIG. 3 is a diagram illustrating an overview of parity generation processing during random writing according to the first embodiment.
  • FIG. 4 is a flowchart of parity generation processing during random writing according to the first embodiment.
  • FIG. 5 is a flowchart of the XDWRITE process according to the first embodiment.
  • FIG. 6 is a flowchart of the XDREAD process according to the first embodiment.
  • FIG. 7 is a flowchart of the XPWRITE process according to the first embodiment.
  • FIG. 8 is a diagram illustrating an overview of parity determination information registration processing according to the second embodiment.
  • FIG. 9 is a configuration diagram of an example of parity determination information according to the second embodiment.
  • FIG. 10 is a diagram illustrating an overview of RMW parity generation processing according to the second embodiment.
  • FIG. 11 is a diagram illustrating an overview of all stripe parity generation processing according to the second embodiment.
  • FIG. 12 is a flowchart of parity generation processing according to the second embodiment.
  • FIG. 13 is a flowchart of the READ process according to the second embodiment.
  • FIG. 14 is a flowchart of the WRITE process according to the second embodiment.
  • FIG. 15 is a diagram illustrating an outline of the collection copy process according to the second embodiment.
  • FIG. 16 is a flowchart of the collection copy process according to the second embodiment.
  • FIG. 17 is a diagram illustrating an overview of RMW parity generation processing when parity is generated using compressed data according to the third embodiment.
  • FIG. 18 is a diagram illustrating an overview of RMW parity generation processing when parity is generated using pre-compression data according to the third embodiment.
  • FIG. 19 is a diagram illustrating an overview of all stripe parity generation processing according to the third embodiment.
  • FIG. 20 is a configuration diagram of an example of an XDREAD / XDWRITE / XPWRITE command according to the third embodiment.
  • FIG. 21 is a flowchart of parity generation processing according to the third embodiment.
  • FIG. 22 is a flowchart of the RMW parity generation process according to the third embodiment.
  • FIG. 23 is a flowchart of the XDWRITE process according to the third embodiment.
  • FIG. 24 is a flowchart of the XDREAD process according to the third embodiment.
  • FIG. 25 is a flowchart of XPWRITE processing according to the third embodiment.
  • FIG. 26 is a diagram illustrating an outline of a collection copy process for a stripe column having parity generated using pre-compression data according to the third embodiment.
  • FIG. 27 is a diagram illustrating an outline of a collection copy process for a stripe column having parity generated using the compressed data according to the third embodiment.
  • FIG. 28 is a flowchart of the collection copy process according to the third embodiment.
  • FIG. 29 is a configuration diagram of an example of a READ / WRITE command according to the third embodiment.
  • FIG. 30 is a flowchart of the READ process according to the third embodiment.
  • FIG. 31 is a flowchart of the WRITE process according to the third embodiment.
  • FIG. 32 is a diagram illustrating an overview of the function execution determination information registration processing according to the fourth embodiment.
  • FIG. 33 is a diagram illustrating an overview of command processing according to the fourth embodiment.
  • FIG. 34 is a flowchart of command processing according to the fourth embodiment.
  • the process may be described using “program” as a subject, but the program is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process is appropriately performed. Since the processing is performed using a storage resource (for example, a memory) and / or a communication interface device (for example, a port), the subject of processing may be a program.
  • the processing described with the program as the subject may be processing performed by a processor or a computer having the processor (for example, a management computer, a host computer, a storage system, etc.).
  • the processor may include a hardware circuit that performs part or all of the processing performed by the processor.
  • the program may be installed in each controller from a program source.
  • the program source may be, for example, a program distribution server or a storage medium.
  • the storage system 10 may be an apparatus configured with a single housing, or may be configured in combination with an external storage apparatus 40.
  • the storage system 10 includes a plurality of storage devices such as an FMPK (Flash Memory Package) 160, for example.
  • FMPK Flash Memory Package
  • a RAID (Redundant Array of Independent Disks) group is configured using a plurality of storage devices.
  • each storage device is managed by being divided into sub storage areas called stripes. That is, each storage device includes a plurality of stripes.
  • the storage area of the RAID group is composed of a plurality of stripe columns. Each stripe column includes one stripe included in each storage device. That is, the stripe column straddles a plurality of storage devices constituting the RAID group.
  • RAID levels There are several levels of RAID (hereinafter referred to as (RAID levels)).
  • the write target data designated by the host computer 30 is divided into a plurality of data elements, and the plurality of data elements are written in a plurality of stripes of the same stripe column.
  • redundant information called “parity” (hereinafter referred to as “parity”) is used from a plurality of data elements included in a stripe column in order to restore data elements that cannot be read from the storage device due to a failure in the storage device.
  • “Redundant code”) is generated, and the redundant code is also written in the stripe of the same stripe column.
  • the stripe column includes three data elements and a parity generated from the three data elements.
  • the parity is also updated. Parity is generated by, for example, an XOR operation of a plurality of data elements included in the same stripe column.
  • the data element and the redundant code are not distinguished from each other, they may be referred to as stripe data elements.
  • RAID 6 two data elements of a plurality of data elements constituting a data unit are read due to a failure of two storage devices of a plurality of storage devices constituting a RAID group. If the two data elements cannot be restored, two types of redundant codes (P parity and Q parity) are generated for each data unit, and the redundant codes are the same. Written to the stripe in the stripe column.
  • RAID levels other than those described above (for example, RAID 1 to 4).
  • a triple parity technique using a triple mirror (Triplication) and three types of parity is also available.
  • the redundant code generation technique there are various techniques such as a Reed-Solomon code using Galois operation and EVEN-ODD.
  • RAID level is RAID 5 will be mainly described, but this is not intended to limit the present invention, and other RAID levels may be used. It can also be applied to.
  • the first method is a calculation method using all data elements in the stripe column (hereinafter referred to as “all stripe parity generation”).
  • the first method is used when the access pattern is a sequential write, for example, when all data elements included in the stripe column are updated.
  • the second method is to update data (new data) and data before update (old data, that is, data updated by new data), parity before update (old parity) for some data elements. (Hereinafter referred to as “RMW (Read Modify Write) parity generation”).
  • the second method is used when the access pattern is a random write, for example, when a part of data elements included in the stripe column is updated.
  • all stripe parity generation and RMW parity generation may be used separately in consideration of the load of the storage system.
  • RMW parity generation will be described with reference to FIG.
  • necessary data is read from the FMPK 160 into the CM 131 and the BE controller 142 or the MP 121 generates a redundant code (hereinafter referred to as conventional RMW), or a storage device such as the FMPK 160 generates a redundant code ( Hereinafter, there is an off-road RMW).
  • the storage controller 11 uses a command described below in addition to the conventional READ / WRITE command.
  • One is an XDWRITE command used to transfer data transmitted from the host computer 30 (hereinafter, new data) to the FMPK 160 and instruct the FMPK to generate parity.
  • the FMPK 160 that has received the XDWRITE command generates intermediate data using the transmitted new data and the data (old data) stored in the storage area of the FMPK 160 having the same address as the new data.
  • Another one is an XDREAD command used to read intermediate data generated by the FMPK 160.
  • the FMPK 160 Upon receiving the XDREAD command, the FMPK 160 transfers the intermediate data generated based on the XDWRITE command to the Buffer 143 of the BEPK 140. Another one is to generate a redundant code (new parity) corresponding to the new data based on the intermediate data and write it to the storage area of the storage address of the redundant code (old parity) so far XPWRITE command used for The FMPK 160 that has received the XPWRITE command generates a new parity using the transmitted intermediate data and the old parity stored in the FMPK 160, and stores the new parity at the corresponding address.
  • these commands include information that can specify whether the input / output target is user data or a redundant code, and are examples of determination information.
  • FIG. 1 is a hardware configuration diagram of the computer system according to the first embodiment.
  • the computer system includes one or more host computers (hereinafter referred to as hosts) 30, a management computer 20, and a storage system 10.
  • the host computer 30 and the storage system 10 are connected via a network 50.
  • the network 50 may be a local area network or a wide area network.
  • the management computer 20 and the storage system 10 are connected by an internal network 150.
  • one or more external storage devices 40 may be connected to the storage system 10 via the network 50.
  • the external storage device 40 includes one or more storage devices.
  • the storage device includes a nonvolatile storage medium such as a magnetic disk, a flash memory, and other semiconductor memories.
  • the host 30 is, for example, a computer that executes an application, and reads data used for the application from the storage system 10 and writes data created by the application to the storage system 10.
  • the management computer 20 is a computer used by an administrator for executing a management process for managing a computer system, and has an input device and a display device.
  • the management computer 20 accepts the RAID level setting for the RAID group by the operation of the administrator with respect to the input device, and performs settings for the storage system 10 so as to configure the RAID group at the accepted RIAD level.
  • the storage system 10 includes one or more front-end packages (FEPK) 100, one or more microprocessor packages (MPPK) 120, one or more cache memory packages (CMPK) 130, and one or more back-end packages (BEPK). 140, an internal network 150, and a plurality of flash packages (FMPK) 160.
  • the FEPK 110, MPPK 120, CMPK 130, and BEPK 140 are connected via the internal network 150.
  • the storage controller 11 is configured by the FEPK 110, the MPPK 120, the CMPK 130, and the BEPK 140.
  • the BEPK 140 is connected to the FMPK 160 through a plurality of paths.
  • the storage device connected to the BEPK 140 is a non-volatile storage medium, such as a magnetic disk, flash memory, other semiconductor memory (PRAM (phase change memory), ReRAM (resistance change memory), MRAM (magnetoresistance memory). ) Etc.).
  • PRAM phase change memory
  • ReRAM resistance change memory
  • MRAM magnetoresistance memory
  • the FEPK 100 is an example of an interface device, and includes one or more ports 101, an FE controller 112, and a buffer 113.
  • the port 101 connects the storage system 10 to various devices via the network 50 or the like.
  • the FE controller 112 controls communication with the host computer 30.
  • the MPPK 120 includes a microprocessor (MP) 121 as an example of a control device and a local memory (LM) 122.
  • the MP 121 and the LM 122 are connected via an internal bus 123.
  • the LM 122 stores various programs and various information.
  • the MP 121 executes a program stored in the LM 122 and executes various processes.
  • the MP 121 transmits various commands (for example, a SCSI READ command and a Write command) to the FMPK 160 via the BEPK 140. Further, the MP 121 transmits various commands to the external storage device 40 via the FEPK 100. In addition, an upper code generation process is performed.
  • the MP 121 For example, for a data unit of a RAID group configured with RAID 5, the MP 121 generates a redundant code (parity) by taking an exclusive OR (XOR) of a plurality of data elements constituting the data unit. In addition, for the data unit of the RAID group composed of RAID 6, the MP 121 further multiplies a plurality of data elements constituting the data unit by a predetermined coefficient, and then performs exclusive OR of the respective data. Thus, parity is generated. In addition, the MP 121 performs restoration processing for restoring any data element in the data unit based on one or more stripe data elements (at least one of the data element and the parity) for the data unit. Parity generation may be performed by the MP 121 executing a program, or a parity generation circuit may be used.
  • the CMPK 130 includes a cache memory (CM) 131 and a shared memory (SM) 132.
  • the CM 131 temporarily stores data (write data) to be written from the host 30 to the FMPK 160 and data read from the FMPK 160 (read data).
  • the SM 132 stores information shared by a plurality of MPPKs 120 when the MPPK 120 executes various processes.
  • the BEPK 140 has one or more ports 141, a BE controller 142, and a buffer 143.
  • the port 141 connects the storage system 10 and a storage device such as the FMPK 160.
  • the BE controller 142 is a processor, for example, and performs data transfer between the CMPK 130 and the FMPK 160.
  • the BEPK 140 may perform a redundant code generation process instead of the MP 121. In this case, the circuit for generating the redundant code may be in the BEPK 140 or may be separate from the BEPK 140.
  • Buffer 143 temporarily stores data transmitted from FMPK 160 and data transmitted to FMPK 160.
  • FMPK 160 stores data.
  • the FMPK 160 has a compression and expansion function for executing compression processing and expansion processing.
  • the data to be written can be compressed and stored in a compressed state. it can.
  • the data stored in the compressed state in the FMPK 160 can be expanded and transmitted to the BEPK 140.
  • the FMPK 160 may store the data in the flash chip 166 after compressing the data, or temporarily store the data in the flash chip 166 and store the data from the storage controller 11. Data may be read out from the flash chip 166 and compressed asynchronously with writing.
  • the storage controller 11 provides a logical volume to the host computer 30.
  • the logical volume is configured based on storage areas of a plurality of FMPKs 160 included in the RAID group.
  • a storage area is assigned to the entire logical address range of the logical volume.
  • the storage controller 11 can provide the host computer 30 with a virtual volume according to thin provisioning.
  • a virtual volume has a volume capacity defined at the stage of creation and an address range of the virtual volume is set, but no storage area is allocated.
  • the storage controller 11 receives a write request from the host computer 30, the storage controller 11 allocates a storage area of a predetermined size (hereinafter referred to as a chunk) to an area including an address specified by the virtual volume write request, and data accompanying the write request. Write.
  • the chunk is configured based on storage areas of a plurality of FMPKs 160 included in the RAID group.
  • the storage controller 11 manages a plurality of chunks using a pool.
  • the pool includes chunks based on a plurality of RAID groups.
  • the storage controller 11 when the storage controller 11 receives a write request for a virtual volume, the storage controller 11 selects a chunk from the pool and assigns it to the virtual volume. If it is a write request to an address range in which a chunk has already been allocated to the virtual volume, there is no need to allocate a new chunk.
  • the logical volume and the virtual volume may be collectively referred to as a volume.
  • FIG. 2 is a hardware configuration diagram of the FMPK according to the first embodiment.
  • the FMPK 160 has a package controller 168 and one or more flash chips 166.
  • the package controller 168 includes a buffer 161, a package memory 162, a package processor 163 as an example of a device controller, a compression / decompression circuit 164, a bus transfer device 165, a communication IF 167, and a parity generation circuit 169.
  • the communication IF 167 receives data transmitted from the BEPK 140.
  • the buffer 161 temporarily stores data transmitted from the BEPK 140 and data transmitted to the BEPK 140.
  • the package memory 162 stores various programs and various information.
  • the package processor 163 executes programs stored in the package memory 162 and executes various processes. For example, the package processor 163 causes the compression / decompression circuit 164 to execute data compression / decompression. Further, the package processor 163 causes the parity operation circuit 169 to generate parity (XOR operation). Further, the package processor 163 causes the bus transfer device 165 to execute data input / output with the flash chip 166.
  • the flash chip 166 is an example of a storage medium and is a flash memory chip.
  • the FMPK 160 provides a logical address space to the external device (storage controller 11). The storage controller 11 designates a logical address in the logical address space and transmits a read / write command or the like to the FMPK 160.
  • the flash memory is a nonvolatile semiconductor storage medium.
  • the flash memory chip 166 has a plurality of blocks as physical storage areas, and each block is a data erasing unit. Each block has a plurality of pages, and each page is a unit of data read / write.
  • the flash memory has a characteristic that it cannot be overwritten when data stored in a page is updated. For this reason, when updating data, the package processor 163 writes the data on a page (second page) different from the page (first page) where the data before update is stored. Here, the package processor 163 maps the logical address range mapped to the first page to the second page.
  • the package memory 162 stores conversion information (logical-physical mapping information) between the logical address and the physical page position (physical address).
  • processing in the FMPK 160 will be described with the package processor 163 as the main body, but it can also be said that the package controller 168 executes data transfer in the FMPK 160 and data compression / decompression processing.
  • FIG. 3 is a diagram illustrating an overview of parity generation processing during random writing according to the first embodiment.
  • the host computer 30 designates the volume number of the logical volume provided by the storage controller 11 and the address on the volume, and sends a write request with write data. It is assumed that this write request is for updating data (old data) already stored in the volume.
  • the MP 121 specifies the FMPK 160 that stores the data based on the volume number specified by the write request and the address on the volume from among the plurality of FMPKs 160 configuring the RAID group, and transmits the data to the FMPK 160.
  • the FMPK 160 executes the parity generation process that has been executed by the storage controller 11 in the past. As a result, the load on the MP 163 that has controlled the parity generation processing is reduced, and the processing performance of the entire storage system 10 is improved. Furthermore, as described below, the FMPK 160 determines whether or not data compression / decompression is necessary, thereby suppressing a decrease in performance of the FMPK 160 due to compression / decompression.
  • processing involving parity generation and data compression / decompression by the FMPK 160 will be described.
  • the MP 121 of the storage system 10 stores the write data (user data: hereinafter referred to as new D1) transmitted from the host 30 in the CM 131 of the CMPK 130 via the FEPK 100 (FIG. 3 (1)).
  • the MP 121 transfers the new D1 to the Buffer 143 of the BEPK 140 (FIG. 3 (2)).
  • the BE controller 142 issues an XDWRITE command to the FMPK 160 and transmits a new D1 (FIG. 3 (3)).
  • the XDrite command is transmitted by designating a logical address corresponding to the old data.
  • the FMPK 160 that has received the XDWRITE command stores the transmitted new D1 in the Buffer 161 (FIG. 3 (4)). Since the received command is the XDWRITE command, the package processor 163 determines that the received new D1 is user data, compresses the new D1 by the compression / decompression circuit 164, and stores it in the flash chip 166 (FIG. 3). (5)). Here, the data obtained by compressing the new D1 is referred to as a new cD1. The process of compressing the new D1 and storing it in the flash chip 166 may be performed asynchronously with the reception of the XDWRITE command.
  • the package processor 163 decompresses the data (hereinafter referred to as old cD1) obtained by compressing the data before update (old D1) corresponding to the new D1 stored in the flash chip 166 by the compression / decompression circuit 164.
  • the old D1 is acquired, and the old D1 is stored in the Buffer 161 ((6) in FIG. 3).
  • the package processor 163 generates intermediate data (hereinafter, referred to as intermediate D1 and intermediate parity) used to generate a parity (redundant code) of the stripe column including D1 from the new D1 and the old D1. (FIG. 3 (7)).
  • the package processor 163 generates an intermediate D1 by taking an exclusive OR of the new D1 and the old D1.
  • the MP 121 of the storage system 10 issues an XDREAD command to the FMPK 160, thereby reading the intermediate D1 from the FMPK 160 to the Buffer 143 of the BEPK 140 (FIG. 3 (8)).
  • the FMPK 160 that has received the XDREAD command reads the intermediate D1 from the Buffer 161 and transmits it to the BEPK 140, and the BE controller 142 receives the intermediate D1 and writes the intermediate D1 to the Buffer 143 of the BEPK 140.
  • the MP 121 of the storage system 10 identifies the intermediate D1 as the FMPK 160 in which the parity of the stripe column including D1 is stored, issues a XPWRITE command specifying the logical address corresponding to the old parity, and outputs the intermediate D1.
  • the FMPK 160 that has received the XPWRITE command stores the intermediate D1 in the Buffer 161 ((9) in FIG. 3). Since the received command is the XPWRITE command, the package processor 163 reads the parity (hereinafter referred to as old P) before updating the stripe column including the old D1 stored in the flash chip 166 to the Buffer 161 (FIG. 3 (10)). )).
  • the package processor 163 generates a parity (hereinafter, new P) corresponding to the new D1 using the intermediate D1 and the old P (FIG. 3 (11)).
  • the package processor 163 generates a new P by taking an exclusive OR of the intermediate D1 and the old P.
  • the package processor 163 determines that the received command is an XPWRITE command, the data generated based on this command is parity, and the generated data, that is, the new P is not compressed, and the flash chip It is stored in 166 (FIG. 3 (12)).
  • the parity is stored in the flash chip 166 without being compressed, the processing load on the FMPK 160 can be reduced. That is, the decompression process in the old P reading process (10) is unnecessary, and the compression process in the new P writing process (12) is not necessary.
  • the parity of the stripe column is updated. For this reason, the frequency of reading / writing parity is higher than that of user data, and the effect of suppressing performance degradation by not performing the accompanying compression / decompression processing is great.
  • the storage capacity used in the storage system 10 can be suppressed.
  • the intermediate parity is data that is used for generating a new parity, but becomes unnecessary when the new parity is stored in the flash chip 166. If the intermediate parity is stored on the buffer and a new parity is generated, the intermediate parity need not be stored in the flash chip 166. For this reason, the necessity to compress the intermediate parity is small, and the package processor 163 can reduce the overhead due to the compression processing by not compressing the intermediate parity.
  • This embodiment is effective for parity generation processing in random writing when data is compressed. For example, in OLTP with a relatively large number of random writes, it is possible to achieve both the cost reduction effect by data compression and the suppression of performance degradation by compression.
  • FIG. 4 is a flowchart of parity generation processing during random writing according to the first embodiment.
  • Parity generation processing at the time of random writing is to generate parity necessary for data update when storing write data transferred from the host 30 stored in the CM 131 by the MP 121 in a storage device such as the FMPK 160. Executed to do.
  • the MP 121 detects write data (new data) for which parity generation has not been performed from the CM 131 (S41).
  • the MP 121 reserves an area in the Buffer 143 of the BEPK 140 in order to transfer the new data to the FMPK 160, and stores the new data therein (S42).
  • the MP 121 executes an XDWRITE command with respect to the FMPK 160 (data FMPK) that stores the pre-update data (old data) corresponding to the new data (S43).
  • the data FMPK that has received the XDWRITE command executes the XDWRITE process (see FIG. 5), performs an XOR operation using the old data and the new data, and generates intermediate data for generating parity.
  • And stored in the Buffer 161 of the FMPK 160 Details of the XDWRITE process will be described later.
  • the MP 121 secures an area in the Buffer 143 in order to acquire intermediate data from the FMPK 160 (S44).
  • the MP 121 executes an XDREAD command for the data FMPK (S45).
  • the data FMPK that has received the XDREAD command executes the XDREAD process (see FIG. 6) and transmits intermediate data to the BEPK 140.
  • intermediate data is stored in the Buffer 143 of the BEPK 140. Details of the XDREAD process will be described later.
  • the MP 121 issues an XPWRITE command to the FMPK 160 (parity FMPK) storing the parity of the stripe column corresponding to the new data, and transmits the intermediate data stored in the Buffer 143 (S46).
  • the generation process ends. Note that, in the parity FMPK that has received the XPWRITE command, an XPWRITE process (see FIG. 7) for generating a parity based on the intermediate data is executed. Details of the XPWRITE process will be described later.
  • FIG. 5 is a flowchart of the XDWRITE process according to the first embodiment.
  • the XDWRITE process is executed when the FMPK 160 receives an XDWRITE command from the MP 121.
  • the package processor 163 of the FMPK 160 stores the write data (new data) transferred by the MP 121 in the Buffer 161 (S52).
  • the package processor 163 determines that the target data (new data) from the XDWRITE command is user data, and stores the old data (old data) corresponding to the write data stored in the flash chip 166. Is compressed by the compression / decompression circuit 164 (S53).
  • the package processor 163 stores the decompressed old data in the Buffer 161 (S54).
  • the package processor 163 performs an XOR operation on the new data and the old data to generate intermediate data (S55).
  • the package processor 163 determines that the target data (new data) from the XDWRITE command is user data, and compresses the new data by the compression / decompression circuit 164 (S56).
  • the package processor 163 stores the compressed new data in the flash chip 166 (S57).
  • Data compression / decompression processing may be performed by the package processor 163 without using the dedicated compression / decompression circuit 164. Further, the XOR operation may be performed using a dedicated circuit.
  • FIG. 6 is a flowchart of the XDREAD process according to the first embodiment.
  • the XDREAD process is executed when the FMPK 16 receives an XDREAD command from the MP 121.
  • the package processor 163 of the FMPK 160 determines whether there is intermediate data in the area of the Buffer 161 corresponding to the address specified by the XDREAD command (S62). As a result, when the intermediate data exists (S62: Yes), the package processor 163 returns the intermediate data of Buffer 161 to the MP 121, and ends the XDREAD process. On the other hand, if there is no intermediate data (S62: No), an abnormal end response is returned to the MP 121 (S64), and the XDREAD process is terminated.
  • FIG. 7 is a flowchart of the XPWRITE process according to the first embodiment.
  • the XPWRITE process is executed when the FMPK 160 receives an XPWRITE command from the MP 121.
  • the package processor 163 of the FMPK 160 stores the intermediate data transferred by the MP 121 in the Buffer 161 (S72).
  • the package processor 163 expands the old redundant code (old parity) from the flash chip 166. Instead, it is stored in Buffer 161 (S73).
  • the package processor 163 generates a new parity by performing an XOR operation on the intermediate data and the old parity (S74).
  • the package processor 163 stores the generated new parity in the flash chip 166 without compressing it. (S75).
  • the storage device can grasp whether or not the data to be input / output is a redundant code from the type of command issued from the storage controller 11, and is a redundant code.
  • input / output target data can be stored in a storage medium without being compressed. For this reason, the processing load of the storage device at the time of random writing can be reduced, and the random writing performance can be improved. Further, since the storage device creates a redundant code, the processing load on the storage controller 11 can be reduced.
  • compression / decompression processing is taken as an example of additional processing executed by the storage device.
  • the additional processing is not limited to this, and processing for changing the state of input / output data, input / output targets, etc.
  • a process of adding predetermined data (guarantee code or the like) to the data may be performed.
  • the addition process may be an encryption process for encrypting input target data.
  • whether or not to execute the process for determining whether or not to execute the additional process may be turned ON / OFF according to an instruction from the management computer 20.
  • the computer system according to the second embodiment is basically the same as the computer system according to the first embodiment shown in FIG.
  • the storage controller 11 transfers determination information for determining whether or not the code is a redundant code to the storage device (for example, FMPK16), and the determination information transferred from the storage controller 11 is also included. Whether the storage device is a redundant code or not is determined.
  • FIG. 8 is a diagram illustrating an overview of the parity determination information registration processing according to the second embodiment.
  • Parity determination information registration processing is executed in the storage system 10 before IO processing is executed by the host 30, for example.
  • the parity determination information 124 (see FIG. 9) is created in advance and stored in the LM 122, for example.
  • the MP 121 of the MPPK 120 of the storage controller 11 transfers the parity determination information 124 stored in the LM 122 to each FMPK 160. Note that the parity determination information 124 transmitted to each FMPK 160 only needs to include information about the area managed by the FMPK 160.
  • the FMPK 160 stores the transferred parity determination information 124 in the package memory 162 (FIG. 8 (1)).
  • the parity determination information 124 is used to determine whether or not the target data of the IO command is a redundant code when an IO command is issued to the FMPK 160.
  • FIG. 9 is a configuration diagram of an example of parity determination information according to the second embodiment.
  • Parity determination information 124 is information indicating whether or not the data of this stripe is a redundant code for each stripe address of the logical volume (logical VOL).
  • the parity determination information 124 includes an address field 124a and an attribute field 124b.
  • the address field 124a stores the start address for each fixed size (stripes) from the beginning to the end of the logical volume. Note that the start address and the end address of the stripe may be stored in the address field 124a.
  • the attribute field 124b stores a value indicating whether or not the data stored in the stripe corresponding to the head address of the address field 124a is a redundant code. For example, when the data stored in the stripe is user data, “data” is stored in the attribute field 124b, and when the data stored in the stripe is a redundant code, the attribute field 124b. Stores “parity”.
  • the parity determination information may have entries for a plurality of stripes in a partial area of the logical VOL, and the number of repetitions thereof, instead of having an entry for the entire logical VOL stripe.
  • the parity determination information 124 is transmitted from the storage controller 11 to the FMPK 160.
  • the storage controller 11 notifies the RAID configuration and the drive position in the RAID configuration, and the FMPK 160 is based on the RAID configuration and the drive position.
  • the parity determination information 124 may be generated.
  • the parity determination information 124 (for the IO command or the transfer data targeted by the IO command when the IO command is issued is not registered in advance in the FMPK 160 from the storage controller 11. Alternatively, only the information of the area corresponding to the IO command target) may be embedded and notified to the FMPK 160.
  • FIG. 10 is a diagram illustrating an outline of RMW parity generation processing according to the second embodiment.
  • the MP 121 of the storage system 10 stores the write data (hereinafter, new D1) received from the host 30 in the CM 131 of the CMPK 130 via the FEPK 100 (FIG. 10 (1)).
  • the MP 121 issues a READ command for reading old data (hereinafter referred to as old D1) stored at the same address as the new D1 to the FMPK 160 and reads the old D1 (FIGS. 10 (2), (3), (4 )).
  • old D1 old data
  • the FMPK 160 that has received the READ command determines whether or not the old D1 is a redundant code based on the parity determination information 124 stored in the package memory 162.
  • the FMPK 160 determines that the old D1 is compressed and stored in the flash chip 166.
  • the data obtained by compressing the old D1 is referred to as the old cD1.
  • the FMPK 160 decompresses the old cD1 stored in the flash chip 166 by the compression / decompression circuit 164 to acquire the old D1 (FIG. 10 (2)), and stores the old D1 in the Buffer 161 (FIG. 10 (3)). Then, the data is transferred to the Buffer 143 of the BEPK 140 designated by the READ command ((4) in FIG. 10).
  • the MP 121 issues a READ command for reading a redundant code (hereinafter referred to as old P) corresponding to the old D1 to the FMPK 160 storing the old P, and reads the old P (FIG. 10 (5), (6 )).
  • old P a redundant code
  • the FMPK 160 that has received the READ command determines from the parity determination information 124 that the old P is a redundant code, and determines that the old P is stored in the flash chip 166 without being compressed.
  • the FMPK 160 stores the old P from the flash chip 166 in the Buffer 161 without decompressing it (FIG. 10 (5)), and transfers it to the Buffer 143 of the BEPK 140 designated by the READ command (FIG. 10 (6)).
  • the MP 121 reads the data (old D, old P) stored in the buffer 143 by the FMPK 160 into the CMPK 130 (FIG. 10 (7)), and performs an XOR operation on the new D1, old D1, and old P. Then, a new redundant code (new P) corresponding to the new D1 is generated and stored in the CMPK 130 (FIG. 10 (8)).
  • the MP 121 transfers the new P of the CMPK 130 to the Buffer 143 of the BEPK 140 (FIG. 10 (9)), and issues a WRITE command to the FMPK 160 (FIG. 10 (10)).
  • the FMPK 160 that has received the WRITE command stores the new P in the Buffer 161.
  • the FMPK 160 determines from the parity determination information 124 that the new P is a redundant code, and determines that the new P is stored in the flash chip 166 without being compressed.
  • the FMPK 160 takes out the new P from the buffer 161, and stores it in the flash chip 166 without compression (FIG. 10 (11)).
  • FIG. 11 is a diagram illustrating an overview of all stripe parity generation processing according to the second embodiment.
  • the all stripe parity generation process is a process for generating a redundant code that is executed when all data in the stripe column is stored in the CMPK 130.
  • the MP 121 of the storage system 10 stores the write data received from the host 30 (hereinafter referred to as new D1 to new Dn) in the CM 131 of the CMPK 130 via the FEPK 100 (FIG. 11 (1)).
  • the MP 121 generates a redundant code (new P) corresponding to the write data by performing an XOR operation using all the data (new D1 to new Dn) constituting the same stripe column, and stores it in the CMPK 130 ( FIG. 11 (2)).
  • the MP 121 issues a WRITE command for writing the new P to the FMPK 160 via the BEPK 140 (FIG. 11 (3)).
  • the FMPK 160 that has received the WRITE command stores the new P in the buffer 161.
  • the FMPK 160 determines from the parity determination information 124 that the new P is a redundant code, and determines to store the new P in the flash chip 166 without compression.
  • the FMPK 160 stores the new P in the flash chip 166 without compressing it (FIG. 11 (4)).
  • FIG. 12 is a flowchart of parity generation processing according to the second embodiment.
  • the redundant code generation method is changed depending on whether or not all data in the same stripe column is available.
  • the all stripe write parity generation processing shown in FIG. 11 is performed.
  • the RMW parity generation process shown in FIG. 10 is performed.
  • the MP 121 detects data before parity generation (hereinafter, new D) from the CMPK 130 (S121). Next, the MP 121 determines whether all the data of the stripe column to which the new D belongs are stored in the CMPK 130 (S122).
  • the MP 121 secures an area for storing the redundant code (new P) corresponding to the new D in the CMPK 130. (S129).
  • the MP 121 generates a new P by performing an XOR operation on all the data in the stripe column to which the new D belongs in the CMPK 130, and stores it in an area secured by the CMPK 130 (S130).
  • the MP 121 secures an area for the new P in the Buffer 143 of the BEPK 140, and stores the new P in that area (S131).
  • the MP 121 issues a WRITE command for writing the new P to the FMPK 160 storing the redundant code corresponding to the stripe column (S132).
  • the FMPK 160 executes the WRITE process (see FIG. 14) and stores the new P.
  • the MP 121 sets an area for storing the data before the new D update (hereinafter referred to as the old D) as the CMPK 130 and It secures to Buffer 131,143 of BEPK140 (S123).
  • the MP 121 issues a READ command for reading the old D to the FMPK 160 in which the old D is stored (S124).
  • the FMPK 160 executes the READ process (see FIG. 13), and the old D is stored in the Buffers 131 and 143 of the CMPK 130 and the BEPK 140.
  • the MP 121 secures an area for storing a redundant code (hereinafter referred to as old P) corresponding to the old D in the Buffers 131 and 143 of the CMPK 130 and BEPK 140 (S125).
  • old P a redundant code
  • the MP 121 issues a READ command for reading the old P to the FMPK 160 in which the old P is stored (S126).
  • the FMPK 160 executes the READ process (see FIG. 13), and the old P is stored in the Buffers 131 and 143 of the CMPK 130 and the BEPK 140.
  • the MP 121 secures an area for storing the new P in the CMPK 130 (S127).
  • the MP 121 generates a new P by performing an XOR operation on the new D, the old D, and the old P, and stores them in the reserved area (S128).
  • the MP 121 secures an area for storing the new P in the Buffer 143 of the BEPK 140 (S131).
  • the MP 121 issues a WRITE command for writing the new P to the FMPK 160 storing the redundant code corresponding to the stripe column (S132).
  • the FMPK 160 executes the WRITE process (see FIG. 14) and stores the new P.
  • FIG. 13 is a flowchart of the READ process according to the second embodiment.
  • the READ process is a process executed by the FMPK 160 that has received the READ command.
  • the FMPK 160 When the FMPK 160 receives the READ command (S141), whether the READ target is a redundant code (parity) using the parity determination information 124 stored in the package memory 162 and the READ target address in the READ command. Is determined (S142).
  • the FMPK 160 uses the flash package 166 because the READ target is not a redundant code. Is compressed and stored, and the READ target data is expanded via the compression / decompression circuit 164 (S143). Next, the FMPK 160 stores the decompressed READ target data in the Buffer 161 (S144), and transmits the data to the BEPK 140 (S145).
  • the FMPK 160 determines that the READ target is a redundant code and is stored in the flash package 166 without being compressed. Are stored in the buffer 161 without being expanded from the flash chip 166 (S144). Next, the FMPK 160 transmits the redundancy code to be read by the Buffer 161 to the BEPK 140 (S145).
  • This READ process eliminates the need for decompression when reading redundant codes, and reduces the processing load on the storage device.
  • FIG. 14 is a flowchart of the WRITE process according to the second embodiment.
  • the WRITE process is a process executed by the FMPK 160 that has received the WRITE command.
  • the FMPK 160 when the FMPK 160 receives a WRITE command (S151), it stores WRITE target data (user data or redundant code) in the Buffer 161 (S152). Next, the FMPK 160 uses the parity determination information 124 stored in the package memory 162 and the WRITE target address in the WRITE command to determine whether the WRITE target data is a redundant code (S153). ).
  • the FMPK 160 stores the data in the flash package 166 because the WRITE target is not a redundant code. It is determined that the data is compressed and stored, the WRITE target data is compressed via the compression / decompression circuit 164 (S154), and the WRITE target data is stored in the flash chip 166 (S155).
  • the FMPK 160 determines that the WRITE target is a redundant code and stores it in the flash package 166 without compression, and compresses the redundant code. Instead, the data is stored in the flash chip 166 (S155).
  • This WRITE process eliminates the need for compression when writing redundant codes, and reduces the processing load on the storage device.
  • FIG. 15 is a diagram illustrating an outline of the collection copy process according to the second embodiment.
  • the collection copy process is a process executed to restore data stored in the failed storage device when a part of the storage device constituting the RAID group fails.
  • the MP 121 issues to each FMPK 160 a READ command for reading data (hereinafter referred to as D2 to Dn) and a redundant code (hereinafter referred to as P) in a stripe column including data to be restored (hereinafter referred to as D1).
  • D2 to Dn and P are obtained from the FMPK 160 and stored in the CMPK 130 (FIGS. 15 (1) to (5)).
  • the MP 121 restores D1 by performing an XOR operation on the data (D2 to Dn) and P stored in the CMPK 130 (FIG. 15 (6)).
  • the MP 121 issues a WRITE command for writing D1 to the spare FMPK 160 for storing D1 (FIGS. 15 (7) and (8)).
  • the FMPK 160 executes the WRITE process, and D1 is compressed and stored in the flash chip 166 (FIG. 15 (9)).
  • the READ process and the WRITE process executed by the FMPK 160 upon receipt of a READ / WRITE command issued in the collection copy process are as shown in FIGS.
  • FIG. 16 is a flowchart of the collection copy process according to the second embodiment.
  • FIG. 16 is a flowchart for realizing the collection copy process shown in FIG.
  • the MP 121 registers the parity determination information 124 in the spare FMPK 160 by the method shown in FIG. 8 (S161).
  • the MP 121 secures an area for storing the data of the stripe column and the redundant code in the Buffer 143 of the BEPK 140 and the CMPK 130 (S162).
  • the MP 121 removes data (hereinafter referred to as D2 to Dn) and redundant code (hereinafter referred to as P) of a certain stripe column to be processed, excluding data (hereinafter referred to as D1) stored in the FMPK 160 where the failure occurred.
  • a READ command for READ is issued to each FMPK 160 (S163).
  • the FMPK 160 executes the READ process (see FIG. 13), and D2 to Dn and P are stored in the Buffers 131 and 143 of the CMPK 130 and the BEPK 140.
  • the MP 121 restores D1 stored in the failed FMPK 160 by performing an XOR operation on D2 to Dn and P (S164).
  • the MP 121 secures and stores an area for storing D1 in the Buffer 143 of the BEPK 140 (S165).
  • the MP 121 issues a WRITE command to write D1 restored to the spare FMPK 160 (S166).
  • the FMPK 160 executes the WRITE process (see FIG. 14), and D1 is stored in the flash chip 166.
  • the MP 121 determines whether or not the data of the last area of the failed FMPK 160 has been restored (S167). As a result, when the last area has not been restored (S167: No), the MP 121 changes the processing target to the next area (S168), and performs the processing of S162 to S167 for the processing target area. . On the other hand, when restoring to the last area (S167: Yes), the MP 121 ends the collection copy process.
  • the compression process is described as an example of the additional process executed by the storage device.
  • the additional process may be an encryption process.
  • whether or not to execute the process for determining whether or not to execute the additional process may be turned ON / OFF according to an instruction from the management computer 20.
  • the computer system according to the third embodiment is basically the same as the computer system according to the first embodiment shown in FIG.
  • the storage controller 11 transfers determination information for determining whether the code is a redundant code to the storage device (for example, FMPK16), and the determination information and command transferred from the storage controller 11 Whether the storage device is a redundant code or not is determined based on the type.
  • the method for determining the redundant code may be any method described in the first or second embodiment.
  • a redundant code is generated for the compressed data, not only the redundant code but also the data is restored in the restoration process (hereinafter referred to as rebuild) when any of the storage devices that make up the RAID group fails.
  • the data (more precisely, the compressed data stored in the flash chip 166) can be restored without compression / decompression, and the rebuild process can be speeded up.
  • FIG. 17 is a diagram illustrating an outline of RMW parity generation processing when parity is generated using compressed data according to the third embodiment.
  • the MP 121 stores the old redundant code (old P) of the stripe column corresponding to the new D1 in the compressed data from the FMPK 160 storing the redundant code of the stripe column corresponding to the WRITE data (hereinafter referred to as the new D1).
  • Parity generation trigger information (generation trigger information) indicating whether or not it has been created is acquired (FIG. 17 (1), (2)).
  • the MP 121 determines whether it is a redundant code created for the compressed data based on the acquired information. In the example of FIG. 17, it is determined that the old P is a redundant code created for the compressed data.
  • the MP 121 issues an XDWRITE command to the FMPK 160 for the new D1 (FIG. 17 (3)).
  • the MP 121 gives information instructing to generate a redundant code for the compressed data to the XDWRITE command (hereinafter, instructing to generate a redundant code for the compressed data) (The command to which information is assigned is described with (RAW) added after the command name.)
  • the FMPK 160 that has received the XDWRITE (RAW) command stores the new D1 in the Buffer 161.
  • the FMPK 160 stores the compressed data (hereinafter referred to as old cD1) of the data before update of the new D1 (hereinafter referred to as old D1) from the flash chip 166 to the Buffer 161 (FIG. 17 (4)).
  • the FMPK 160 compresses the new D1 by the compression / decompression circuit 164 to generate compressed data (new cD1), and stores the new cD1 in the flash chip 166 (FIG. 17 (5)).
  • the FMPK 160 stores the new cD1 in the Buffer 161 (FIG. 17 (6)).
  • the FMPK 160 inserts padding (pad in the figure) to match the sizes of the new cD1 and the old cD1 (FIG. 17 (7)).
  • a method of generating data with padding it may be generated by overwriting a new cD1 in an area of a predetermined length in which a padding value (for example, 0) is stored in advance,
  • the FMPK 160 may generate the padding value for the new cD1, or may be added at the time of transfer by hardware such as the bus transfer device 165.
  • any method may be used to generate data with padding.
  • the FMPK 160 generates intermediate data (intermediate cD1) for generating a redundant code by performing an XOR operation of the new cD1 and the old cD1 with the same data size by padding (FIG. 17 (8)). ).
  • the FMPK 160 attaches the size information (SizeD1) of the new cD1 to the intermediate cD1 and stores it in the Buffer 161 (FIG. 17 (9)).
  • the size information may be embedded in the data or in the command.
  • the size information is stored for each compressed block unit. Instead of adding size information, a terminal symbol may be embedded at the end of each compressed block unit of data (new cD1).
  • the MP 121 issues an XDREAD (RAW) command to the FMPK 160 and reads the intermediate cD1 into the Buffer 143 of the BEPK 140 (FIG. 17 (10)).
  • the MP 121 issues an XPWRITE (RAW) command to the FMPK 160 that stores the parity of the stripe column corresponding to D1 (FIG. 17 (11)).
  • the FMPK 160 Upon receiving the XPWRITE (RAW) command, the FMPK 160 stores the intermediate cD1, SizeD1, and parity generation trigger information transferred by the XPWRITE command in the Buffer 161.
  • the FMPK 160 reads into the buffer 161 the redundant code (old P) corresponding to the old D1 and the size information (Size) of each data in the parity stripe assigned to the redundant code (FIG. 17 (12)).
  • the FMPK 160 puts padding for each compressed block of the intermediate cD1 to make the size of the old P uniform (FIG. 17 (13)).
  • the FMPK 160 generates a redundant code (hereinafter, new P) corresponding to the new D1 by performing an XOR operation on the intermediate cD1 and the old P having the same size (FIG. 17 (14)).
  • the FMPK 160 updates the size information corresponding to D1 in the Size based on SizeD1 and assigns it to the new P, and information (post) indicating that the parity has been generated after compression as parity generation trigger information.
  • the new P is given and stored in the flash chip 166 (FIGS. 17 (15) and (16)).
  • the size and parity generation trigger information to be added to the redundant code may be embedded in the data, may be held as information corresponding to the address in the package memory 162, or held as information corresponding to the address in the LM 122 of the MPPK 120. May be.
  • FIG. 18 is a diagram illustrating an outline of RMW parity generation processing when parity is generated using pre-compression data according to the third embodiment. Since the RMW parity generation process has the same part as the parity generation process of the first embodiment shown in FIG. 3, the description of the same part will be omitted and only the difference will be described.
  • the MP 121 acquires the parity generation trigger information of the redundant code (old P) corresponding to the new D1 from the FMPK 160 in order to determine the parity generation trigger (FIGS. 18 (1) and (2)).
  • the MP 121 determines whether it is a redundant code created for the compressed data based on the acquired information. In the example of FIG. 18, it is determined that the old P is a redundant code created for data before compression.
  • the MP 121 issues an XDWRITE command and an XDREAD command to the FMPK 160 in the same manner as in the example of FIG. 3, and acquires the intermediate D1 (FIGS. 18 (3) to (8)).
  • the MP 121 gives parity generation trigger information (before compression) to the intermediate D1, and issues an XPWRITE command to the FMPK 160 ((9) in FIG. 18).
  • the FMPK 160 that has received the XPWRITE command generates a new P as in the example of FIG. 3 (FIG. 18 (10)).
  • the FMPK 160 attaches parity generation trigger information (before compression) to the new P and stores it in the flash chip 166 (FIGS. 18 (11) and (12)).
  • FIG. 19 is a diagram illustrating an overview of all stripe parity generation processing according to the third embodiment.
  • the all-strip parity generation process according to the third embodiment has the same part as the all-strip parity generation process shown in FIG. 11, and thus description of the same part is omitted, and only the difference is described.
  • the MP 121 generates a new P as in FIG. 11 (FIGS. 19 (1) and (2)).
  • the MP 121 WRITEs the FMPK 160 by issuing a WRITE command (WRITE (D) in FIG. 19) for writing the new D1 to the new Dn to the FMPK 160 (FIG. 19 (3)).
  • the FMPK 160 attaches parity generation trigger information (before compression: pre) to the new P, and issues a WRITE command (WRITE (P) in FIG. 19) to write this data to the FMPK 160 (FIG. 19).
  • the WRITE process In the FMPK 160 that has received the WRITE command, the WRITE process is executed, and the new P to which the parity generation opportunity information is added is stored in the flash chip 166 (FIG. 19 (5)).
  • FIG. 20 is a configuration diagram of an example of an XDREAD / XDWRITE / XPWRITE command according to the third embodiment.
  • the command 170 of the XDREAD / XDWRITE / XPWRITE command includes a command type 170a, an LBA 170b, a transfer length 170c, a parity generation opportunity 170d, a number of compressed blocks 170e, and a compressed block size 170f.
  • the command type 170a indicates the type of command. For example, XDREAD, XDWRITE, or XPWRITE is set as the command type.
  • the LBA 170b is a logical block address of the logical VOL.
  • the transfer length 170c is the length of data transferred by a command.
  • the parity generation opportunity 170d is parity generation opportunity information indicating whether to generate parity for the compressed data or to generate parity for the uncompressed data.
  • the parity generation opportunity 170d is set to “post-compression (post)” when generating parity for data after compression, and “pre-compression” when generating parity for data before compression. (Pre) ".
  • the number of compressed blocks 170e is a field that is valid only when the parity generation opportunity 170d is “after compression”, and is a value indicating the number of compressed blocks included in the data to be transferred.
  • the compressed block size 170f is a valid field only when the parity generation opportunity 170d is “after compression”, and the command 170 has the compressed block size 170f as many as the number of compressed blocks.
  • Each compressed block size 170 is a size after compression of each compressed block. Note that the parity generation opportunity 170d, the number of compressed blocks 170e, and the compressed block size 170f may be embedded in data instead of a command.
  • FIG. 21 is a flowchart of parity generation processing according to the third embodiment.
  • symbol is attached
  • the MP 121 determines whether or not all the data in the stripe column to which the data for which parity is generated belongs are prepared (S122). As a result, when all the data in the stripe column is not complete (S122: No), the RMW parity generation process (see FIG. 22) is executed (S212), and the process is terminated. On the other hand, when all the data in the stripe column is available (S122: Yes), the MP 121 generates a new P as in FIG. 12 (S129 to S131), and parity generation trigger information (before compression) in the new P Is given (S211). Next, the MP 121 issues a WRITE command to the FMPK 160 (S132) and ends the process.
  • FIG. 22 is a flowchart of the RMW parity generation process according to the third embodiment. Note that portions similar to those in the parity generation processing illustrated in FIG.
  • the MP 121 obtains parity generation opportunity information from the FMPK 160 storing the redundant code, and determines which is the parity generation opportunity (S221).
  • the MP 121 issues an XDWRITE command to the FMPK 160 (S43).
  • parity generation trigger information indicating that the parity generation trigger is after compression is added to the XDWRITE command.
  • the MP 121 issues an XDREAD (RAW) command for reading the intermediate data to the FMPK 160 (S45).
  • the MP 121 adds parity generation trigger information (after compression) to the intermediate data that has been read (S227).
  • the MP 121 issues an XPWRITE (RAW) command to the FMPK 160 (S47).
  • the MP 121 issues an XDWRITE command to the FMPK 160.
  • information that the parity generation trigger is before compression is added to the command (S43).
  • the MP 121 issues an XDREAD (CMP) command for reading the intermediate data from the FMPK 160 (S45).
  • CMP XDREAD
  • the MP 121 adds parity generation trigger information (before compression) to the intermediate data that has been read (S222).
  • the MP 121 issues an XPWRITE (CMP) command to the FMPK 160 (S47).
  • FIG. 23 is a flowchart of the XDWRITE process according to the third embodiment.
  • symbol is attached
  • the XDWRITE process is a process executed when the FMPK 160 receives an XDWRITE command.
  • the FMPK 160 receives an XDWRITE command
  • the FDK 160 executes a process on the assumption that the target of the command is not a redundant code.
  • the FMPK 160 After receiving the XDWRITE command (after S51 and S52), the FMPK 160 determines which is the parity generation trigger for the data targeted by the XDWRITE command (S231).
  • the FMPK 160 executes the processing of steps S53 to S57, and ends the XDWRITE processing.
  • the FMPK 160 obtains compressed data (hereinafter referred to as new cD1) obtained by compressing the new D1 via the compression / decompression circuit 164 (S232).
  • the cD1 is stored in the flash chip 166 (S233).
  • the FMPK 160 reads the new cD1 from the flash chip 166 into the Buffer 161 (S234).
  • the FMPK 160 stores the old data after compression (old cD1) in the Buffer 161 (S235).
  • the FMPK 160 puts padding for each compressed block, and aligns the data sizes of the new cD1 and the old cD1 (S236).
  • the FMPK 160 generates intermediate data (hereinafter, intermediate cD1) by performing an XOR operation on the new cD1 and the old cD1 having the same size (S237).
  • the FMPK 160 gives the size information after compression of each compressed block in the new cD1 to the intermediate cD1 (S238), and ends the XDWRITE process.
  • FIG. 24 is a flowchart of the XDREAD process according to the third embodiment.
  • symbol is attached
  • the XDREAD process is a process that is executed when the FMPK 160 receives an XDREAD command.
  • the FMPK 160 receives an XDREAD command
  • the FDK 160 executes a process on the assumption that the target of the command is not a redundant code.
  • the FMPK 160 determines which is the parity generation trigger (S241).
  • the FMPK 160 executes the process of step S63 and ends the XDREAD process.
  • the FMPK 160 transmits the intermediate data of the Buffer 161 and the size information added to the intermediate data to the MP 121 (S242).
  • FIG. 25 is a flowchart of the XPWRITE process according to the third embodiment.
  • the same parts as those in the XPWRITE process according to the first embodiment illustrated in FIG. 7 are denoted by the same reference numerals, and here, differences from the processes will be mainly described.
  • the XPWRITE process is a process executed when the FMPK 160 receives an XPWRITE command.
  • the FMPK 160 executes a process on the assumption that the target of the command is a redundant code.
  • step S73 the FMPK 160 determines which is the parity generation opportunity of the XPWRITE command (S251).
  • the FMPK 160 determines which is the parity generation trigger for the old parity (S259).
  • the parity generation trigger of the old parity is after compression (S259: after compression)
  • the consistency of the parity generation trigger is not taken, and the FMPK 160 responds to the MP 121 with an abnormal end ( S253), the process is terminated.
  • the FMPK 160 when it is determined that the parity generation trigger of the old parity is before compression (S259: before compression), the FMPK 160 generates a new P by performing an XOR operation between the intermediate data and the old parity (S260). ), A parity generation opportunity (before compression) is assigned to the new P (S261), the new P is stored in the flash chip 166 (S262), and the process is terminated.
  • step S251 If it is determined in step S251 that the parity generation opportunity is after compression (S251: after compression), the FMPK 160 determines which is the parity generation opportunity for the old parity (S252). As a result, when it is determined that the parity generation trigger of the old parity is before compression (S252: before compression), the consistency of the parity generation trigger is not taken, so the FMPK 160 responds to the MP 121 with an abnormal end ( S253), the process is terminated.
  • the FMPK 160 performs padding for each compressed block of intermediate data from the size information (S254).
  • the FMPK 160 generates a new P by performing an XOR operation on the padded intermediate data and the old P (S255).
  • the FMPK 160 updates the size information assigned to and stored in the old P to the size information corresponding to the new P based on the size information assigned to the intermediate data (S256).
  • the FMPK 160 gives a parity generation opportunity (after compression) to the new P (S257), stores it in the flash chip 166 (S258), and ends the process.
  • the parity generation trigger it is possible to switch between generating the parity of each data based on the data before compression and generating based on the data after compression.
  • the trigger it is possible to generate parity at an appropriate trigger.
  • FIG. 26 is a diagram illustrating an outline of a collection copy process of a stripe column having parity generated using pre-compression data according to the third embodiment. Since this collection copy process has the same part as the collection copy process of the second embodiment shown in FIG. 15, the description of the same part will be omitted and only the difference will be described.
  • the MP 121 acquires the parity generation trigger information of the redundant code of the stripe string to be processed from the FMPK 160 (FIGS. 26 (1) and (2)), and determines that the parity generation has been performed before compression in this stripe string. To do. Next, the MP 121 restores D1 as in FIG. 15 (FIG. 26 (3)) and stores it in the spare FMPK 160 (FIG. 26 (4)). At this time, parity generation trigger information (before compression) is added to the READ / WRITE command.
  • CMP parity generation trigger information
  • FIG. 27 is a diagram showing an outline of a collection copy process of a stripe column having parity generated using the compressed data according to the third embodiment. Since this collection copy process has the same part as the collection copy process shown in FIG. 26, the description of the same part will be omitted and only the difference will be described.
  • the MP 121 obtains a parity generation opportunity from the FMPK 161 and determines that parity generation has been performed after compression (FIGS. 27 (1) and (2)). Next, the MP 121 acquires the size information after compression of the data in the stripe from the FMPK 160 ((3) in FIG. 27). Next, the MP 121 issues a READ command for reading the data (D2 to Dn) and the redundancy code (P) from each FMPK 160, and acquires them (FIGS. 27 (4) to (8)). At this time, the MP 121 assigns compression necessity information (compression unnecessary) to the READ command. The FMPK 160 that has received the READ command (CMP) responds to the MP 121 without decompressing the compressed data stored in the flash chip 166 based on the compression necessity information.
  • CMP compression necessity information
  • the MP 121 adjusts the data size by padding each compressed block of the compressed data based on the size information (FIG. 27 (9)).
  • the MP 121 generates data in which padding is included in the data to be restored (cD1) after compression by performing an XOR operation on each padded data and P (FIG. 27 (10)).
  • MP 121 generates cD1 without padding based on the size information (FIG. 27 (11))
  • MP 121 issues a WRITE command to WRITE cD1 to spare FMPK 160 (FIG. 27).
  • the MP 121 assigns compression necessity information (compression unnecessary) to the WRITE command, and the FMPK 160 that has received this WRITE command compresses cD1 based on the compression necessity information.
  • FIG. 27 (13) Note that the process of adding / deleting padding is performed by MP121.
  • the FMPK 160 may receive size information from the FMPK 160, and the FMPK 160 may execute the processing based on the size information.
  • the CMPK 130 separately manages the data after compression and the data before compression. The compressed data is not visible from the host.
  • FIG. 28 is a flowchart of the collection copy process according to the third embodiment. Parts similar to those in the collection copy process according to the second embodiment illustrated in FIG. 16 are denoted by the same reference numerals, and here, differences from that process will be mainly described.
  • the MP 121 acquires a parity generation opportunity from the FMPK 160 in which the parity of the stripe column to be restored is stored (S281). Next, the MP 121 determines which of the parity generation triggers (S282).
  • the MP 121 executes the processing of steps S163 to S166, and advances the processing to step S167.
  • the MP 121 acquires size information after compression of data in the parity stripe from the FMPK 160 storing the parity. (S283).
  • the MP 121 issues a READ command for reading from the FMPK 160 the data (cD2 to cDn) and the redundant code (hereinafter referred to as P) in the stripe string necessary for restoration (S284).
  • the MP 121 assigns compression necessity information (compression unnecessary) to the READ command.
  • the FMPK 160 that has received the READ command reads the data in which the target data and the redundant code are compressed from the flash chip 166 as it is, and returns it. Therefore, the FMPK 160 can reduce the processing load without performing the process of expanding the data.
  • the MP 121 aligns the sizes of cD2 to cDn and P by inserting padding for each compressed block of data based on the size information (S285).
  • the MP 121 uses cD2 to cDn and P to restore data in which padding is included in data to be restored (hereinafter, cD1) (S286).
  • the MP 121 deletes the padding from the restored data based on the size information, and generates cD1 to be restored (S287).
  • the MP 121 secures and stores an area for cD1 in the BEPK 140 (S288), and issues a WRITE command for WRITE cD1 to the spare FMPK 160 (S289).
  • the MP 121 gives compression information (compression unnecessary) to the WRITE command.
  • the FMPK 160 that has received the WRITE command stores cD1 in the flash chip 166 without compression.
  • the MP 121 does not perform compression processing, and the processing load is reduced.
  • MP121 advances a process to step S167.
  • FIG. 29 is a block diagram of an example of a READ / WRITE command according to the third embodiment.
  • the command 171 of the READ / WRITE command includes a command type 171a, an LBA 171b, a transfer length 171c, and a compression implementation necessity 171d.
  • the command type 171a indicates the type of command. For example, READ and WRITE are set as the command type.
  • the LBA 171b is a logical block address of the logical VOL.
  • the transfer length 171c is the length of data transferred by a command.
  • the compression implementation necessity 171d is information indicating whether or not the compression / decompression processing is performed in the FMPK 160 for the READ / WRITE target data.
  • the FMPK 160 When the value of the compression execution necessity 171d is the execution necessity, the FMPK 160 performs the compression / decompression process inside and executes READ / WRITE. However, when the FMPK 160 determines from the parity determination information 124 that the READ / WRITE target is a redundant code, the compression / decompression process is not performed in the FMPK 160 even if the value of the compression execution necessity 171d is necessary. Execute READ / WRITE processing. If the value of the compression implementation necessity 171d is not necessary, the FMPK 160 performs the READ / WRITE process without performing the compression / decompression process therein.
  • FIG. 30 is a flowchart of the READ process according to the third embodiment.
  • the same parts as those in the READ process according to the second embodiment illustrated in FIG. 13 are denoted by the same reference numerals, and here, differences from the processes will be mainly described.
  • the FMPK 160 determines which of the compression implementation necessity 171d is (S301).
  • the FMPK 160 executes the processing of steps S142 to S145 as in FIG.
  • the FMPK 160 stores the compressed data of the READ target stored in the flash chip 166 in the Buffer 161 without decompressing ( S144). Next, the FMPK 160 transmits the READ target data to the BEPK 140 (S145), and ends the READ process.
  • FIG. 31 is a flowchart of the WRITE process according to the third embodiment.
  • the same parts as those in the WRITE process according to the second embodiment illustrated in FIG. 14 are denoted by the same reference numerals, and here, differences from the processes will be mainly described.
  • the FMPK 160 When the FMPK 160 receives the WRITE command (S151), the FMPK 160 receives the WRITE target to the Buffer 161 (S152), and determines which of the compression execution necessity 171d is (S311).
  • the FMPK 160 executes the processing of steps S153 to S155 as in FIG.
  • the FMPK 160 stores the WRITE target data stored in the Buffer 161 in the flash chip 166 without being compressed (S155).
  • the compression process is described as an example of the additional process executed by the storage device.
  • the additional process may be an encryption process.
  • the additional processing is encryption processing, unlike the compression processing, the data size after execution of the data processing does not change, so the above-mentioned size information retention and data size adjustment processing (padding processing) is unnecessary. It is. Further, whether or not to execute the process for determining whether or not to execute the additional process may be turned ON / OFF according to an instruction from the management computer 20.
  • a storage device for example, FMPK 160
  • additional processing functions such as a compression processing function and an encryption processing function
  • a higher-level device for example, the storage controller 11
  • the storage device can be configured not to perform additional processing only on data stored in a predetermined area, and the IO processing performance of the storage device can be improved.
  • the storage device addition processing may be not only compression processing and encryption processing but also snapshot acquisition processing, for example.
  • the information notified from the host device may be information indicating whether or not the IO target is parity as in the first to third embodiments.
  • the operation and operation of the application program that operates on the server. May be information indicating that it is not necessary to perform additional processing on data in a predetermined area, and may be information that can determine whether additional processing has been performed or not. .
  • FIG. 32 is a diagram illustrating an outline of the function execution determination information registration process according to the fourth embodiment.
  • this function implementation determination information registration process has the same part as the parity determination information registration process shown in FIG. 8, description is abbreviate
  • the function execution determination information 125 is registered in the FMPK 166 in place of the parity determination information 124 in the parity determination information registration process shown in FIG. 1)).
  • the function execution determination information 125 is an example of determination information, and is, for example, information (function execution necessity information) indicating whether or not to perform an additional process for each unit area of a fixed size of the logical VOL. Based on the function execution determination information 125, the FMPK 160 determines whether or not the function is necessary during the IO process, and determines whether or not to perform the additional process.
  • the function execution determination information 125 may hold, for example, function execution necessity information for each unit area of the entire logical VOL. For each unit area within a specific size, the function execution necessity information and the specific size You may make it have the repetition number of. Further, the function execution determination information 125 may be notified to the FMPK 160 by being embedded in the command or data corresponding to the command for each IO instead of being registered in the FMPK 160 in advance.
  • FIG. 33 is a diagram illustrating an overview of command processing according to the fourth embodiment.
  • the MP 121 issues a command to the FMPK 160 via the BEPK 140 (FIGS. 33 (1) and (2)).
  • the FMPK 160 receives the command, and based on the address information in the command and the function execution determination information 125, the FMPK 160 performs the drive function unit for data to be input / output by the command (D1 or D2 in FIG. It is determined whether or not the predetermined additional processing is to be performed by 167 (FIGS. 33 (3) and (4)).
  • the drive function unit 167 may be a dedicated circuit that performs predetermined addition processing, or may be configured by the package processor 163 of the FMPK 160.
  • the FMPK 160 determines that it is not necessary to perform the additional processing (case D1 in FIG. 33), the FMPK 160 stores D1 in the flash chip 166 without executing the additional processing by the drive function unit 167 (FIG. 33 ( 5)).
  • the drive function unit 167 executes the predetermined additional processing related to D2, and then executes the additional processing. Is stored in the flash chip 166 (FIG. 33 (6)).
  • FIG. 33 the outline of processing when data is written to the flash chip 166 has been described. However, when data is read from the flash chip 166, processing corresponding to the processing at the time of writing may be performed. Specifically, when the FMPK 160 determines that the execution of the additional process is unnecessary (in the case of reading D1), the FMPK 160 reads the data as it is without executing the additional process from the flash chip 160, and performs the additional process. Is determined to be necessary (in the case of reading D2), it may be read by executing an additional process by the drive function unit 167 on the data of the flash chip 160.
  • FIG. 34 is a flowchart of command processing according to the fourth embodiment.
  • the command process is a process executed by the FMPK 160 that has received a command issued from the storage controller 11.
  • the FMPK 160 When the FMPK 160 receives the command (S341), based on the address information of the target of the command and the function execution determination information 125, the FMPK 160 performs predetermined addition processing on the address data indicated by the address information. Whether or not (function implementation necessity) is determined (S342).
  • the FMPK 160 performs a predetermined additional process on the command target data by the drive function unit 167. (S343) Processing corresponding to the command (for example, data IO processing) is performed (S344), and the command processing is terminated.
  • the FMPK 160 does not perform the addition processing by the drive function unit 167, but performs processing corresponding to the command (for example, data I / O processing) is performed (S344).
  • the FMPK 160 performs only the process corresponding to the command without executing the additional process for data that does not need to be subjected to the additional process, so that the processing load on the FMPK 160 can be reduced. it can.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

　ストレージシステムは、データを格納する記憶媒体と、データに対してデータの状態の変更を伴う付加処理を実行するデバイスコントローラと、を有するストレージデバイスと、ストレージデバイスへのデータの入出力を制御するストレージコントローラとを備える。ストレージコントローラは、ストレージデバイスに対して、入出力対象のデータに関する入出力処理に伴って、デバイスコントローラが付加処理を実行するか否かの判断に利用可能な判断情報を送信する。デバイスコントローラは、ストレージコントローラから送信された判断情報に基づいて、入出力対象のデータに対する付加処理の実行を制御する。

Description

ストレージシステム及び記憶制御方法
　本発明は、格納対象のデータに対する所定の処理を実行可能なストレージデバイスを有するストレージシステムの記憶制御に関する。
　ストレージシステムでは、ストレージコントローラがデータの最終記憶装置であるストレージデバイスに対するＩＯの制御を行う。近年では、企業で扱うデータ量増大に伴い、データを格納するために必要なストレージデバイスの増加によりデータ格納のためのコストも増大している。このため、ストレージシステムにおけるデータ保持コストの低減が求められている。このニーズに答える技術の一つとして、ストレージデバイス（例えば、ＨＤＤ（Hard　Disk　Drive）やＳＳＤ（Solid　State　Drive））に格納されるデータを圧縮することでデータ格納量を削減する技術がある。データ量の増大により、データ圧縮技術は、バックアップ用途のボリュームだけではなく、通常の業務で使用されるボリューム（プライマリボリューム）にも適用することが求められている。
　圧縮技術としては、例えば、特許文献１には、ビットコストの高いフラッシュメモリを記憶媒体とするＳＳＤ等のフラッシュデバイスに格納するデータ容量を削減するために、フラッシュデバイスがデータ圧縮処理を実施する技術が開示されている。
米国特許出願公開第２０１１／３２０９１５号明細書 国際公開第２０１０／１３７１７８号パンフレット
　特許文献１の技術では、フラッシュデバイスが圧縮処理を実施しているため、ストレージコントローラが圧縮処理を実施する場合と比べてストレージコントローラの負荷が低減される。ただし、フラッシュデバイスがＩＯ処理に加えて圧縮処理を実施するため、圧縮処理を実施しない時に比べてフラッシュデバイスの性能が低下する。フラッシュデバイスのＩＯ処理はＨＤＤと比べて高速であるため、圧縮／伸張処理による性能への影響が大きくなる。つまり、フラッシュデバイスで圧縮処理を実施した場合には、ＨＤＤで圧縮処理を実施した場合と比べて性能低下率が大きくなる。
　ここで、ストレージシステムでは、ＩＯ処理の高速化や耐障害性向上を目的として、ＲＡＩＤ（Redundant　Array　of　Independent　Disks）グループを構成してパリティ（冗長コード）を生成する場合がある。ＲＡＩＤグループにおけるパリティ生成方法としては、従来から知られているストレージシステムのコントローラがパリティを生成する方法と、特許文献２に開示されているストレージデバイスがパリティを生成する方法とがある。このようなシステムに圧縮技術を適用すると、ランダムライト時には、ホストライト１回に対して、旧データ及び旧パリティの伸長と、新データ及び新パリティの圧縮が必要となる。つまり、圧縮／伸張処理をそれぞれ２回ずつ行うこととなるので、性能低下率はさらに大きくなる。
　プライマリボリュームに圧縮技術を適用した場合、データ圧縮による性能低下は業務への影響が大きく、圧縮によってデータ格納量を削減しつつ、性能低下を抑制することが課題である。例えば、データベースへのアクセスを伴うことが多いＯＬＴＰ（Ｏｎ－Ｌｉｎｅ
Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ）では、ランダムライトが比較的多く、データ圧縮した場合の性能低下も大きくなる。
　ストレージシステムは、データを格納する記憶媒体と、データに対してデータの状態の変更を伴う付加処理を実行するデバイスコントローラと、を有するストレージデバイスと、ストレージデバイスへのデータの入出力を制御するストレージコントローラとを備える。ストレージコントローラは、ストレージデバイスに対して、入出力対象のデータに関する入出力処理に伴って、デバイスコントローラが付加処理を実行するか否かの判断に利用可能な判断情報を送信する。デバイスコントローラは、ストレージコントローラから送信された判断情報に基づいて、入出力対象のデータに対する付加処理の実行を制御する。
　フラッシュデバイスがストレージコントローラから送信される情報に基づいて圧縮処理の要否を判定する。これにより、データの格納量が削減されて低コスト化することができ、全データを圧縮する場合よりもライト性能を向上することができる。
図１は、実施例１に係る計算機システムのハードウェア構成図である。 図２は、実施例１に係るＦＭＰＫのハードウェア構成図である。 図３は、実施例１に係るランダムライト時のパリティ生成処理の概要を示す図である。 図４は、実施例１に係るランダムライト時のパリティ生成処理のフローチャートである。 図５は、実施例１に係るＸＤＷＲＩＴＥ処理のフローチャートである。 図６は、実施例１に係るＸＤＲＥＡＤ処理のフローチャートである。 図７は、実施例１に係るＸＰＷＲＩＴＥ処理のフローチャートである。 図８は、実施例２に係るパリティ判定情報登録処理の概要を示す図である。 図９は、実施例２に係るパリティ判定情報の一例の構成図である。 図１０は、実施例２に係るＲＭＷパリティ生成処理の概要を示す図である。 図１１は、実施例２に係る全ストライプパリティ生成処理の概要を示す図である。 図１２は、実施例２に係るパリティ生成処理のフローチャートである。 図１３は、実施例２に係るＲＥＡＤ処理のフローチャートである。 図１４は、実施例２に係るＷＲＩＴＥ処理のフローチャートである。 図１５は、実施例２に係るコレクションコピー処理の概要を示す図である。 図１６は、実施例２に係るコレクションコピー処理のフローチャートである。 図１７は、実施例３に係る圧縮後データを用いてパリティを生成する場合の、ＲＭＷパリティ生成処理の概要を示す図である。 図１８は、実施例３に係る圧縮前データを用いてパリティを生成する場合の、ＲＭＷパリティ生成処理の概要を示す図である。 図１９は、実施例３に係る全ストライプパリティ生成処理の概要を示す図である。 図２０は、実施例３に係るＸＤＲＥＡＤ／ＸＤＷＲＩＴＥ／ＸＰＷＲＩＴＥコマンドの一例の構成図である。 図２１は、実施例３に係るパリティ生成処理のフローチャートである。 図２２は、実施例３に係るＲＭＷパリティ生成処理のフローチャートである。 図２３は、実施例３に係るＸＤＷＲＩＴＥ処理のフローチャートである。 図２４は、実施例３に係るＸＤＲＥＡＤ処理のフローチャートである。 図２５は、実施例３に係るＸＰＷＲＩＴＥ処理のフローチャートである。 図２６は、実施例３に係る圧縮前データを用いて生成されたパリティを持つストライプ列のコレクションコピー処理の概要を示す図である。 図２７は、実施例３に係る圧縮後データを用いて生成されたパリティを持つストライプ列のコレクションコピー処理の概要を示す図である。 図２８は、実施例３に係るコレクションコピー処理のフローチャートである。 図２９は、実施例３に係るＲＥＡＤ／ＷＲＩＴＥコマンドの一例の構成図である。 図３０は、実施例３に係るＲＥＡＤ処理のフローチャートである。 図３１は、実施例３に係るＷＲＩＴＥ処理のフローチャートである。 図３２は、実施例４に係る機能実施判定情報登録処理の概要を示す図である。 図３３は、実施例４に係るコマンド処理の概要を示す図である。 図３４は、実施例４に係るコマンド処理のフローチャートである。
　幾つかの実施例を、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
　なお、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central　Processing　Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェースデバイス（例えばポート）を用いながら行うため、処理の主語がプログラムとされても良い。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（例えば、管理計算機、ホスト計算機、ストレージシステム等）が行う処理としても良い。また、プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。プログラムは、プログラムソースから各コントローラにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
　実施例１に係るストレージシステムを含む計算機システムの概要を説明する。
　ストレージシステム１０は、図１に示すように、例えば、１つの筐体で構成された装置としても良いし、外部ストレージ装置４０と組み合わせて構成されても良い。ストレージシステム１０は、例えば、ＦＭＰＫ（Flash Memory Package）１６０のようなストレージデバイスを複数備える。ストレージシステム１０においては、複数のストレージデバイスを用いてＲＡＩＤ（Redundant　Array　of　Independent　Disks）グループが構成される。
　各ストレージデバイスの記憶領域は、ストライプと呼ばれるサブ記憶領域に分割されて管理される。つまり、各ストレージデバイスは複数のストライプを含む。ＲＡＩＤグループの記憶領域は、複数のストライプ列で構成されている。各ストライプ列は、各ストレージデバイスに含まれるストライプをひとつずつ含む。つまり、ストライプ列は、ＲＡＩＤグループを構成する複数のストレージデバイスに跨っている。
　ＲＡＩＤには、いくつかのレベル（以下、（ＲＡＩＤレベル）という）がある。
　例えば、ＲＡＩＤ５では、ホスト計算機３０から指定されたライト対象のデータは、複数のデータ要素に分割され、複数のデータ要素が、同一のストライプ列の複数のストライプに書き込まれる。また、ＲＡＩＤ５では、ストレージデバイスに障害が発生したことによりそのストレージデバイスから読み出せなくなったデータ要素を復元するために、ストライプ列に含まれる複数のデータ要素から“パリティ”と呼ばれる冗長な情報（以下、「冗長コード」）が生成され、その冗長コードも、同一のストライプ列のストライプに書き込まれる。例えば、ＲＡＩＤグループを構成するストレージデバイスの数が４である場合は、そのうちの３つのストレージデバイスに対応する３つのストライプに、ストライプ列を構成する３つのデータ要素が書き込まれ、残りの１つのストレージデバイスに対応するストライプに、冗長コードが書き込まれる。この場合、ストライプ列は、３つのデータ要素と、３つのデータ要素から生成されるパリティを含む。パリティが含まれるストライプ列に含まれるデータ要素のいずれかが更新された場合、そのパリティも更新される。パリティは、例えば、同じストライプ列に含まれる複数のデータ要素のＸＯＲ演算により生成される。以下、データ要素と冗長コードとを区別しない場合には、両者をそれぞれストライプデータ要素ということもある。
　また、ＲＡＩＤ６では、ＲＡＩＤグループを構成する複数のストレージデバイスのうちの２つのストレージデバイスに障害が発生した等の理由により、データ単位を構成する複数のデータ要素のうちの２つのデータ要素を読み出すことができない場合に、これら２つのデータ要素を復元することができるように、各データ単位に対して、２種類の冗長コード（Ｐパリティ、Ｑパリティという）が生成されて、それぞれの冗長コードが同一のストライプ列のストライプに書き込まれる。
　また、上記に説明した以外にもＲＡＩＤレベルは存在する（例えばＲＡＩＤ１～４）。また、データの冗長化技術として、３重ミラー（Ｔｒｉｐｌｉｃａｔｉｏｎ）、３種類のパリティを用いたトリプルパリティ技術等もある。また、冗長コードの生成技術についても、ガロア演算を用いたＲｅｅｄ－ｓｏｌｏｍｏｎ符号や、ＥＶＥＮ－ＯＤＤ等さまざまな技術が存在する。本実施例では、ＲＡＩＤレベルがＲＡＩＤ５である例を主に説明するが、これは本発明を限定するものではなく、他のＲＡＩＤレベルであっても良く、上記した他の技術を用いたＲＡＩＤに対しても適用することができる。
　ストライプ列のデータ要素を更新した際に、そのストライプ列についての冗長コードを計算して更新する。ここで、冗長コードの計算方法としては、その冗長コードを計算するために用いるデータによっていくつかの方法がある。第１の方法は、ストライプ列の全てのデータ要素を用いて計算する方法（以下、「全ストライプパリティ生成」という)である。第１の方法は、アクセスパターンがシーケンシャルライトの場合、例えばストライプ列に含まれるすべてのデータ要素が更新される場合に用いられる。第２の方法は、一部のデータ要素についての更新後のデータ（新データ）及び更新前のデータ（旧データ、つまり新データによって更新されるデータ）と、更新前のパリティ（旧パリティ）とを用いて計算する方法(以下、「ＲＭＷ（Read　Modify　Write）パリティ生成」という)である。第２の方法は、アクセスパターンがランダムライトの場合、例えばストライプ列に含まれるデータ要素の一部が更新される場合に用いられる。ただし、全ストライプパリティ生成とＲＭＷパリティ生成とは、ストレージシステムの負荷を考慮して使い分けられてもよい。
　以下、図１を参照して、ＲＭＷパリティ生成を説明する。ＲＭＷパリティ生成には、ＣＭ１３１にＦＭＰＫ１６０から必要なデータを読み込んで、ＢＥコントローラ１４２もしくはＭＰ１２１が冗長コードを生成する方法(以下、従来ＲＭＷ)や、ＦＭＰＫ１６０などのストレージデバイスが冗長コードを生成する方法(以下、オフロードＲＭＷ)がある。
　ＦＭＰＫ１６０が冗長コードを生成するオフロードＲＭＷでは、ストレージコントローラ１１は、従来のＲＥＡＤ／ＷＲＩＴＥコマンドに加えて以下に説明するコマンドを利用する。１つは、ホスト計算機３０が送信したデータ(以下、新データ)をＦＭＰＫ１６０に転送してＦＭＰＫにパリティ生成を指示するために用いるＸＤＷＲＩＴＥコマンドである。ＸＤＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、送信された新データと、新データと同一アドレスのＦＭＰＫ１６０の記憶領域に格納されているデータ（旧データ）とを用いて中間データを生成する。別の１つは、ＦＭＰＫ１６０が生成した中間データを読み出すために用いるＸＤＲＥＡＤコマンドである。ＸＤＲＥＡＤコマンドを受領したＦＭＰＫ１６０は、ＸＤＷＲＩＴＥコマンドに基づいて生成した中間データを、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に転送する。さらに別の１つは、中間データに基づいて新データに対応する冗長コード（新パリティ）を生成して、それまでの冗長コード（旧パリティ）の格納アドレスの記憶領域に対して書き込みを行うために用いるＸＰＷＲＩＴＥコマンドである。ＸＰＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、送信された中間データとＦＭＰＫ１６０に格納されている旧パリティとを用いて、新パリティを生成し、新パリティを対応するアドレスに格納する。実施例１では、これらのコマンドは、入出力対象がユーザデータであるか、冗長コードであるかを特定可能な情報を含んでおり、判断情報の一例である。
　次に、実施例１に係るストレージシステムを含む計算機システムを詳細に説明する。
　図１は、実施例１に係る計算機システムのハードウェア構成図である。
　計算機システムは、１以上のホスト計算機（以下、ホストという）３０と、管理計算機２０と、ストレージシステム１０とを含む。ホスト計算機３０と、ストレージシステム１０とは、ネットワーク５０を介して接続されている。ネットワーク５０は、ローカルエリアネットワークであっても良く、ワイドエリアネットワークであっても良い。また、管理計算機２０と、ストレージシステム１０とは、内部ネットワーク１５０により接続されている。なお、ストレージシステム１０に、ネットワーク５０を介して１以上の外部ストレージ装置４０を接続するようにしても良い。外部ストレージ装置４０は、１つ以上のストレージデバイスを含む。ストレージデバイスは、不揮発性の記憶媒体、例えば、磁気ディスク、フラッシュメモリ、その他半導体メモリを含む。
　ホスト３０は、例えば、アプリケーションを実行する計算機であり、ストレージシステム１０からアプリケーションに利用するデータを読み出したり、ストレージシステム１０にアプリケーションで作成したデータを書き込んだりする。
　管理計算機２０は、計算機システムを管理する管理処理を実行するための管理者により使用される計算機であり、入力デバイスや表示デバイスを有する。管理計算機２０は、入力デバイスに対する管理者の操作により、ＲＡＩＤグループに対するＲＡＩＤレベルの設定を受けつけ、受け付けたＲＩＡＤレベルでＲＡＩＤグループを構成するようにストレージシステム１０に対して設定を行う。
　ストレージシステム１０は、１以上のフロントエンドパッケージ（ＦＥＰＫ）１００と、１以上のマイクロプロセッサパッケージ（ＭＰＰＫ）１２０と、１以上のキャッシュメモリパッケージ（ＣＭＰＫ）１３０と、１以上のバックエンドパッケージ（ＢＥＰＫ）１４０と、内部ネットワーク１５０と、複数のフラッシュパッケージ（ＦＭＰＫ）１６０とを有する。ＦＥＰＫ１１０、ＭＰＰＫ１２０、ＣＭＰＫ１３０、及びＢＥＰＫ１４０は、内部ネットワーク１５０を介して接続されている。ここで、ＦＥＰＫ１１０、ＭＰＰＫ１２０、ＣＭＰＫ１３０、及びＢＥＰＫ１４０により、ストレージコントローラ１１が構成される。ＢＥＰＫ１４０は、複数系統のパスを介してＦＭＰＫ１６０と接続されている。ここでは、ＢＥＰＫ１４０に接続するストレージデバイスは不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他半導体メモリ（ＰＲＡＭ（相変化メモリ）、ＲｅＲＡＭ（抵抗変化メモリ）、ＭＲＡＭ（磁気抵抗メモリ）など）でも良い。
　ＦＥＰＫ１００は、インターフェースデバイスの一例であり、１以上のポート(ｐｏｒｔ)１０１と、ＦＥコントローラ１１２と、バッファ１１３とを有する。ポート１０１は、ストレージシステム１０を、ネットワーク５０等を介して種々の装置と接続する。ＦＥコントローラ１１２は、ホスト計算機３０との間の通信を制御する。
　ＭＰＰＫ１２０は、制御デバイスの一例としてのマイクロプロセッサ（ＭＰ）１２１と、ローカルメモリ（ＬＭ）１２２とを有する。ＭＰ１２１と、ＬＭ１２２とは、内部バス１２３を介して接続されている。ＬＭ１２２は、各種プログラムや、各種情報を記憶する。ＭＰ１２１は、ＬＭ１２２に格納されたプログラムを実行して各種処理を実行する。ＭＰ１２１は、ＢＥＰＫ１４０を介して、各種コマンド（例えばＳＣＳＩにおけるＲＥＡＤコマンドやＷｒｉｔｅコマンドなど）をＦＭＰＫ１６０に送信する。また、ＭＰ１２１は、ＦＥＰＫ１００を介して、各種コマンドを外部ストレージ装置４０に送信する。また、上長コードの生成処理を実施する。ＭＰ１２１は、例えば、ＲＡＩＤ５で構成されたＲＡＩＤグループのデータ単位に対しては、データ単位を構成する複数のデータ要素の排他的論理和（ＸＯＲ）をとることによって冗長コード（パリティ）を生成する。また、ＭＰ１２１は、ＲＡＩＤ６で構成されたＲＡＩＤグループのデータ単位に対しては、更に、データ単位を構成する複数のデータ要素に所定の係数を掛けた後、それぞれのデータの排他的論理和をとることによって、パリティを生成する。また、ＭＰ１２１は、データ単位についての１以上のストライプデータ要素（データ要素及びパリティのうち少なくとも１つ）に基づいて、データ単位中のいずれかのデータ要素を復元する復元処理を行う。パリティの生成は、ＭＰ１２１がプログラムを実行して行ってもよいし、パリティ生成回路を用いてもよい。
　ＣＭＰＫ１３０は、キャッシュメモリ（ＣＭ）１３１と、共有メモリ(ＳＭ)１３２とを有する。ＣＭ１３１は、ホスト３０からＦＭＰＫ１６０等に書き込むデータ（ライトデータ）や、ＦＭＰＫ１６０から読み出したデータ（リードデータ）を一時的に格納する。ＳＭ１３２は、ＭＰＰＫ１２０が各種処理を実行する際に、複数のＭＰＰＫ１２０で共有する情報を格納する。
　ＢＥＰＫ１４０は、１以上のポート１４１と、ＢＥコントローラ１４２と、Ｂｕｆｆｅｒ１４３とを有する。ポート１４１は、ストレージシステム１０と、ＦＭＰＫ１６０のようなストレージデバイスとを接続する。ＢＥコントローラ１４２は、例えば、プロセッサであり、ＣＭＰＫ１３０とＦＭＰＫ１６０と間のデータ転送を行う。また、ＢＥＰＫ１４０が、ＭＰ１２１に代わって冗長コード生成処理を実施してもよい。この場合、冗長コードを生成するための回路は、ＢＥＰＫ１４０内にあってもよいしＢＥＰＫ１４０とは別にあっても良い。
　Ｂｕｆｆｅｒ１４３は、ＦＭＰＫ１６０から送信されたデータや、ＦＭＰＫ１６０へ送信するデータを一時的に格納する。
　ＦＭＰＫ１６０は、データを格納する。ＦＭＰＫ１６０は、圧縮処理及び伸張処理を実行する圧縮及び伸張機能を有しており、ＢＥＰＫ１４０から書き込み要求があった場合には、書き込み対象のデータを、圧縮して、圧縮した状態で格納することができる。また、ＢＥＰＫ１４０から読み出し要求があった場合には、ＦＭＰＫ１６０に圧縮された状態で格納されているデータを伸張して、ＢＥＰＫ１４０に送信することができる。なお、ＦＭＰＫ１６０は、ストレージコントローラ１１からデータを受信した場合に、圧縮してからフラッシュチップ１６６にデータを格納してもよいし、一旦フラッシュチップ１６６にデータを格納し、ストレージコントローラ１１からのデータの書き込みとは非同期にフラッシュチップ１６６からデータを読み出して圧縮してもよい。
　ストレージコントローラ１１は、ホスト計算機３０に、論理ボリュームを提供する。論理ボリュームは、ＲＡＩＤグループに含まれる複数のＦＭＰＫ１６０の記憶領域に基づいて構成される。論理ボリュームには、その論理ボリュームの全論理アドレス範囲に記憶領域が割当てられている。
　また、ストレージコントローラ１１は、ホスト計算機３０に、シンプロビジョニングに従う仮想ボリュームを提供できる。仮想ボリュームは、作成された段階ではボリューム容量が定義され、仮想ボリュームのアドレス範囲は設定されるが、記憶領域は割当てられていない。ストレージコントローラ１１は、ホスト計算機３０からライト要求を受信すると、所定のサイズの記憶領域（以下、チャンクと呼ぶ）を仮想ボリュームのライト要求で指定されるアドレスを含む領域に割り当て、ライト要求に伴うデータを書き込む。チャンクは、ＲＡＩＤグループに含まれる複数のＦＭＰＫ１６０の記憶領域に基づいて構成される。また、ストレージコントローラ１１は、複数のチャンクをプールを用いて管理する。プールには、複数のＲＡＩＤグループに基づくチャンクが含まれる。つまり、ストレージコントローラ１１は、仮想ボリュームに対するライト要求を受信すると、プールからチャンクを選択し、仮想ボリュームに割当てる。すでに仮想ボリュームにチャンクが割当てられているアドレス範囲へのライト要求であれば、新たにチャンクを割当てる必要はない。以下では、論理ボリュームと仮想ボリュームをあわせてボリュームと呼ぶことがある。
　図２は、実施例１に係るＦＭＰＫのハードウェア構成図である。
　ＦＭＰＫ１６０は、パッケージコントローラ１６８と、１以上のフラッシュチップ１６６とを有する。パッケージコントローラ１６８は、Ｂｕｆｆｅｒ１６１と、パッケージメモリ１６２と、デバイスコントローラの一例としてのパッケージプロセッサ１６３と、圧縮・伸張回路１６４と、バス転送装置１６５と、通信ＩＦ１６７と、パリティ生成回路１６９を有する。
　通信ＩＦ１６７は、ＢＥＰＫ１４０から送信されたデータを受信する。Ｂｕｆｆｅｒ１６１は、ＢＥＰＫ１４０から送信されたデータや、ＢＥＰＫ１４０へ送信するデータを一時的に格納する。パッケージメモリ１６２は、各種プログラムや各種情報を記憶する。パッケージプロセッサ１６３は、パッケージメモリ１６２に格納されたプログラムを実行して各種処理を実行する。例えば、パッケージプロセッサ１６３は、圧縮・伸張回路１６４によりデータの圧縮・伸張を実行させる。また、パッケージプロセッサ１６３は、パリティ演算回路１６９にパリティの生成（ＸＯＲ演算）を実行させる。また、パッケージプロセッサ１６３は、バス転送装置１６５によりフラッシュチップ１６６との間のデータ入出力を実行させる。フラッシュチップ１６６は、記憶媒体の一例であり、フラッシュメモリのチップである。ＦＭＰＫ１６０は、外部装置（ストレージコントローラ１１）に対して論理アドレス空間を提供している。ストレージコントローラ１１は、論理アドレス空間上の論理アドレスを指定してリード／ライトコマンド等を、ＦＭＰＫ１６０に送信する。
　ここで、フラッシュメモリは、不揮発性半導体記憶媒体である。フラッシュメモリチップ１６６は、物理的な記憶領域として、複数のブロックを有しており、各ブロックはデータ消去の単位である。また、各ブロックは、複数のページを有しており、各ページはデータのリード／ライトの単位である。フラッシュメモリは、ページに格納されたデータを更新する場合、上書きできないという特性を持つ。このため、データを更新する場合、パッケージプロセッサ１６３は、更新前のデータが格納されているページ（第一ページ）とは異なるページ（第二ページ）にデータを書きこむ。ここで、パッケージプロセッサ１６３は、第一ページにマッピングされていた論理アドレス範囲を第二ページにマッピングする。これにより、ストレージコントローラ１１は、ＦＭＰＫ１６０が提供する論理アドレスにアクセスすれば、ＦＭＰＫ１６０内部での物理的なデータ格納位置を意識する必要なく、更新後のデータにアクセスできる。パッケージメモリ１６２には、この論理アドレスと物理的なページの位置（物理アドレス）の変換情報（論理－物理マッピング情報）を格納されている。
　以下では、パッケージプロセッサ１６３を主体としてＦＭＰＫ１６０における処理を説明するが、パッケージコントローラ１６８がＦＭＰＫ１６０内のデータの転送やデータの圧縮／伸長処理を実行するということもできる。
　図３は、実施例１に係るランダムライト時のパリティ生成処理の概要を示す図である。
　ホスト計算機３０は、ストレージコントローラ１１によって提供される論理ボリュームのボリューム番号及びボリューム上のアドレスを指定し、ライトデータを伴うライト要求を送信する。このライト要求はすでにボリュームに格納されたデータ（旧データ）を更新するものであるとする。ＭＰ１２１は、ＲＡＩＤグループを構成する複数のＦＭＰＫ１６０の中から、ライト要求によって指定されるボリューム番号及びボリューム上のアドレスに基づいて、そのデータを格納するＦＭＰＫ１６０を特定し、ＦＭＰＫ１６０にデータを送信する。
　本実施例では、従来ストレージコントローラ１１が実行していたパリティ生成処理をＦＭＰＫ１６０が実行する。これにより、パリティ生成処理を制御していたＭＰ１６３の負荷が低減され、ストレージシステム１０全体として処理性能が向上する。さらに、以下に説明するようにＦＭＰＫ１６０がデータ圧縮・伸長の要否を判定することで、圧縮・伸長による、ＦＭＰＫ１６０の性能低下を抑制する。以下に、ＦＭＰＫ１６０によるパリティ生成及びデータ圧縮・伸長を伴う処理を説明する。
　ストレージシステム１０のＭＰ１２１は、ホスト３０から送信されたライトデータ（ユーザデータ：以下、新Ｄ１という)を、ＦＥＰＫ１００を介してＣＭＰＫ１３０のＣＭ１３１に格納する（図３（１））。次に、ＭＰ１２１は、新Ｄ１をＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に転送する（図３（２））。次いで、ＢＥコントローラ１４２は、ＦＭＰＫ１６０に対してＸＤＷＲＩＴＥコマンドを発行し、新Ｄ１を送信する（図３（３））。ＸＤＲＩＴＥコマンドは、旧データに対応する論理アドレスを指定して送信される。
　ＸＤＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、送信された新Ｄ１をＢｕｆｆｅｒ１６１に格納する（図３（４））。パッケージプロセッサ１６３は、受信したコマンドがＸＤＷＲＩＴＥコマンドであるので、受信した新Ｄ１はユーザデータであると判定し、新Ｄ１を圧縮・伸張回路１６４により圧縮した後に、フラッシュチップ１６６に格納する（図３（５））。ここで、新Ｄ１を圧縮させたデータは、新ｃＤ１という。なお、新Ｄ１を圧縮してフラッシュチップ１６６に格納する処理は、ＸＤＷＲＩＴＥコマンドの受信とは非同期に実施しても良い。
　また、パッケージプロセッサ１６３は、フラッシュチップ１６６に格納されている、新Ｄ１に対応する更新前のデータ（旧Ｄ１）を圧縮したデータ(以下、旧ｃＤ１)を、圧縮・伸張回路１６４により伸張して、旧Ｄ１を取得し、旧Ｄ１をＢｕｆｆｅｒ１６１に格納する（図３（６））。次に、パッケージプロセッサ１６３は、新Ｄ１と旧Ｄ１とから、Ｄ１を含むストライプ列のパリティ（冗長コード）を生成するために利用する中間データ(以下、中間Ｄ１、中間パリティと呼んでもよい)を生成する（図３（７））。本実施例では、パッケージプロセッサ１６３は、新Ｄ１と、旧Ｄ１との排他的論理和をとって中間Ｄ１を生成する。
　次に、ストレージシステム１０のＭＰ１２１は、ＦＭＰＫ１６０に対してＸＤＲＥＡＤコマンドを発行することにより、ＦＭＰＫ１６０からＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に中間Ｄ１を読み出す（図３（８））。具体的には、ＸＤＲＥＡＤコマンドを受信したＦＭＰＫ１６０は、中間Ｄ１をＢｕｆｆｅｒ１６１から読み出して、ＢＥＰＫ１４０に送信し、ＢＥコントローラ１４２は、中間Ｄ１を受信し、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に中間Ｄ１を書き込む。
　次に、ストレージシステム１０のＭＰ１２１は、中間Ｄ１を、Ｄ１を含むストライプ列のパリティが格納されているＦＭＰＫ１６０を特定し、旧パリティに対応する論理アドレスを指定してＸＰＷＲＩＴＥコマンドを発行し、中間Ｄ１を送信する。ＸＰＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、中間Ｄ１をＢｕｆｆｅｒ１６１に格納する（図３（９））。パッケージプロセッサ１６３は、受信したコマンドがＸＰＷＲＩＴＥコマンドであるので、フラッシュチップ１６６に格納されている、旧Ｄ１を含むストライプ列の更新前のパリティ(以下、旧Ｐ)をＢｕｆｆｅｒ１６１に読み出す（図３（１０））。次に、パッケージプロセッサ１６３は、中間Ｄ１と旧Ｐとを利用して新Ｄ１に対応するパリティ(以下、新Ｐ)を生成する（図３（１１））。本実施例では、パッケージプロセッサ１６３は、中間Ｄ１と、旧Ｐとの排他的論理和をとって新Ｐを生成する。
　次に、パッケージプロセッサ１６３は、受信したコマンドがＸＰＷＲＩＴＥコマンドであり、このコマンドに基づいて生成したデータはパリティであると判定して、生成したデータ、すなわち、新Ｐを圧縮せずに、フラッシュチップ１６６に格納する（図３（１２））。
　このように、パリティについては、圧縮せずにフラッシュチップ１６６に格納するので、ＦＭＰＫ１６０における処理負荷を軽減することができる。つまり、旧Ｐの読み出し（１０）での伸長処理が不要となり、新Ｐの書き込み処理（１２）での圧縮処理が不要となる。ストライプ列に含まれるデータ要素のいずれかが更新されると、そのストライプ列のパリティは更新される。このため、ユーザデータと比べてパリティを読み出し／書き込みする頻度は高く、それに伴う圧縮／伸長処理を行わないことによる性能低下抑制効果は大きい。一方、ユーザデータについては、圧縮しているので、ストレージシステム１０において使用する記憶容量を抑えることができる。また、中間パリティは、新パリティの生成に用いられるが、新パリティがフラッシュチップ１６６に格納されると不要になるデータである。バッファ上に中間パリティが格納され、新パリティが生成されれば、中間パリティはフラッシュチップ１６６に格納される必要はない。このため、中間パリティを圧縮する必要性は小さく、パッケージプロセッサ１６３は、中間パリティを圧縮しないことで、圧縮処理によるオーバーヘッドを軽減することができる。
　本実施例では、データを圧縮する場合のランダムライトにおけるパリティ生成処理に対して効果的である。例えば、ランダムライトが比較的多いＯＬＴＰでは、データ圧縮によるコスト削減効果と、圧縮による性能低下抑制を両立できる。
　図４は、実施例１に係るランダムライト時のパリティ生成処理のフローチャートである。
　ランダムライト時のパリティ生成処理は、ＭＰ１２１によってＣＭ１３１に格納されたホスト３０から転送されたライトデータをＦＭＰＫ１６０のようなストレージデバイスに格納する際に、データの更新に応じて必要となるパリティの生成を行うために実行される。
　パリティ生成処理では、ＭＰ１２１は、ＣＭ１３１上からパリティの生成を実施していないライトデータ（新データ）を検出する（Ｓ４１）。次に、ＭＰ１２１は、新データをＦＭＰＫ１６０に転送するためにＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に領域を確保し、そこに新データを格納する（Ｓ４２）。次に、ＭＰ１２１は、新データに対応する更新前のデータ（旧データ）を格納しているＦＭＰＫ１６０(データＦＭＰＫ)に対してＸＤＷＲＩＴＥコマンドを実行する（Ｓ４３）。これにより、ＸＤＷＲＩＴＥコマンドを受領したデータＦＭＰＫは、ＸＤＷＲＩＴＥ処理（図５参照）を実行して、旧データと新データとを用いてＸＯＲ演算を行って、パリティを生成するための中間データを生成し、ＦＭＰＫ１６０のＢｕｆｆｅｒ１６１に格納する。なお、ＸＤＷＲＩＴＥ処理の詳細については後述する。
　次に、ＭＰ１２１は、ＦＭＰＫ１６０から中間データを取得するために、Ｂｕｆｆｅｒ１４３に領域を確保する（Ｓ４４）。次に、ＭＰ１２１は、データＦＭＰＫに対してＸＤＲＥＡＤコマンドを実行する（Ｓ４５）。これにより、ＸＤＲＥＡＤコマンドを受領したデータＦＭＰＫは、ＸＤＲＥＡＤ処理（図６参照）を実行して、中間データをＢＥＰＫ１４０に送信する。これにより、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に中間データが格納されることとなる。なお、ＸＤＲＥＡＤ処理の詳細については後述する。
　次に、ＭＰ１２１は、新データに対応するストライプ列のパリティを格納しているＦＭＰＫ１６０(パリティＦＭＰＫ)に対してＸＰＷＲＩＴＥコマンドを発行し、Ｂｕｆｆｅｒ１４３に格納されている中間データを送信し（Ｓ４６）、パリティ生成処理を終了する。なお、ＸＰＷＲＩＴＥコマンドを受領したパリティＦＭＰＫでは、中間データに基づいてパリティを生成するＸＰＷＲＩＴＥ処理（図７参照）が実行される。ＸＰＷＲＩＴＥ処理についての詳細は、後述する。
　図５は、実施例１に係るＸＤＷＲＩＴＥ処理のフローチャートである。
　ＸＤＷＲＩＴＥ処理は、ＦＭＰＫ１６０がＭＰ１２１からＸＤＷＲＩＴＥコマンドを受領した際に実行される。
　ＸＤＷＲＩＴＥ処理では、ＦＭＰＫ１６０がＭＰ１２１からＸＤＷＲＩＴＥコマンドを受領する（Ｓ５１）と、ＦＭＰＫ１６０のパッケージプロセッサ１６３は、ＭＰ１２１によって転送されたライトデータ(新データ)をＢｕｆｆｅｒ１６１に格納する（Ｓ５２）。次に、パッケージプロセッサ１６３はＸＤＷＲＩＴＥコマンドからコマンドの対象のデータ（新データ）は、ユーザデータであると判定して、フラッシュチップ１６６に格納されている、ライトデータに対応する古いデータ(旧データ)を圧縮させたデータを、圧縮・伸張回路１６４により伸張する（Ｓ５３）。次に、パッケージプロセッサ１６３は伸張した旧データをＢｕｆｆｅｒ１６１に格納する（Ｓ５４）。次に、パッケージプロセッサ１６３は、新データと旧データとをＸＯＲ演算して中間データを生成する（Ｓ５５）。次に、パッケージプロセッサ１６３は、ＸＤＷＲＩＴＥコマンドからコマンドの対象のデータ（新データ）はユーザデータと判定し、圧縮・伸張回路１６４により、新データを圧縮する（Ｓ５６）。次に、パッケージプロセッサ１６３は、圧縮された新データをフラッシュチップ１６６に格納する（Ｓ５７）。これにより、ユーザデータについては、フラッシュチップ１６６に圧縮されて格納されることとなる。なお、データの圧縮・伸張処理は、専用の圧縮・伸張回路１６４を用いずに、パッケージプロセッサ１６３が行っても良い。また、ＸＯＲ演算を、専用の回路を用いて実施するようにしても良い。
　図６は、実施例１に係るＸＤＲＥＡＤ処理のフローチャートである。
　ＸＤＲＥＡＤ処理は、ＦＭＰＫ１６が、ＭＰ１２１からＸＤＲＥＡＤコマンドを受領した際に実行される。
　ＦＭＰＫ１６０がＸＤＲＥＡＤコマンドを受領すると（Ｓ６１）、ＦＭＰＫ１６０のパッケージプロセッサ１６３は、ＸＤＲＥＡＤコマンドにより指定されたアドレスに対応するＢｕｆｆｅｒ１６１の領域に中間データがあるか否かを判定する（Ｓ６２）。この結果、中間データが存在する場合（Ｓ６２：Ｙｅｓ）には、パッケージプロセッサ１６３は、Ｂｕｆｆｅｒ１６１の中間データをＭＰ１２１に応答し、ＸＤＲＥＡＤ処理を終了する。一方、中間データが存在しない場合（Ｓ６２：Ｎｏ）には、異常終了応答をＭＰ１２１に応答し（Ｓ６４）、ＸＤＲＥＡＤ処理を終了する。
　図７は、実施例１に係るＸＰＷＲＩＴＥ処理のフローチャートである。
　ＸＰＷＲＩＴＥ処理は、ＦＭＰＫ１６０が、ＭＰ１２１からＸＰＷＲＩＴＥコマンドを受領した際に実行される。
　ＦＭＰＫ１６０は、ＸＰＷＲＩＴＥコマンドを受領すると（Ｓ７１）、ＦＭＰＫ１６０のパッケージプロセッサ１６３は、ＭＰ１２１により転送された中間データをＢｕｆｆｅｒ１６１に格納する（Ｓ７２）。次に、受領したコマンドがＸＰＷＲＩＴＥコマンドであることから、入出力対象が冗長コードであり、伸張する必要がないので、パッケージプロセッサ１６３は、フラッシュチップ１６６から古い冗長コード(旧パリティ)を伸張することなく、Ｂｕｆｆｅｒ１６１に格納する（Ｓ７３）。次に、パッケージプロセッサ１６３は、中間データと旧パリティとをＸＯＲ演算することで新パリティを生成する（Ｓ７４）。次に、受領したコマンドがＸＰＷＲＩＴＥコマンドであることから、入出力対象が冗長コードであり、圧縮する必要がないので、パッケージプロセッサ１６３は、生成した新パリティを圧縮せずに、フラッシュチップ１６６に格納する（Ｓ７５）。
　本実施例によると、ストレージコントローラ１１から発行されたコマンドの種別からストレージデバイス(本実施例ではＦＭＰＫ１６０)が、入出力対象のデータが冗長コードであるか否かを把握でき、冗長コードである場合には、入出力対象のデータを非圧縮で記憶媒体に格納することができる。このため、ランダムライト時のストレージデバイスの処理負荷を軽減でき、ランダムライト性能を向上させることができる。また、冗長コードをストレージデバイスが作成するので、ストレージコントローラ１１の処理負荷を低減することができる。
　なお、実施例１では、ストレージデバイスが実行する付加処理として、圧縮・伸張処理を例に挙げているが、付加処理はこれに限られず、入出力データの状態を変更する処理や、入出力対象のデータに所定のデータ（保証コード等）を付加する処理でもよい。例えば、付加処理は、入力対象のデータを暗号化する暗号化処理であってもよい。また、付加処理を実行するか否かを判定する処理を実行するか否かを、管理計算機２０からの指示によりＯＮ/ＯＦＦするようにしてもよい。
　次に、実施例２に係る計算機システムについて説明する。なお、実施例２に係る計算機システムは、図１に示す実施例１に係る計算機システムと基本的には同様である。実施例２に係る計算機システムでは、冗長コードであるか否かを判定するための判定情報をストレージコントローラ１１がストレージデバイス（例えば、ＦＭＰＫ１６）に転送し、ストレージコントローラ１１から転送された判定情報をもとにストレージデバイスは冗長コードであるか否かを判定する。
　図８は、実施例２に係るパリティ判定情報登録処理の概要を示す図である。
　パリティ判定情報登録処理は、例えば、ホスト３０によりＩＯ処理が実行される前に、ストレージシステム１０で実行される。パリティ判定情報１２４（図９参照）は、例えば、予め作成されてＬＭ１２２に格納される。
　ストレージコントローラ１１のＭＰＰＫ１２０のＭＰ１２１は、ＬＭ１２２に格納されているパリティ判定情報１２４を各ＦＭＰＫ１６０に転送する。なお、各ＦＭＰＫ１６０に送信されるパリティ判定情報１２４は、そのＦＭＰＫ１６０で管理している領域についての情報を含んでいれば良い。ＦＭＰＫ１６０は、転送されたパリティ判定情報１２４をパッケージメモリ１６２に格納する（図８（１））。パリティ判定情報１２４は、ＦＭＰＫ１６０に対してＩＯコマンドが発行された際に、ＩＯコマンドの対象のデータが冗長コードであるか否かを判定するために利用される。
　図９は、実施例２に係るパリティ判定情報の一例の構成図である。
　パリティ判定情報１２４は、論理ボリューム（論理ＶＯＬ）の各ストライプのアドレス毎に、このストライプのデータが冗長コードであるか否かを示す情報である。パリティ判定情報１２４は、アドレスフィールド１２４ａと、属性フィールド１２４ｂとを含む。アドレスフィールド１２４ａには、論理ボリュームの先頭から終端までの固定サイズ（ストライプ）毎の先頭アドレスが格納される。なお、アドレスフィールド１２４ａに、ストライプの開始アドレスと終了アドレスとを格納しても良い。属性フィールド１２４ｂには、アドレスフィールド１２４ａの先頭アドレスに対応するストライプに格納されているデータが冗長コードであるか否かを示す値が格納される。例えば、ストライプに格納されているデータがユーザデータである場合には、属性フィールド１２４ｂには、「データ」が格納され、ストライプに格納されているデータが冗長コードである場合には、属性フィールド１２４ｂには、「パリティ」が格納される。
　パリティ判定情報としては、論理ＶＯＬ全体のストライプについてのエントリを持つのではなく、論理ＶＯＬの一部の領域の複数のストライプについてのエントリと、それらの繰り返し数を持つようにしても良い。
　また、ストレージコントローラ１１からＦＭＰＫ１６０にパリティ判定情報１２４を送信するようにしていたが、ストレージコントローラ１１からＲＡＩＤ構成とＲＡＩＤ構成におけるドライブ位置とを通知し、ＦＭＰＫ１６０がＲＡＩＤ構成と、ドライブ位置とに基づいて、パリティ判定情報１２４を生成するようにしても良い。また、予めストレージコントローラ１１からＦＭＰＫ１６０にパリティ判定情報１２４を登録するのではなく、ＩＯコマンドの発行時に、ＩＯコマンドに対して、もしくはＩＯコマンドの対象とする転送データに対して、パリティ判定情報１２４（又は、そのうちのＩＯコマンドの対象に対応する領域の情報のみ）を埋め込んで、ＦＭＰＫ１６０に通知するようにしても良い。
　図１０は、実施例２に係るＲＭＷパリティ生成処理の概要を示す図である。
　ストレージシステム１０のＭＰ１２１は、ホスト３０から受信したライトデータ(以下、新Ｄ１)を、ＦＥＰＫ１００を介してＣＭＰＫ１３０のＣＭ１３１に格納する（図１０（１））。ＭＰ１２１は、新Ｄ１と同一アドレスに格納されている古いデータ(以下、旧Ｄ1)をリードするＲＥＡＤコマンドをＦＭＰＫ１６０に発行し、旧Ｄ１をリードする（図１０（２）、（３）、（４））。具体的には、ＲＥＡＤコマンドを受領したＦＭＰＫ１６０は、パッケージメモリ１６２に格納されたパリティ判定情報１２４に基づいて、旧Ｄ１が冗長コードであるか否かを判定する。ここでは、旧Ｄ１は冗長コードではないと判定されるため、ＦＭＰＫ１６０は、旧Ｄ１は圧縮されてフラッシュチップ１６６に格納されていると判定する。ここで、旧Ｄ１を圧縮したデータを旧ｃＤ１とする。ＦＭＰＫ１６０は、フラッシュチップ１６６に格納されている旧ｃＤ１を圧縮・伸張回路１６４により伸張して旧Ｄ１を取得し（図１０（２））、旧Ｄ１をＢｕｆｆｅｒ１６１に格納し（図１０（３））、ＲＥＡＤコマンドで指定されたＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に転送する（図１０（４））。
　次に、ＭＰ１２１は、旧Ｄ１に対応する冗長コード(以下、旧Ｐ)をリードするＲＥＡＤコマンドを、旧Ｐを格納するＦＭＰＫ１６０に発行し、旧Ｐをリードする（図１０（５）、（６））。具体的には、ＲＥＡＤコマンドを受領したＦＭＰＫ１６０は、パリティ判定情報１２４から旧Ｐが冗長コードであると判定し、旧Ｐは圧縮されずにフラッシュチップ１６６に格納されていると判定する。ＦＭＰＫ１６０は、フラッシュチップ１６６から旧Ｐを伸張することなくＢｕｆｆｅｒ１６１に格納し（図１０（５））、ＲＥＡＤコマンドで指定されたＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に転送する（図１０（６））。
　次に、ＭＰ１２１は、ＦＭＰＫ１６０によりＢｕｆｆｅｒ１４３に格納されたデータ（旧Ｄ、旧Ｐ）をＣＭＰＫ１３０に読み込み（図１０（７））、新Ｄ1と、旧Ｄ１と、旧ＰとをＸＯＲ演算することで、新Ｄ１に対応する新しい冗長コード(新Ｐ)を生成し、ＣＭＰＫ１３０に格納する（図１０（８））。
　また、ＭＰ１２１は、ＣＭＰＫ１３０の新ＰをＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に転送し（図１０（９））、ＦＭＰＫ１６０にＷＲＩＴＥコマンドを発行する（図１０（１０））。ＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、新ＰをＢｕｆｆｅｒ１６１に格納する。次いで、ＦＭＰＫ１６０は、パリティ判定情報１２４から新Ｐは冗長コードであると判定して、圧縮せずにフラッシュチップ１６６に格納すると判定する。ＦＭＰＫ１６０は、新ＰをＢｕｆｆｅｒ１６１から取り出し、圧縮せずにフラッシュチップ１６６に格納する（図１０（１１））。
　この処理によると、冗長コードである旧Ｐを読み出す際に伸張せずに済み、ストレージデバイスの処理負荷を軽減できるとともに、新Ｐを書き込む際に、新Ｐを圧縮せずに済み、ストレージデバイスの処理負荷を軽減することができる。
　図１１は、実施例２に係る全ストライプパリティ生成処理の概要を示す図である。
　全ストライプパリティ生成処理は、ＣＭＰＫ１３０にストライプ列の全てのデータが格納されている場合に実行される冗長コードを生成する処理である。
　ストレージシステム１０のＭＰ１２１は、ホスト３０から受信したライトデータ(以下、新Ｄ１～新Ｄｎという)を、ＦＥＰＫ１００を介して、ＣＭＰＫ１３０のＣＭ１３１に格納する（図１１（１））。ＭＰ１２１は、同一のストライプ列を構成する全てのデータ（新Ｄ１～新Ｄｎ）を用いてＸＯＲ演算を実施することでライトデータに対応する冗長コード(新Ｐ)を生成し、ＣＭＰＫ１３０に格納する（図１１（２））。
　ＭＰ１２１は、ＢＥＰＫ１４０を介してＦＭＰＫ１６０に対して、新ＰをＷＲＩＴＥするＷＲＩＴＥコマンドを発行する（図１１（３））。ＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、Ｂｕｆｆｅｒ１６１に新Ｐを格納する。ＦＭＰＫ１６０は、パリティ判定情報１２４から新Ｐが冗長コードであると判定し、フラッシュチップ１６６に新Ｐを圧縮せずに格納すると判定する。ＦＭＰＫ１６０は、新Ｐを圧縮せずにフラッシュチップ１６６に格納する（図１１（４））。
　この処理によると、新Ｐを書き込む際に、新Ｐを圧縮せずに済み、ストレージデバイスの処理負荷を軽減することができる。
　図１２は、実施例２に係るパリティ生成処理のフローチャートである。
　パリティ生成処理では、同一ストライプ列のデータが全て揃っているか否かに応じて、冗長コードの生成方法を変更する。同一ストライプ列のデータが全て揃っている場合は、図１１に示す全ストライプライトパリティ生成処理を実施する。一方、同一ストライプ列のデータが揃っていない場合は、図１０に示すＲＭＷパリティ生成処理を実施する。
　パリティ生成処理では、まず、ＭＰ１２１がＣＭＰＫ１３０の中からパリティ生成前のデータ(以下、新Ｄ)を検出する(Ｓ１２１)。次に、ＭＰ１２１は、新Ｄの属するストライプ列のデータが全てＣＭＰＫ１３０内に格納されているかを判定する(Ｓ１２２)。
　この結果、ＣＭＰＫ１３０内に新Ｄの属するストライプ列のデータが全て揃っている場合（Ｓ１２２：Ｙｅｓ）には、ＭＰ１２１は、新Ｄに対応する冗長コード(新Ｐ)を格納する領域をＣＭＰＫ１３０に確保する(Ｓ１２９)。次に、ＭＰ１２１はＣＭＰＫ１３０にある新Ｄの属するストライプ列の全データをＸＯＲ演算することで新Ｐを生成し、ＣＭＰＫ１３０の確保している領域に格納する(Ｓ１３０)。次に、ＭＰ１２１は、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に新Ｐ用の領域を確保し、その領域に新Ｐを格納する(Ｓ１３１)。次に、ＭＰ１２１は、このストライプ列に対応する冗長コードを格納しているＦＭＰＫ１６０に対して新ＰをＷＲＩＴＥするＷＲＩＴＥコマンドを発行する(Ｓ１３２)。これにより、ＦＭＰＫ１６０では、ＷＲＩＴＥ処理（図１４参照）が実行され、新Ｐが格納されることとなる。
　一方、ＣＭＰＫ１３０内に新Ｄの属するストライプ列のデータが全て揃っていない場合（Ｓ１２２：Ｎｏ）には、ＭＰ１２１は、新Ｄの更新前のデータ(以下、旧Ｄ)を格納する領域をＣＭＰＫ１３０及びＢＥＰＫ１４０のＢｕｆｆｅｒ１３１、１４３に確保する(Ｓ１２３)。次に、ＭＰ１２１は、旧Ｄが格納されているＦＭＰＫ１６０に対して、旧ＤをＲＥＡＤするためのＲＥＡＤコマンドを発行する(Ｓ１２４)。これにより、ＦＭＰＫ１６０では、ＲＥＡＤ処理（図１３参照）が実行され、ＣＭＰＫ１３０及びＢＥＰＫ１４０のＢｕｆｆｅｒ１３１、１４３に旧Ｄが格納されることとなる。
　次に、ＭＰ１２１は、旧Ｄに対応する冗長コード(以下、旧Ｐ)を格納する領域をＣＭＰＫ１３０及びＢＥＰＫ１４０のＢｕｆｆｅｒ１３１、１４３に確保する(Ｓ１２５)。次に、ＭＰ１２１は、旧Ｐが格納されているＦＭＰＫ１６０に対して、旧ＰをＲＥＡＤするためのＲＥＡＤコマンドを発行する(Ｓ１２６)。これにより、ＦＭＰＫ１６０では、ＲＥＡＤ処理（図１３参照）が実行され、ＣＭＰＫ１３０及びＢＥＰＫ１４０のＢｕｆｆｅｒ１３１、１４３に旧Ｐが格納されることとなる。
　次に、ＭＰ１２１は、ＣＭＰＫ１３０に新Ｐを格納する領域を確保する(Ｓ１２７)。次に、ＭＰ１２１は、新Ｄと、旧Ｄと、旧ＰとをＸＯＲ演算することで新Ｐを生成し、確保している領域に格納する(Ｓ１２８)。次に、ＭＰ１２１は、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に新Ｐを格納する領域を確保する(Ｓ１３１)。次に、ＭＰ１２１はこのストライプ列に対応する冗長コードを格納しているＦＭＰＫ１６０に対して新ＰをＷＲＩＴＥするＷＲＩＴＥコマンドを発行する(Ｓ１３２)。これにより、ＦＭＰＫ１６０では、ＷＲＩＴＥ処理（図１４参照）が実行され、新Ｐが格納されることとなる。
　図１３は、実施例２に係るＲＥＡＤ処理のフローチャートである。
　ＲＥＡＤ処理は、ＲＥＡＤコマンドを受領したＦＭＰＫ１６０によって実行される処理である。
　ＦＭＰＫ１６０は、ＲＥＡＤコマンドを受領する(Ｓ１４１)と、パッケージメモリ１６２に格納しているパリティ判定情報１２４とＲＥＡＤコマンド中のＲＥＡＤ対象アドレスとを用いてＲＥＡＤ対象が冗長コード（パリティ）であるか否かを判定する(Ｓ１４２)。
　この結果、ＲＥＡＤ対象が冗長コードでないと判定した場合、すなわち、ＲＥＡＤ対象がデータ（ユーザデータ）である場合（Ｓ１４２：データ）は、ＦＭＰＫ１６０は、ＲＥＡＤ対象が冗長コードではないために、フラッシュパッケージ１６６には圧縮して格納されていると判定し、ＲＥＡＤ対象のデータを圧縮・伸張回路１６４を介して伸張する(Ｓ１４３)。次に、ＦＭＰＫ１６０は、伸張したＲＥＡＤ対象のデータをＢｕｆｆｅｒ１６１に格納し(Ｓ１４４)、データをＢＥＰＫ１４０に対して送信する（Ｓ１４５）。
　一方、ＲＥＡＤ対象が冗長コードであると判定した場合（Ｓ１４２：パリティ）には、ＦＭＰＫ１６０は、ＲＥＡＤ対象が冗長コードであるためフラッシュパッケージ１６６に圧縮せずに格納されていると判定し、ＲＥＡＤ対象の冗長コードをフラッシュチップ１６６から伸張せずにＢｕｆｆｅｒ１６１に格納する(Ｓ１４４)。次に、ＦＭＰＫ１６０は、Ｂｕｆｆｅｒ１６１のリード対象の冗長コードをＢＥＰＫ１４０に対して送信する（Ｓ１４５）。
　このＲＥＡＤ処理によると、冗長コードを読み出す際に伸張せずに済み、ストレージデバイスの処理負荷を軽減できる。
　図１４は、実施例２に係るＷＲＩＴＥ処理のフローチャートである。
　ＷＲＩＴＥ処理は、ＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０によって実行される処理である。
　まず、ＦＭＰＫ１６０は、ＷＲＩＴＥコマンドを受領する(Ｓ１５１)と、ＷＲＩＴＥ対象のデータ（ユーザデータ又は冗長コード）をＢｕｆｆｅｒ１６１に格納する(Ｓ１５２)。次に、ＦＭＰＫ１６０は、パッケージメモリ１６２に格納されているパリティ判定情報１２４と、ＷＲＩＴＥコマンド中のＷＲＩＴＥ対象のアドレスとを用いて、ＷＲＩＴＥ対象のデータが冗長コードであるか否かを判定する(Ｓ１５３)。
　この結果、ＷＲＩＴＥ対象が冗長コードでないと判定した場合、すなわち、ＷＲＩＴＥ対象がデータ（ユーザデータ）である場合（Ｓ１５３：データ）には、ＦＭＰＫ１６０は、ＷＲＩＴＥ対象は冗長コードではないためフラッシュパッケージ１６６に圧縮して格納さすると判定し、ＷＲＩＴＥ対象のデータを圧縮・伸張回路１６４を介して圧縮し(Ｓ１５４)、ＷＲＩＴＥ対象のデータをフラッシュチップ１６６へ格納する(Ｓ１５５)。
　一方、ＷＲＩＴＥ対象が冗長コードであると判定した場合（Ｓ１５３：パリティ）には、ＦＭＰＫ１６０は、ＷＲＩＴＥ対象は冗長コードであるためフラッシュパッケージ１６６に圧縮せずに格納すると判定し、冗長コードを圧縮せずに、フラッシュチップ１６６へ格納する(Ｓ１５５)。
　このＷＲＩＴＥ処理によると、冗長コードを書き込む際に圧縮せずに済み、ストレージデバイスの処理負荷を軽減できる。
　図１５は、実施例２に係るコレクションコピー処理の概要を示す図である。
　コレクションコピー処理は、ＲＡＩＤグループを構成するストレージデバイスの一部が故障した際に、故障したストレージデバイスに格納されていたデータを復元するために実行する処理である。
　まず、ＭＰ１２１は、復元対象のデータ(以下、Ｄ１)を含むストライプ列のデータ(以下、Ｄ２～Ｄｎ)及び冗長コード(以下、Ｐ)をＲＥＡＤするためのＲＥＡＤコマンドを、それぞれのＦＭＰＫ１６０に発行し、ＦＭＰＫ１６０からＤ２～Ｄｎ及びＰを取得し、ＣＭＰＫ１３０に格納する（図１５（１）乃至（５））。次に、ＭＰ１２１は、ＣＭＰＫ１３０に格納したデータ(Ｄ２～Ｄｎ)とＰとをＸＯＲ演算することでＤ１を復元する（図１５（６））。次に、ＭＰ１２１は、Ｄ１を格納させるスペア用のＦＭＰＫ１６０に対して、Ｄ１をＷＲＩＴＥするためのＷＲＩＴＥコマンドを発行する（図１５（７）、（８））。これにより、ＦＭＰＫ１６０では、ＷＲＩＴＥ処理が実行されて、Ｄ１が圧縮されてフラッシュチップ１６６に格納されることとなる（図１５（９））。なお、コレクションコピー処理で発行されるＲＥＡＤ／ＷＲＩＴＥコマンドを受領してＦＭＰＫ１６０で実行されるＲＥＡＤ処理及びＷＲＩＴＥ処理は、図１３、図１４に示した通りである。
　図１６は、実施例２に係るコレクションコピー処理のフローチャートである。図１６は、図１５に示すコレクションコピー処理を実現するフローチャートである。
　まず、ＭＰ１２１は、スペア用のＦＭＰＫ１６０に対してパリティ判定情報１２４を図８に示す方法で登録する(Ｓ１６１)。次に、ＭＰ１２１は、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３と、ＣＭＰＫ１３０とに、ストライプ列のデータ及び冗長コードを格納する領域を確保する(Ｓ１６２)。次に、ＭＰ１２１は、故障の発生したＦＭＰＫ１６０に格納されていたデータ(以下、Ｄ１)を除く、処理対象の或るストライプ列のデータ(以下、Ｄ２～Ｄｎ)及び冗長コード(以下、Ｐ)をＲＥＡＤするＲＥＡＤコマンドを各ＦＭＰＫ１６０に発行する(Ｓ１６３)。これにより、ＦＭＰＫ１６０では、ＲＥＡＤ処理（図１３参照）が実行され、ＣＭＰＫ１３０及びＢＥＰＫ１４０のＢｕｆｆｅｒ１３１、１４３にＤ２～Ｄｎ及びＰが格納されることとなる。
　次に、ＭＰ１２１は、Ｄ２～Ｄｎ及びＰをＸＯＲ演算することで故障したＦＭＰＫ１６０に格納されていたＤ１を復元する(Ｓ１６４)。次に、ＭＰ１２１は、ＢＥＰＫ１４０のＢｕｆｆｅｒ１４３にＤ１を格納する領域を確保して格納する(Ｓ１６５)。次に、ＭＰ１２１は、スペア用のＦＭＰＫ１６０に復元したＤ１をＷＲＩＴＥするためのＷＲＩＴＥコマンドを発行する(Ｓ１６６)。これにより、ＦＭＰＫ１６０では、ＷＲＩＴＥ処理（図１４参照）が実行され、フラッシュチップ１６６にＤ１が格納されることとなる。
　次に、ＭＰ１２１は、故障したＦＭＰＫ１６０の最後の領域のデータまで復元したか否かを判定する(Ｓ１６７)。この結果、最後の領域まで復元していない場合（Ｓ１６７：Ｎｏ）には、ＭＰ１２１は、処理対象を次の領域に変更し(Ｓ１６８)、処理対象の領域について、Ｓ１６２～Ｓ１６７の処理を実施する。一方、最後の領域まで復元している場合（Ｓ１６７：Ｙｅｓ）には、ＭＰ１２１は、コレクションコピー処理を終了する。
　本実施例では、ストレージデバイスが実行する付加処理としては、圧縮処理を例として説明していたが、付加処理としては、暗号化処理であっても良い。また、付加処理を実行するか否かを判定する処理を実行するか否かを、管理計算機２０からの指示によりＯＮ/ＯＦＦするようにしてもよい。
　次に、実施例３に係る計算機システムについて説明する。なお、実施例３に係る計算機システムは、図１に示す実施例１に係る計算機システムと基本的には同様である。実施例３に係る計算機システムでは、冗長コードであるか否かを判定するための判定情報をストレージコントローラ１１がストレージデバイス（例えば、ＦＭＰＫ１６）に転送し、ストレージコントローラ１１から転送された判定情報及びコマンドの種類をもとにストレージデバイスは冗長コードであるか否かを判定する。冗長コードの判定方法は、実施例１や実施例２で説明したいずれの方法でも良い。また、実施例３では、冗長コードの生成方法として、２つの方法がある。１つは、実施例１と同様に、圧縮前のデータに基づいて冗長コードを生成する方法であり、もう１つは、圧縮後のデータに基づいて冗長コードを生成する方法である。圧縮後のデータに対して冗長コードを生成するようにすると、ＲＡＩＤグループを構成するストレージデバイスのいずれかに障害が発生した場合の復元処理(以下、リビルド)において、冗長コードだけでなく、データについても圧縮／伸張をすることなく、データ（正確には、フラッシュチップ１６６に格納させる圧縮されたデータ）の復元が可能となり、リビルド処理の高速化が可能となる。
　図１７は、実施例３に係る圧縮後データを用いてパリティを生成する場合の、ＲＭＷパリティ生成処理の概要を示す図である。
　まず、ＭＰ１２１は、ＷＲＩＴＥデータ(以下、新Ｄ１)に対応するストライプ列の冗長コードを格納しているＦＭＰＫ１６０から、新Ｄ１に対応するストライプ列の古い冗長コード（旧Ｐ）が圧縮後のデータに対して作成されたものであるか否かを示すパリティ生成契機情報（生成契機情報）を取得する（図１７（１）、（２））。ＭＰ１２１は、取得した情報に基づいて圧縮後のデータに対して作成された冗長コードであるか否かを判定する。図１７の例では、旧Ｐは圧縮後のデータに対して作成された冗長コードであると判定される。ＭＰ１２１は、新Ｄ１を対象に、ＦＭＰＫ１６０に対してＸＤＷＲＩＴＥコマンドを発行する（図１７（３））。このとき、ＭＰ１２１は、ＸＤＷＲＩＴＥコマンドに対して圧縮後のデータに対して冗長コードを生成することを指示する情報を付与する(以降、圧縮後のデータに対して冗長コードを生成することを指示する情報が付与されたコマンドを、コマンド名の後ろに(ＲＡＷ）を付与して記載する。)。ＸＤＷＲＩＴＥ(ＲＡＷ)コマンドを受領したＦＭＰＫ１６０は、新Ｄ１をＢｕｆｆｅｒ１６１に格納する。
　次に、ＦＭＰＫ１６０は、新Ｄ１の更新前のデータ(以下、旧Ｄ１)の圧縮データ(以下、旧ｃＤ１)をフラッシュチップ１６６からＢｕｆｆｅｒ１６１に格納する（図１７（４））。次に、ＦＭＰＫ１６０は、圧縮・伸張回路１６４により新Ｄ１を圧縮して圧縮データ（新ｃＤ１)を生成し、新ｃＤ１をフラッシュチップ１６６に格納する（図１７（５））。次に、ＦＭＰＫ１６０は、新ｃＤ１をＢｕｆｆｅｒ１６１に格納する（図１７（６））。次に、ＦＭＰＫ１６０は、新ｃＤ１と旧ｃＤ１とのサイズをあわせるためにパディング（図中ｐａｄ）を入れる（図１７（７））。パディングを入れたデータを生成する方法としては、予めパディング用の値（例えば、０等）を格納している所定の長さの領域に新ｃＤ１を上書きするようにして生成しても良いし、ＦＭＰＫ１６０が新ｃＤ１に対してパディング用の値を追加するように生成しても良いし、バス転送装置１６５などのハードウェアにより転送時に付与するようにしても良い。以降の実施例において、パディングを入れたデータを生成する処理は、いずれの方法をとっても良い。
　次に、ＦＭＰＫ１６０はパディングを入れてデータサイズをそろえた新ｃＤ１と旧ｃＤ１とのＸＯＲ演算を実施することで冗長コードを生成するための中間データ(中間ｃＤ１ )を生成する（図１７（８））。次に、ＦＭＰＫ１６０は、中間ｃＤ１に対して新ｃＤ１のサイズ情報(ＳｉｚｅｃＤ１)を付与してＢｕｆｆｅｒ１６１に格納する（図１７（９））。サイズ情報は、データに埋め込んでも良いし、コマンドに埋め込んでも良い。また、サイズ情報は、圧縮ブロック単位毎に持つ。なお、サイズ情報を付与する代わりに、データ(新ｃＤ１)の各圧縮ブロック単位の終端に終端記号を埋め込むようにしても良い。
　次に、ＭＰ１２１は、ＦＭＰＫ１６０に対してＸＤＲＥＡＤ(ＲＡＷ)コマンドを発行し、中間ｃＤ１をＢＥＰＫ１４０のＢｕｆｆｅｒ１４３に読み込む（図１７（１０））。次に、ＭＰ１２１は、Ｄ１に対応するストライプ列のパリティを格納しているＦＭＰＫ１６０に対してＸＰＷＲＩＴＥ(ＲＡＷ)コマンドを発行する（図１７（１１））。ＸＰＷＲＩＴＥ（ＲＡＷ）コマンドを受領したＦＭＰＫ１６０は、ＸＰＷＲＩＴＥコマンドによって転送された中間ｃＤ１、ＳｉｚｅｃＤ１、パリティ生成契機情報をＢｕｆｆｅｒ１６１に格納する。
　次に、ＦＭＰＫ１６０は、旧Ｄ１に対応する冗長コード（旧Ｐ）及び冗長コードに付与されたパリティストライプ内の各データのサイズ情報(Ｓｉｚｅ)をＢｕｆｆｅｒ１６１に読み込む（図１７（１２））。次に、ＦＭＰＫ１６０は、中間ｃＤ１の圧縮ブロック毎にパディングを入れて旧Ｐとのサイズをそろえる（図１７（１３））。次に、ＦＭＰＫ１６０は、サイズをそろえた、中間ｃＤ１と旧ＰとをＸＯＲ演算することで、新Ｄ１に対応する冗長コード(以下、新Ｐ)を生成する（図１７（１４））。次に、ＦＭＰＫ１６０は、ＳｉｚｅｃＤ１に基づいて、Ｓｉｚｅ内のＤ１に対応するサイズ情報を更新して新Ｐに付与し、パリティ生成契機情報として圧縮後にパリティが生成されたことを示す情報（ｐｏｓｔ）を新Ｐに付与して、フラッシュチップ１６６に格納する（図１７（１５）、（１６））。冗長コードに付与するＳｉｚｅやパリティ生成契機情報は、データに埋め込んでも良いし、パッケージメモリ１６２などにアドレスに対応する情報として保持しても良いし、ＭＰＰＫ１２０のＬＭ１２２にアドレスに対応する情報として保持しても良い。
　図１８は、実施例３に係る圧縮前データを用いてパリティを生成する場合の、ＲＭＷパリティ生成処理の概要を示す図である。なお、ＲＭＷパリティ生成処理は、図３に示す実施例１のパリティ生成処理と同様な部分があるので、同様な部分については説明を省略し、差分のみを説明する。
　まず、ＭＰ１２１は、パリティの生成契機を判定するためにＦＭＰＫ１６０から新Ｄ１に対応する冗長コード(旧Ｐ)のパリティ生成契機情報を取得する（図１８（１）、（２））。ＭＰ１２１は、取得した情報に基づいて圧縮後のデータに対して作成された冗長コードであるか否かを判定する。図１８の例では、旧Ｐは圧縮前のデータに対して作成された冗長コードであると判定される。次に、ＭＰ１２１は、図３の例と同様にＦＭＰＫ１６０に対してＸＤＷＲＩＴＥコマンド、ＸＤＲＥＡＤコマンドを発行して、中間Ｄ１を取得する（図１８（３）～（８））。次に、ＭＰ１２１は、中間Ｄ１にパリティ生成契機情報(圧縮前)を付与してＦＭＰＫ１６０に対してＸＰＷＲＩＴＥコマンドを発行する（図１８（９））。ＸＰＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、図３の例と同様に新Ｐを生成する（図１８（１０））。次に、ＦＭＰＫ１６０は、新Ｐにパリティ生成契機情報(圧縮前)を付与してフラッシュチップ１６６に格納する（図１８（１１）、（１２））。
　図１９は、実施例３に係る全ストライプパリティ生成処理の概要を示す図である。なお、実施例３に係る全ストライプパリティ生成処理は、図１１に示す全ストライプパリティ生成処理と同様な部分があるので、同様な部分についての説明は省略し、差分のみを説明する。
　まず、ＭＰ１２１は、図１１と同様に新Ｐを生成する（図１９（１）、（２））。次に、ＭＰ１２１は、新Ｄ１～新ＤｎをＷＲＩＴＥするＷＲＩＴＥコマンド（図１９のＷＲＩＴＥ（Ｄ））をＦＭＰＫ１６０に発行することにより、ＦＭＰＫ１６０に対してＷＲＩＴＥする（図１９（３））。次に、ＦＭＰＫ１６０は、新Ｐに対してパリティ生成契機情報(圧縮前：ｐｒｅ)を付与して、このデータをＷＲＩＴＥするＷＲＩＴＥコマンド（図１９のＷＲＩＴＥ（Ｐ））をＦＭＰＫ１６０に発行する（図１９（４））。ＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０では、ＷＲＩＴＥ処理が実行され、フラッシュチップ１６６にパリティ生成契機情報が付与された新Ｐが格納されることとなる（図１９（５））。
　図２０は、実施例３に係るＸＤＲＥＡＤ／ＸＤＷＲＩＴＥ／ＸＰＷＲＩＴＥコマンドの一例の構成図である。
　ＸＤＲＥＡＤ／ＸＤＷＲＩＴＥ／ＸＰＷＲＩＴＥコマンドのコマンド１７０は、コマンド種別１７０ａと、ＬＢＡ１７０ｂと、転送長１７０ｃと、パリティ生成契機１７０ｄと、圧縮ブロック数１７０ｅと、圧縮ブロックサイズ１７０ｆとを含む。コマンド種別１７０ａは、コマンドの種別を示す。コマンド種別としては、例えば、ＸＤＲＥＡＤ、ＸＤＷＲＩＴＥ、又はＸＰＷＲＩＴＥが設定される。ＬＢＡ１７０ｂは、論理ＶＯＬの論理ブロックアドレスである。転送長１７０ｃは、コマンドにより転送するデータの長さである。パリティ生成契機１７０ｄは、圧縮後のデータに対してパリティを生成するか、圧縮前のデータに対してパリティを生成するかのいずれであるかを示すパリティ生成契機情報である。パリティ生成契機１７０ｄは、圧縮後のデータに対してパリティを生成する場合には、「圧縮後（ｐｏｓｔ）」に設定され、圧縮前のデータに対してパリティを生成する場合には、「圧縮前（ｐｒｅ）」に設定される。圧縮ブロック数１７０ｅは、パリティ生成契機１７０ｄが「圧縮後」の時のみ有効なフィールドであり、転送するデータ中に含まれている圧縮ブロックの数を示す値である。圧縮ブロックサイズ１７０ｆは、パリティ生成契機１７０ｄが「圧縮後」の時のみ有効なフィールドであり、コマンド１７０は、圧縮ブロック数分だけ圧縮ブロックサイズ１７０ｆを持つ。各圧縮ブロックサイズ１７０は、各圧縮ブロックの圧縮後のサイズである。なお、パリティ生成契機１７０ｄ、圧縮ブロック数１７０ｅ、圧縮ブロックサイズ１７０ｆは、コマンドではなく、データに埋め込むようにしても良い。
　図２１は、実施例３に係るパリティ生成処理のフローチャートである。なお、図１２に示す実施例２に係るパリティ生成処理と同様な部分については、同一符号を付し、重複する説明を省略する。
　ＭＰ１２１は、パリティを生成する対象のデータの属するストライプ列のデータが全て揃っているか否かを判定する（Ｓ１２２）。この結果、ストライプ列のデータの全てが揃っていない場合（Ｓ１２２：Ｎｏ）には、ＲＭＷパリティ生成処理（図２２参照）を実行し（Ｓ２１２）、処理を終了する。一方、ストライプ列のデータ全てが揃っている場合（Ｓ１２２：Ｙｅｓ）には、ＭＰ１２１は、図１２と同様に新Ｐを生成し（Ｓ１２９～Ｓ１３１）、新Ｐにパリティ生成契機情報(圧縮前)を付与する(Ｓ２１１)。次に、ＭＰ１２１は、ＦＭＰＫ１６０に対してＷＲＩＴＥコマンドを発行し（Ｓ１３２）、処理を終了する。
　図２２は、実施例３に係るＲＭＷパリティ生成処理のフローチャートである。なお、図４に示すパリティ生成処理と同様な部分については、同一符号を付す。
　まず、ＭＰ１２１は、冗長コードを格納しているＦＭＰＫ１６０からパリティ生成契機情報を取得して、パリティ生成契機がいずれであるかを判定する(Ｓ２２１)。
　この結果、パリティ生成契機が圧縮後の場合（Ｓ２２１：圧縮後）において、ＭＰ１２１は、ＦＭＰＫ１６０にＸＤＷＲＩＴＥコマンドを発行する（Ｓ４３）。このとき、ＸＤＷＲＩＴＥコマンドに、パリティ生成契機が圧縮後であることを示すパリティ生成契機情報を付与する。また、ＭＰ１２１は、ＦＭＰＫ１６０に、中間データをＲＥＡＤするためのＸＤＲＥＡＤ(ＲＡＷ)コマンドを発行する(Ｓ４５)。次に、ＭＰ１２１はＲＥＡＤした中間データにパリティ生成契機情報(圧縮後)を付与する(Ｓ２２７)。次に、ＭＰ１２１は、ＦＭＰＫ１６０に対してＸＰＷＲＩＴＥ(ＲＡＷ)コマンドを発行する（Ｓ４７）。
　一方、パリティ生成契機が圧縮前の場合（Ｓ２２１：圧縮後）においては、ＭＰ１２１は、ＦＭＰＫ１６０にＸＤＷＲＩＴＥコマンドを発行する。このとき、コマンドには、パリティ生成契機が圧縮前である情報を付与する(Ｓ４３)。また、ＭＰ１２１は、ＦＭＰＫ１６０から中間データをＲＥＡＤするためのＸＤＲＥＡＤ(ＣＭＰ)コマンドを発行する(Ｓ４５)。次に、ＭＰ１２１はＲＥＡＤした中間データにパリティ生成契機情報(圧縮前)を付与する(Ｓ２２２)。次に、ＭＰ１２１は、ＦＭＰＫ１６０に対してＸＰＷＲＩＴＥ(ＣＭＰ)コマンドを発行する（Ｓ４７）。
　図２３は、実施例３に係るＸＤＷＲＩＴＥ処理のフローチャートである。なお、図５に示す実施例１に係るＸＤＷＲＩＴＥ処理と同様な部分には同一符号を付し、その処理との差分を中心に説明する。
　ＸＤＷＲＩＴＥ処理は、ＦＭＰＫ１６０がＸＤＷＲＩＴＥコマンドを受領した場合に実行する処理であり、ＦＭＰＫ１６０は、ＸＤＷＲＩＴＥコマンドを受領した場合には、そのコマンドの対象は、冗長コードではないとして処理を実行する。
　ＦＭＰＫ１６０は、ＸＤＷＲＩＴＥコマンドを受領した後（Ｓ５１、Ｓ５２の後）に、ＸＤＷＲＩＴＥコマンドの対象のデータに対するパリティ生成契機がいずれであるかを判定する(Ｓ２３１)。
　この結果、パリティ生成契機が圧縮前の場合（Ｓ２３１：圧縮前）には、ＦＭＰＫ１６０は、ステップＳ５３～Ｓ５７の処理を実行して、ＸＤＷＲＩＴＥ処理を終了する。
　一方、パリティ生成契機が圧縮後の場合（Ｓ２３１：圧縮後）には、ＦＭＰＫ１６０は圧縮・伸張回路１６４を介して新Ｄ１を圧縮した圧縮データ(以下、新ｃＤ１)を取得し(Ｓ２３２)、新ｃＤ１をフラッシュチップ１６６に格納する(Ｓ２３３)。次に、ＦＭＰＫ１６０は、新ｃＤ１をフラッシュチップ１６６からＢｕｆｆｅｒ１６１に読みこむ(Ｓ２３４)。次に、ＦＭＰＫ１６０は、圧縮後の旧データ(旧ｃＤ１)をＢｕｆｆｅｒ１６１に格納する(Ｓ２３５)。次に、ＦＭＰＫ１６０は、圧縮ブロック毎にパディングを入れて、新ｃＤ１と、旧ｃＤ１とのデータサイズをそろえる(Ｓ２３６)。次に、ＦＭＰＫ１６０は、サイズをそろえた新ｃＤ１及び旧ｃＤ１をＸＯＲ演算することで中間データ(以下、中間ｃＤ１)を生成する（Ｓ２３７）。次に、ＦＭＰＫ１６０は、新ｃＤ１内の各圧縮ブロックの圧縮後のサイズ情報を中間ｃＤ１に付与し(Ｓ２３８)、ＸＤＷＲＩＴＥ処理を終了する。
　図２４は、実施例３に係るＸＤＲＥＡＤ処理のフローチャートである。なお、図６に示す実施例１に係るＸＤＲＥＡＤ処理と同様な部分には同一符号を付し、その処理との差分を中心に説明する。
　ＸＤＲＥＡＤ処理は、ＦＭＰＫ１６０がＸＤＲＥＡＤコマンドを受領した場合に実行する処理であり、ＦＭＰＫ１６０は、ＸＤＲＥＡＤコマンドを受領した場合には、そのコマンドの対象は、冗長コードではないとして処理を実行する。
　ＸＤＲＥＡＤ対象の中間データがあった場合（Ｓ６２：Ｙｅｓ）には、ＦＭＰＫ１６０は、パリティ生成契機がいずれであるかを判定する(Ｓ２４１)。
　この結果、パリティ生成契機が圧縮前の場合（Ｓ２４１：圧縮前）には、ＦＭＰＫ１６０は、ステップＳ６３の処理を実行して、ＸＤＲＥＡＤ処理を終了する。一方、パリティ生成契機が圧縮後の場合（Ｓ２４１：圧縮後）には、ＦＭＰＫ１６０は、Ｂｕｆｆｅｒ１６１の中間データと、中間データに付与されたサイズ情報とを共に、ＭＰ１２１に送信する（Ｓ２４２）。
　図２５は、実施例３に係るＸＰＷＲＩＴＥ処理のフローチャートである。なお、図７に示す実施例１に係るＸＰＷＲＩＴＥ処理と同様な部分には同一符号を付し、ここでは、その処理との差分を中心に説明する。
　ＸＰＷＲＩＴＥ処理は、ＦＭＰＫ１６０がＸＰＷＲＩＴＥコマンドを受領した場合に実行する処理であり、ＦＭＰＫ１６０は、ＸＰＷＲＩＴＥコマンドを受領した場合には、そのコマンドの対象は、冗長コードであるとして処理を実行する。
　ステップＳ７３の次に、ＦＭＰＫ１６０は、ＸＰＷＲＩＴＥコマンドのパリティ生成契機がいずれであるかを判定する（Ｓ２５１）。
　この結果、パリティ生成契機が圧縮前であると判定した場合（Ｓ２５１：圧縮前）には、ＦＭＰＫ１６０は、旧パリティのパリティ生成契機がいずれであるかを判定する(Ｓ２５９)。この結果、旧パリティのパリティ生成契機が圧縮後であると判定した場合（Ｓ２５９：圧縮後）には、パリティ生成契機の整合性が取れていないので、ＦＭＰＫ１６０は、ＭＰ１２１に異常終了を応答し(Ｓ２５３)、処理を終了する。
　一方、旧パリティのパリティ生成契機が圧縮前であると判定した場合（Ｓ２５９：圧縮前）には、ＦＭＰＫ１６０は、中間データと、旧パリティとのＸＯＲ演算をすることにより新Ｐを生成し(Ｓ２６０)、新Ｐにパリティ生成契機(圧縮前)を付与し(Ｓ２６１)、新Ｐをフラッシュチップ１６６に格納し(Ｓ２６２)、処理を終了する。
　ステップＳ２５１で、パリティ生成契機が圧縮後であると判定した場合（Ｓ２５１：圧縮後）には、ＦＭＰＫ１６０は、旧パリティのパリティ生成契機がいずれであるかを判定する(Ｓ２５２)。この結果、旧パリティのパリティ生成契機が圧縮前であると判定した場合（Ｓ２５２：圧縮前）には、パリティ生成契機の整合性が取れていないので、ＦＭＰＫ１６０は、ＭＰ１２１に異常終了を応答し(Ｓ２５３)、処理を終了する。
　一方、旧パリティのパリティ生成契機が圧縮後であると判定した場合（Ｓ２５２：圧縮後）には、ＦＭＰＫ１６０は、サイズ情報から中間データの圧縮ブロック毎にパディングを実施する(Ｓ２５４)。次に、ＦＭＰＫ１６０は、パディングを実施した中間データと、旧ＰとをＸＯＲ演算することで新Ｐを生成する(Ｓ２５５)。次に、ＦＭＰＫ１６０は、中間データに付与されたサイズ情報に基づいて、旧Ｐに付与して格納していたサイズ情報を新Ｐに対応するサイズ情報に更新する(Ｓ２５６)。次に、ＦＭＰＫ１６０は、新Ｐにパリティ生成契機(圧縮後)を付与し(Ｓ２５７)、フラッシュチップ１６６に格納し(Ｓ２５８)、処理を終了する。
　この処理によると、パリティ生成契機に従って、各データのパリティを圧縮前のデータに基づいて生成することと、圧縮後のデータに基づいて生成することとを切り替えて実行することができるので、パリティ生成契機を各データの性質に応じて決定することにより、適切な契機におけるパリティを生成することができる。
　図２６は、実施例３に係る圧縮前データを用いて生成されたパリティを持つストライプ列のコレクションコピー処理の概要を示す図である。なお、このコレクションコピー処理は、図１５に示す実施例２のコレクションコピー処理と同様な部分があるので、同様な部分については説明を省略し、差分のみを説明する。
　ＭＰ１２１は、ＦＭＰＫ１６０から処理対象のストライプ列の冗長コードのパリティ生成契機情報を取得し（図２６（１）、（２））、このストライプ列においては、圧縮前にパリティの生成を実施したと判定する。次に、ＭＰ１２１は、図１５と同様にＤ１を復元し（図２６（３））、スペアのＦＭＰＫ１６０に格納する（図２６（４））。このとき、ＲＥＡＤ/ＷＲＩＴＥコマンドには、パリティ生成契機情報(圧縮前)を付与する。ここで、パリティ生成契機情報（圧縮前）が付与されたコマンドを、コマンド名の後ろに(ＣＭＰ）を付与して記載する。
　図２７は、実施例３に係る圧縮後データを用いて生成されたパリティを持つストライプ列のコレクションコピー処理の概要を示す図である。なお、このコレクションコピー処理は、図２６に示すコレクションコピー処理と同様な部分があるので、同様な部分については説明を省略し、差分のみを説明する。
　ＭＰ１２１は、ＦＭＰＫ１６１からパリティ生成契機を取得して、圧縮後にパリティ生成を実施したと判定する（図２７（１）、（２））。次に、ＭＰ１２１は、ＦＭＰＫ１６０からストライプ内のデータの圧縮後のサイズ情報を取得する（図２７（３））。次に、ＭＰ１２１は、各ＦＭＰＫ１６０からデータ(Ｄ２～Ｄｎ)と冗長化コード(Ｐ)とをＲＥＡＤするＲＥＡＤコマンドを発行し、それらを取得する（図２７（４）～（８））。このとき、ＭＰ１２１は、ＲＥＡＤコマンドに圧縮要否情報(圧縮不要)を付与する。ＲＥＡＤコマンド（ＣＭＰ）を受領したＦＭＰＫ１６０は、圧縮要否情報に基づいてフラッシュチップ１６６内に格納されている圧縮後のデータを伸張することなくＭＰ１２１に応答する。
　次に、ＭＰ１２１はサイズ情報に基づいて圧縮後のデータの各圧縮ブロックにパディングを入れてデータサイズをそろえる（図２７（９））。次に、ＭＰ１２１は、パディングを入れた各データと、ＰとをＸＯＲ演算することで圧縮後の復元対象のデータ(ｃＤ１)にパディングが入ったデータを生成する（図２７（１０）。次に、ＭＰ１２１は、サイズ情報に基づいて、パディングをなくして、ｃＤ１を生成する（図２７（１１））。次に、ＭＰ１２１は、スペアのＦＭＰＫ１６０に対してｃＤ１をＷＲＩＴＥするＷＲＩＴＥコマンドを発行する（図２７（１２））。このとき、ＭＰ１２１は、ＷＲＩＴＥコマンドに圧縮要否情報(圧縮不要)を付与する。このＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、圧縮要否情報に基づいて、ｃＤ１を、圧縮をすることなくフラッシュチップ１６６に格納する（図２７（１３））。なお、パディングを追加する／削除する処理は、ＭＰ１２１からＦＭＰＫ１６０がサイズ情報を受け取って、ＦＭＰＫ１６０がそのサイズ情報に基づいて実行するようにしても良い。なお、ＣＭＰＫ１３０においては、圧縮後のデータと、圧縮前のデータとを別管理をしており、ホストから圧縮後のデータが見えないようになっている。
　図２８は、実施例３に係るコレクションコピー処理のフローチャートである。なお、図１６に示す実施例２に係るコレクションコピー処理と同様な部分には同一符号を付し、ここでは、その処理との差分を中心に説明する。
　ＭＰ１２１は、復元対象のストライプ列のパリティが格納されているＦＭＰＫ１６０からパリティ生成契機を取得する(Ｓ２８１)。次に、ＭＰ１２１は、パリティ生成契機がいずれであるかを判定する(Ｓ２８２)。
　この結果、パリティ生成契機が圧縮前である場合（Ｓ２８２：圧縮前）には、ＭＰ１２１は、ステップＳ１６３～Ｓ１６６の処理を実行し、処理をステップＳ１６７に進める。
　一方、パリティ生成契機が圧縮後である場合（Ｓ２８２：圧縮後）には、ＭＰ１２１は、パリティを格納しているＦＭＰＫ１６０からパリティストライプ内のデータの圧縮後のサイズ情報を取得する。（Ｓ２８３）。次に、ＭＰ１２１は、復元に必要なストライプ列内のデータ（ｃＤ２～ｃＤｎ)、及び冗長コード(以下、Ｐ)をＦＭＰＫ１６０からＲＥＡＤするためのＲＥＡＤコマンドを発行する（Ｓ２８４）。このとき、ＭＰ１２１は、ＲＥＡＤコマンドに圧縮要否情報(圧縮不要)を付与する。これにより、ＲＥＡＤコマンドを受領したＦＭＰＫ１６０は、対象のデータ及び冗長コードをフラッシュチップ１６６から圧縮されたデータをそのまま読み出し、返却することとなる。従って、ＦＭＰＫ１６０では、データを伸張する処理をすることがなく、処理負荷を軽減することができる。次に、ＭＰ１２１は、サイズ情報に基づいて、データの圧縮ブロック毎にパディングを入れることで、ｃＤ２～ｃＤｎ及びＰのサイズをそろえる(Ｓ２８５)。
　次に、ＭＰ１２１は、ｃＤ２～ｃＤｎ、及びＰを用いて、復元対象のデータ(以下、ｃＤ１)にパディングが入っているデータを復元する(Ｓ２８６)。次に、ＭＰ１２１は、サイズ情報に基づいて復元したデータからパディングを削除して、復元対象のｃＤ１を生成する(Ｓ２８７)。次に、ＭＰ１２１は、ＢＥＰＫ１４０にｃＤ１用の領域を確保して格納し(Ｓ２８８)、スペア用のＦＭＰＫ１６０に対してｃＤ１をＷＲＩＴＥするＷＲＩＴＥコマンドを発行する（Ｓ２８９）。このとき、ＭＰ１２１は、ＷＲＩＴＥコマンドに圧縮情報(圧縮不要)を付与する。これにより、ＷＲＩＴＥコマンドを受領したＦＭＰＫ１６０は、ｃＤ１を圧縮することなくフラッシュチップ１６６に格納する。これにより、ＭＰ１２１は、圧縮処理を行うことがなく、処理負荷が軽減される。その後、ＭＰ１２１は、処理をステップＳ１６７に進める。
　このコレクションコピー処理では、復元対象のデータに対するパリティ生成契機が圧縮後である場合には、パリティだけでなく、データについてもＦＭＰＫ１６０で圧縮／伸張をすることなく、復元対象のデータ（厳密には、その復元対象のデータの圧縮データ）をフラッシュチップ１６６に復元させることができ、ＦＭＰＫ１６０の処理負荷が軽減し、リビルド処理を高速化することができる。
　図２９は、実施例３に係るＲＥＡＤ／ＷＲＩＴＥコマンドの一例の構成図である。
　ＲＥＡＤ／ＷＲＩＴＥコマンドのコマンド１７１は、コマンド種別１７１ａと、ＬＢＡ１７１ｂと、転送長１７１ｃと、圧縮実施要否１７１ｄとを含む。コマンド種別１７１ａは、コマンドの種別を示す。コマンド種別としては、例えば、ＲＥＡＤ、ＷＲＩＴＥが設定される。ＬＢＡ１７１ｂは、論理ＶＯＬの論理ブロックアドレスである。転送長１７１ｃは、コマンドにより転送するデータの長さである。圧縮実施要否１７１ｄは、ＲＥＡＤ/ＷＲＩＴＥ対象のデータに対してＦＭＰＫ１６０内で圧縮／伸張処理を実施するか否かを示す情報である。圧縮実施要否１７１ｄの値が、実施要の場合は、ＦＭＰＫ１６０は、その内部で圧縮／伸張処理を実施してＲＥＡＤ／ＷＲＩＴＥを実施する。ただし、ＦＭＰＫ１６０がパリティ判定情報１２４からＲＥＡＤ／ＷＲＩＴＥ対象が冗長コードであると判定した場合は、圧縮実施要否１７１ｄの値が実施要であってもＦＭＰＫ１６０内で圧縮／伸張処理を実施することなくＲＥＡＤ／ＷＲＩＴＥ処理を実施する。また、圧縮実施要否１７１ｄの値が実施不要の場合は、ＦＭＰＫ１６０は、その内部で圧縮／伸張処理を実施することなくＲＥＡＤ／ＷＲＩＴＥ処理を実施する。
　図３０は、実施例３に係るＲＥＡＤ処理のフローチャートである。なお、図１３に示す実施例２に係るＲＥＡＤ処理と同様な部分には同一符号を付し、ここでは、その処理との差分を中心に説明する。
　ＦＭＰＫ１６０は、ＲＥＡＤコマンドを受領する(Ｓ１４１)と、圧縮実施要否１７１ｄがいずれであるかを判定する(Ｓ３０１)。
　この結果、圧縮実施要否１７１ｄが実施要である場合（Ｓ３０１：実施要）には、ＦＭＰＫ１６０は、図１３と同様に、ステップＳ１４２～Ｓ１４５の処理を実行する。
　一方、圧縮実施要否１７１ｄが実施不要である場合（Ｓ３０１：実施不要）には、ＦＭＰＫ１６０は、フラッシュチップ１６６に格納されているＲＥＡＤ対象の圧縮後のデータを伸張することなくＢｕｆｆｅｒ１６１に格納する(Ｓ１４４)。次に、ＦＭＰＫ１６０は、ＲＥＡＤ対象のデータをＢＥＰＫ１４０に送信し(Ｓ１４５)、ＲＥＡＤ処理を終了する。
　図３１は、実施例３に係るＷＲＩＴＥ処理のフローチャートである。なお、図１４に示す実施例２に係るＷＲＩＴＥ処理と同様な部分には同一符号を付し、ここでは、その処理との差分を中心に説明する。
　ＦＭＰＫ１６０は、ＷＲＩＴＥコマンドを受領する(Ｓ１５１)と、ＷＲＩＴＥ対象をＢｕｆｆｅｒ１６１に受領し(Ｓ１５２)し、圧縮実施要否１７１ｄがいずれであるかを判定する(Ｓ３１１)。
　この結果、圧縮実施要否１７１ｄが実施要である場合（Ｓ３１１：実施要）には、ＦＭＰＫ１６０は、図１４と同様に、ステップＳ１５３～Ｓ１５５の処理を実行する。
　一方、圧縮実施要否１７１ｄが実施不要である場合（Ｓ３１１：実施不要）には、ＦＭＰＫ１６０は、Ｂｕｆｆｅｒ１６１に格納されているＷＲＩＴＥ対象のデータを圧縮することなくフラッシュチップ１６６に格納する(Ｓ１５５)。
　本実施例では、ストレージデバイスが実行する付加処理としては、圧縮処理を例として説明していたが、付加処理としては、暗号化処理であっても良い。付加処理を暗号化処理とする場合は、圧縮処理と異なり、データに対する処理実行後のデータサイズは変わらないため、上記したようなサイズ情報の保持、及びデータサイズをそろえる処理(パディング処理)は不要である。また、付加処理を実行するか否かを判定する処理を実行するか否かを、管理計算機２０からの指示によりＯＮ/ＯＦＦするようにしてもよい。
　次に、実施例４に係る計算機システムについて説明する。なお、実施例４に係る計算機システムは、図１に示す実施例１に係る計算機システムと基本的には同様である。実施例４に係る計算機システムでは、圧縮処理の機能や暗号化処理の機能といった付加処理の機能を有するストレージデバイス（例えば、ＦＭＰＫ１６０）が上位装置（例えば、ストレージコントローラ１１）から通知された情報に基づいて、付加処理の実施又は未実施を制御する。これにより、ストレージデバイスは、例えば、所定の領域に格納するデータのみに対して付加処理を未実施とするようにすることができ、ストレージデバイスのＩＯ処理性能を向上させることができる。ここで、ストレージデバイスの付加処理としては、圧縮処理や暗号化処理だけでなく、例えば、スナップショットの取得処理等であっても良い。
　また、上位装置から通知される情報は、実施例１乃至３のように、ＩＯ対象がパリティであるか否かを示す情報であっても良く、例えば、サーバで動作するアプリケーションプログラムの動作や運用に基づいて生成される、所定の領域のデータに対する付加処理の実施が不要であることを示す情報であっても良く、要は、付加処理の実施／未実施を判定可能な情報であれば良い。
　図３２は、実施例４に係る機能実施判定情報登録処理の概要を図である。なお、この機能実施判定情報登録処理は、図８に示すパリティ判定情報登録処理と同様な部分があるので、同様な部分については説明を省略し、差分のみを説明する。なお、図３２に示す機能実施判定情報登録処理では、図８に示すパリティ判定情報登録処理のパリティ判定情報１２４に代えて機能実施判定情報１２５をＦＭＰＫ１６６に登録するようになっている（図３２（１））となっている。
　機能実施判定情報１２５は、判定情報の一例であり、例えば、論理ＶＯＬの固定サイズの単位領域毎における付加処理を実施するか否かを示す情報（機能実施要否情報）である。ＦＭＰＫ１６０は、機能実施判定情報１２５に基づいて、ＩＯ処理の際に機能実施要否を判定し、付加処理を実施するか否かを判定する。機能実施判定情報１２５は、例えば、論理ＶＯＬの全体の各単位領域についての機能実施要否情報を保持しても良く、特定サイズ内の各単位領域について機能実施要否情報と、その特定サイズについての繰り返し数とを持つようにしても良い。また、機能実施判定情報１２５は、予めＦＭＰＫ１６０に登録するのではなく、ＩＯ毎にコマンド中もしくはコマンドに対応するデータ中に埋め込むようにして、ＦＭＰＫ１６０に通知するようにしても良い。
　図３３は、実施例４に係るコマンド処理の概要を示す図である。
　ＭＰ１２１は、ＢＥＰＫ１４０を介してＦＭＰＫ１６０に対してコマンドを発行する（図３３（１）、（２））。これに対して、ＦＭＰＫ１６０は、コマンドを受領し、コマンド中のアドレス情報と、機能実施判定情報１２５とに基づいて、コマンドによる入出力対象のデータ（図３３のＤ１又はＤ２）について、ドライブ機能部１６７による所定の付加処理の実施要否の判定を行う（図３３（３）、（４））。ドライブ機能部１６７は、所定の付加処理を実施する専用の回路であっても良いし、ＦＭＰＫ１６０のパッケージプロセッサ１６３により構成されても良い。
　ＦＭＰＫ１６０は、付加処理の実施が不要であると判定した場合（図３３中Ｄ１のケース）には、ドライブ機能部１６７による付加処理を実行することなくフラッシュチップ１６６にＤ１を格納する（図３３（５））。
　一方、ＦＭＰＫ１６０は、付加処理の実施が必要であると判定した場合(図３３中Ｄ２のケース)には、ドライブ機能部１６７によりＤ２に関する所定の付加処理を実行した後、付加処理を実行した後のデータをフラッシュチップ１６６に格納する（図３３（６））。
　なお、図３３では、フラッシュチップ１６６にデータを書き込む際の処理の概要について説明したが、フラッシュチップ１６６からデータを読み出す際には、書き込む際の処理に対応する処理を行えば良い。具体的には、ＦＭＰＫ１６０は、付加処理の実施が不要であると判定した場合（Ｄ１を読み出すケース）には、フラッシュチップ１６０から付加処理を実行しないでそのままデータを読み出すようにし、付加処理の実施が必要であると判定した場合（Ｄ２を読み出すケース）には、フラッシュチップ１６０のデータに対してドライブ機能部１６７による付加処理を実行して読み出すようにすれば良い。
　図３４は、実施例４に係るコマンド処理のフローチャートである。
　コマンド処理は、ストレージコントローラ１１から発行されたコマンドを受領したＦＭＰＫ１６０が実行する処理である。
　ＦＭＰＫ１６０は、コマンドを受領する(Ｓ３４１)と、コマンドの対象のアドレス情報、及び機能実施判定情報１２５とに基づいて、そのアドレス情報が示すアドレスのデータに対して、所定の付加処理を実施するか否か（機能実施要否）を判定する(Ｓ３４２)。
　この結果、所定の付加処理を実施する必要があると判定した場合（Ｓ３４２：実施要）には、ＦＭＰＫ１６０は、コマンドの対象のデータに対してドライブ機能部１６７により、所定の付加処理を実施し(Ｓ３４３)、コマンドに対応する処理（例えば、データのＩＯ処理）を実施し(Ｓ３４４)、コマンド処理を終了する。
　一方、所定の付加処理を実施する必要がないと判定した場合（Ｓ３４２：実施不要）には、ＦＭＰＫ１６０は、ドライブ機能部１６７による付加処理は行わずに、コマンドに対応する処理（例えば、データのＩＯ処理）を実施する(Ｓ３４４)。
　この処理によると、ＦＭＰＫ１６０は、付加処理を実行する必要がないデータに対しては、付加処理を実行せずに、コマンドに対応する処理のみを実行するので、ＦＭＰＫ１６０における処理負荷を軽減することができる。
　以上、本発明の幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
　３０…ホスト計算機　１０…ストレージシステム　１１…ストレージコントローラ　１６０…ＦＭＰＫ　１６６…フラッシュチップ。

Claims (15)

  1. 　データを格納する記憶媒体と、前記データに対して前記データの状態の変更を伴う付加処理を実行するデバイスコントローラと、を有するストレージデバイスと、
    　前記ストレージデバイスへのデータの入出力を制御するストレージコントローラと
    を備え、
    　前記ストレージコントローラは、前記ストレージデバイスに対して、入出力対象のデータに関する入出力処理に伴って、前記デバイスコントローラが前記付加処理を実行するか否かの判断に利用可能な判断情報を送信し、
    　前記デバイスコントローラは、前記判断情報に基づいて、前記入出力対象のデータに対する前記付加処理の実行を制御する
    ストレージシステム。
  2. 　前記デバイスコントローラは、ホスト計算機が利用するユーザデータと、前記ユーザデータに基づいて算出される、前記ユーザデータを復元するための冗長コードとを格納し、
    　前記判断情報は、入出力対象のデータが前記ユーザデータであるか、前記冗長コードであるかを特定可能な情報を含み、
    　前記デバイスコントローラは、前記判断情報に基づいて、入出力対象のデータが前記ユーザデータであると特定した場合には、前記入出力対象のデータに対して前記付加処理を伴う入出力処理を実行し、前記入出力対象のデータが前記冗長コードであると特定した場合には、前記付加処理を伴わない入出力処理を実行する
    請求項１に記載のストレージシステム。
  3. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理である
    請求項１に記載のストレージシステム。
  4. 　前記デバイスコントローラは、前記ストレージシステムに対する入力対象のユーザデータに対応する冗長コードを生成する
    請求項２に記載のストレージシステム。
  5. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理であり、
    　前記ストレージコントローラ又は前記デバイスコントローラは、圧縮をする前の前記ユーザデータに対応する冗長コードを生成する
    請求項２に記載のストレージシステム。
  6. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理であり、
    　前記ストレージコントローラ又は前記デバイスコントローラは、前記ユーザデータに対して圧縮を行った後の圧縮ユーザデータに対応する冗長コードを生成する
    請求項２に記載のストレージシステム。
  7. 　前記ストレージコントローラ又は前記デバイスコントローラは、前記ユーザデータに対する冗長コードが、圧縮を行った後の圧縮ユーザデータに対応する冗長コードであるか、圧縮を行う前のユーザデータについての冗長コードであるかを示す生成契機情報を管理し、
    　前記ストレージコントローラ又は前記デバイスコントローラは、前記生成契機情報に基づいて、前記ユーザデータに対応する冗長コードの生成を制御する
    請求項２に記載のストレージシステム。
  8. 　前記ストレージコントローラが圧縮後の圧縮ユーザデータに対応する冗長コードを用いて、前記圧縮ユーザデータを復元する際に、
    　前記デバイスコントローラは、
    　前記圧縮ユーザデータの復元に利用する他の圧縮ユーザデータ又は冗長コードを伸張することなく前記ストレージコントローラに送信し、
    　前記ストレージコントローラは、
    　前記他の圧縮ユーザデータ及び前記冗長コードに基づいて、復元対象の前記圧縮ユーザデータを復元して前記ストレージデバイスに送信し、
    　前記デバイスコントローラは、
    　復元された前記圧縮ユーザデータを圧縮することなく格納する
    請求項６に記載のストレージシステム。
  9. 　前記記憶媒体が、フラッシュメモリである、
    請求項１に記載のストレージシステム。
  10. 　データを格納する記憶デバイスと、前記データに対して前記データの状態の変更を伴う付加処理を実行するデバイスコントローラと、を有するストレージデバイスと、
    　前記ストレージデバイスへのデータの入出力を制御するストレージコントローラと
    を備えるストレージシステムの記憶制御方法であって、
    　前記ストレージコントローラが、前記ストレージデバイスに対して、入出力対象のデータに関する入出力処理に伴って所定の付加処理を実行するか否かの判断に利用可能な判断情報を送信し、
    　前記デバイスコントローラが、前記判断情報に基づいて、前記入出力対象のデータに対する前記入出力処理に伴う前記付加処理の実行を制御する
    記憶制御方法。
  11. 　前記デバイスコントローラは、ホスト計算機が利用するユーザデータと、前記ユーザデータに基づいて算出される、前記ユーザデータを復元するための冗長コードとを格納し、
    　前記判断情報は、入出力対象のデータが前記ユーザデータであるか、前記冗長コードであるかを特定可能な情報を含み、
    　前記デバイスコントローラが、前記判断情報に基づいて、入出力対象のデータが前記ユーザデータであると特定した場合には、前記入出力対象のデータに対して前記付加処理を伴う入出力処理を実行し、前記入出力対象のデータが前記冗長コードであると特定した場合には、前記付加処理を伴わない入出力処理を実行する
    請求項１０に記載の記憶制御方法。
  12. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理である
    請求項１０に記載の記憶制御方法。
  13. 　前記デバイスコントローラが、前記ストレージシステムに対する入力対象のユーザデータに対応する冗長コードを生成する
    請求項１１に記載の記憶制御方法。
  14. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理であり、
    　前記ストレージコントローラ又は前記デバイスコントローラが、圧縮をする前の前記ユーザデータに対応する冗長コードを生成する
    請求項１１に記載の記憶制御方法。
  15. 　前記付加処理は、前記入出力対象のデータを圧縮又は伸張する処理であり、
    　前記ストレージコントローラ又は前記デバイスコントローラが、前記ユーザデータに対して圧縮を行った後の圧縮ユーザデータに対応する冗長コードを生成する
    請求項１１に記載の記憶制御方法。
PCT/JP2013/061485 2013-04-18 2013-04-18 ストレージシステム及び記憶制御方法 WO2014170984A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/241,784 US9122399B2 (en) 2013-04-18 2013-04-18 Storage system and storage control method
PCT/JP2013/061485 WO2014170984A1 (ja) 2013-04-18 2013-04-18 ストレージシステム及び記憶制御方法
US14/828,912 US9465561B2 (en) 2013-04-18 2015-08-18 Storage system and storage control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/061485 WO2014170984A1 (ja) 2013-04-18 2013-04-18 ストレージシステム及び記憶制御方法

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/241,784 A-371-Of-International US9122399B2 (en) 2013-04-18 2013-04-18 Storage system and storage control method
US14/828,912 Continuation US9465561B2 (en) 2013-04-18 2015-08-18 Storage system and storage control method

Publications (1)

Publication Number Publication Date
WO2014170984A1 true WO2014170984A1 (ja) 2014-10-23

Family

ID=51729924

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/061485 WO2014170984A1 (ja) 2013-04-18 2013-04-18 ストレージシステム及び記憶制御方法

Country Status (2)

Country Link
US (2) US9122399B2 (ja)
WO (1) WO2014170984A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109313593A (zh) * 2016-09-16 2019-02-05 株式会社日立制作所 存储系统

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016017002A1 (ja) * 2014-07-31 2016-02-04 株式会社日立製作所 ストレージシステム
US9678665B2 (en) * 2015-03-06 2017-06-13 Western Digital Technologies, Inc. Methods and systems for memory page allocation
KR101676792B1 (ko) * 2015-06-01 2016-11-16 삼성전자주식회사 데이터를 효율적으로 임베디드 압축 하기 위한 방법, 장치 및 컴퓨터 판독 가능한 기록 매체
US10168939B2 (en) * 2015-11-24 2019-01-01 International Business Machines Corporation Reading records from a tape medium
CN106919617B (zh) * 2015-12-25 2020-09-04 北京奇虎科技有限公司 一种压缩存储方法和装置
US10459638B2 (en) * 2016-02-22 2019-10-29 Hitachi Ltd. Computer system that generates group information and redundant code based on user data and changes the group information and redundant code based on transmission data, control method for computer system, and recording medium
US9936019B2 (en) 2016-03-16 2018-04-03 Google Llc Efficient live-migration of remotely accessed data
US10037245B2 (en) 2016-03-29 2018-07-31 International Business Machines Corporation Raid system performance enhancement using compressed data and byte addressable storage devices
US10437667B2 (en) * 2016-03-29 2019-10-08 International Business Machines Corporation Raid system performance enhancement using compressed data
KR20180040767A (ko) * 2016-10-12 2018-04-23 삼성전자주식회사 Raid 방식으로 데이터를 저장하는 스토리지 장치
CN108733309B (zh) * 2017-04-17 2021-06-11 伊姆西Ip控股有限责任公司 存储管理方法、设备和计算机可读介质
TWI656442B (zh) * 2017-11-30 2019-04-11 慧榮科技股份有限公司 用來於一記憶裝置中進行存取控制之方法以及記憶裝置及其控制器
US10592173B2 (en) 2018-01-10 2020-03-17 International Business Machines Corporation Increasing storage efficiency of a data protection technique

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008108039A (ja) * 2006-10-25 2008-05-08 Hitachi Ltd 暗号化機能を備えたストレージサブシステム
JP2009070361A (ja) * 2007-09-11 2009-04-02 Hitachi Ltd コンピュータストレージシステムにおいてデータ圧縮並びに整合性を管理する方法および装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6378038B1 (en) * 1999-03-31 2002-04-23 International Business Machines Corporation Method and system for caching data using raid level selection
US7133228B2 (en) * 2003-10-10 2006-11-07 Seagate Technology Llc Using data compression to achieve lower linear bit densities on a storage medium
JP4288486B2 (ja) * 2003-11-17 2009-07-01 日本電気株式会社 ディスクアレイ装置，ｒａｉｄ用パリティデータ生成回路およびガロア体乗算回路
US7793167B2 (en) * 2007-08-23 2010-09-07 International Business Machines Corporation Detection and correction of dropped write errors in a data storage system
JP5404804B2 (ja) 2009-05-25 2014-02-05 株式会社日立製作所 ストレージサブシステム
US8533550B2 (en) 2010-06-29 2013-09-10 Intel Corporation Method and system to improve the performance and/or reliability of a solid-state drive

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008108039A (ja) * 2006-10-25 2008-05-08 Hitachi Ltd 暗号化機能を備えたストレージサブシステム
JP2009070361A (ja) * 2007-09-11 2009-04-02 Hitachi Ltd コンピュータストレージシステムにおいてデータ圧縮並びに整合性を管理する方法および装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109313593A (zh) * 2016-09-16 2019-02-05 株式会社日立制作所 存储系统
CN109313593B (zh) * 2016-09-16 2022-03-01 株式会社日立制作所 存储系统

Also Published As

Publication number Publication date
US9122399B2 (en) 2015-09-01
US20150355864A1 (en) 2015-12-10
US20140317340A1 (en) 2014-10-23
US9465561B2 (en) 2016-10-11

Similar Documents

Publication Publication Date Title
WO2014170984A1 (ja) ストレージシステム及び記憶制御方法
JP6328335B2 (ja) ストレージ装置及びその制御方法
JP6134857B2 (ja) 記憶デバイス、記憶デバイスを有する装置、及び記憶制御方法
US9910748B2 (en) Rebuilding process for storage array
JP5722500B2 (ja) リモートコピーシステム、及びリモートコピー制御方法
JP5937697B2 (ja) ストレージシステム
JP6007332B2 (ja) ストレージシステム及びデータライト方法
JP6429963B2 (ja) ストレージ装置及びストレージ装置の制御方法
JP2008204041A (ja) ストレージ装置及びデータ配置制御方法
JP5826949B2 (ja) ストレージ装置及びデータ管理方法
WO2015029230A1 (ja) 記憶装置及びデータ制御方法
JP6666540B2 (ja) ストレージ制御装置、及びプログラム
JP7472341B2 (ja) ストレージシステム及びストレージシステムの制御方法
JP2015114784A (ja) バックアップ制御装置及びバックアップ制御方法、ディスクアレイ装置、並びにコンピュータ・プログラム
US20130159656A1 (en) Controller, computer-readable recording medium, and apparatus
JP5829753B2 (ja) ストレージシステムおよび記憶制御方法
JP6163588B2 (ja) ストレージシステム
WO2015118680A1 (ja) ストレージ装置
WO2017212515A1 (ja) ストレージシステム、計算機、およびストレージ制御方法
US20160357479A1 (en) Storage control apparatus
WO2017061022A1 (ja) データを重複排除するシステム
US11221790B2 (en) Storage system
JP2019053485A (ja) ストレージ制御装置、ストレージ制御システム、ストレージ制御方法、及び、ストレージ制御プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 14241784

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13882440

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13882440

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP