WO2015162681A1 - ストレージシステムおよび記憶デバイスの制御方法 - Google Patents

ストレージシステムおよび記憶デバイスの制御方法 Download PDF

Info

Publication number
WO2015162681A1
WO2015162681A1 PCT/JP2014/061238 JP2014061238W WO2015162681A1 WO 2015162681 A1 WO2015162681 A1 WO 2015162681A1 JP 2014061238 W JP2014061238 W JP 2014061238W WO 2015162681 A1 WO2015162681 A1 WO 2015162681A1
Authority
WO
WIPO (PCT)
Prior art keywords
size
data
storage
controller
read
Prior art date
Application number
PCT/JP2014/061238
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 US15/128,089 priority Critical patent/US10222988B2/en
Priority to PCT/JP2014/061238 priority patent/WO2015162681A1/ja
Publication of WO2015162681A1 publication Critical patent/WO2015162681A1/ja

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/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
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/04—Addressing variable-length words or parts of words
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • 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
    • 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/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • 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/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to 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/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/0661—Format or protocol conversion 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/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • 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/0685—Hybrid storage combining heterogeneous device types, e.g. hierarchical storage, hybrid 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/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
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/26—Using a specific storage system architecture
    • G06F2212/261—Storage comprising a plurality of storage devices
    • G06F2212/262—Storage comprising a plurality of storage devices configured as RAID
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/31—Providing disk cache in a specific location of a storage system
    • G06F2212/312—In storage controller
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/40—Specific encoding of data in memory or cache
    • G06F2212/401—Compressed data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory

Definitions

  • the present invention relates to a storage system and a storage device control method.
  • a data compression technique is known as a technique for reducing the amount of data.
  • a capacity virtualization technique is known as a technique for reducing the capacity used for storing data.
  • the capacity virtualization technique is a technique for showing a virtual capacity larger than the physical storage capacity available to the storage system to a host device or the like outside the storage system.
  • Patent Document 1 a storage destination area in a pool is dynamically allocated to data after compression using a data compression technique and a capacity virtualization technique according to the data size after compression. Thereby, in patent document 1, the use efficiency of storage capacity can be improved. Furthermore, in Patent Document 1, since the user does not need to prepare a volume having a size that matches the compressed data size, usability is improved.
  • the unit of compression / decompression is a unit for the storage controller to give a compression / decompression instruction to the compression / decompression circuit, or a unit for associating the logical address accessed by the host with the physical address of the final storage medium. Therefore, if the compression / decompression unit is reduced, the number of times of instructing the compression / decompression circuit to perform compression / decompression and the number of times of associating the physical address of the final storage medium are increased when reading large data. Will increase. Furthermore, since the number of times data is read from the final storage medium such as a hard disk increases, the load on the final storage medium also increases.
  • the present invention has been made in view of the above problems, and an object of the present invention is to provide a storage system and a storage device control method capable of improving efficiency. Another object of the present invention is to provide a storage system and a storage device control method capable of satisfying both the performance when reading and writing data with a small size and the performance when reading data with a large size. .
  • a storage system having at least one storage device, a controller that controls the storage device, and a cache, the first size being the maximum size of data that can be read from the storage device at one time And a second size equal to or smaller than the first size, and a third size that is a divisor of the first size and is set to a value smaller than the first size and the second size, and the controller
  • the controller When a virtual volume composed of a plurality of virtual pages is provided and a write request to the virtual volume is received, a pool area composed of a plurality of stripes having the first size is allocated by the virtual page size, and the write request
  • the data is Compressed data is generated in units of units, the storage area of the storage device is selected in units of the second size, and the compressed data is transferred to the selected second size storage area at the beginning of the free area in the storage area of the second size. Write in order starting from the address.
  • the compressed data is written in the second size storage area in order from the start address of the storage area of the second size without any gap between the second size.
  • the location of the compressed data can be grasped only by managing the offset in the storage area. Therefore, management efficiency can be improved.
  • FIG. 1 shows the configuration of a storage system.
  • FIG. 2 is an explanatory diagram showing the relationship among virtual volumes, pools, virtual pages, real pages, stripes, sub-stripes, physical chunks, and the like.
  • FIG. 3 is a block diagram showing the storage contents of the cache memory.
  • FIG. 4 is a block diagram showing storage contents of a hard disk drive as an example of a storage device.
  • FIG. 5 shows a configuration example of a table for managing virtual volumes.
  • FIG. 6 shows a configuration example of a table for managing the storage pool.
  • FIG. 7 shows a configuration example of a table for managing RAID (Redundant Arrays of Inexpensive Disks) groups.
  • FIG. 8 shows a configuration example of a table for managing a hard disk drive as a PDEV (Physical Device).
  • FIG. 9 shows a configuration example of a table for managing virtual pages.
  • FIG. 10 shows a configuration example of a table for managing real pages.
  • FIG. 11 shows a configuration example of a table for managing free real pages (free real pages).
  • FIG. 12 shows a configuration example of a table for managing stripes.
  • FIG. 13 shows a configuration example of a table for managing physical chunks.
  • FIG. 14 shows a configuration example of a table for managing free physical chunks (free physical chunks).
  • FIG. 15 shows a flowchart of the write process.
  • FIG. 16 shows a flowchart of the destage processing.
  • FIG. 17 shows a flowchart of a process for destaged compressed data.
  • FIG. 18 shows a flowchart of processing for allocating physical chunks.
  • FIG. 19 shows a flowchart of the read process.
  • FIG. 20 shows a flowchart of a process for staging data to the cache.
  • FIG. 21 shows a flowchart of a process for staging the compressed data to the cache.
  • management table various types of information may be described using an expression such as “management table”, but the various types of information may be expressed using a data structure other than a table. Further, the “management table” can be referred to as “management information” to indicate that it does not depend on the data structure.
  • a hard disk drive will be described as an example of “storage device”, but at least a part of this embodiment can also be applied to a flash memory device.
  • the program is executed by a processor, for example, a CPU (Central Processing Unit), and performs a predetermined process.
  • a processor for example, a CPU (Central Processing Unit)
  • the subject of processing may be a processor because the storage resource (for example, memory) and the communication interface device (for example, communication port) are used as appropriate.
  • the processor may have dedicated hardware in addition to the CPU.
  • the computer program may be installed on each computer from a program source.
  • the program source may be provided by, for example, a program distribution host computer or a storage medium.
  • each element can be identified by a number or the like, but other types of identification information such as a name may be used as long as it is identifiable information.
  • identification information such as a name
  • the same reference numerals are given to the same parts, but the present invention is not limited to the present embodiment, and any application examples that meet the idea of the present invention are technical. Included in the range. Further, unless specifically limited, each component may be plural or singular.
  • the logical address area is divided by stripes constituting a RAID group.
  • the stripe size corresponds to the “first size”.
  • the physical storage area of the hard disk is divided and managed in units of chunks (physical chunks) smaller than stripes.
  • the physical chunk size corresponds to “second size”.
  • the storage system controller compresses data for the stripe and allocates as many chunks as necessary according to the data size after compression.
  • the controller compresses and decompresses data in units of sub-stripes smaller than the stripe size in order to respond to read requests and write requests for data having a size less than the stripe size.
  • the sub stripe size corresponds to the “third size”.
  • the stripe is divided in units of sub-stripes, and a sub-strip size area is a unit for compression and expansion.
  • FIG. 1 is a block diagram showing the overall configuration of the storage system 1.
  • the storage system 1 includes, for example, a controller 10 and a drive enclosure 20.
  • the storage system 1 transmits / receives data blocks to / from the host computer 2 via the communication network N.
  • the host computer 2 may be abbreviated as “host 2”.
  • the controller 10 includes, for example, a host I / F (Interface) 11, a CPU (Central Processing Unit) 12, a cache memory 13 (hereinafter sometimes abbreviated as CM), and a drive I / F 14. Any of these elements 11 to 14 may be two or more. These elements 11 to 14 are connected by an internal bus 15 capable of bidirectional data transmission.
  • the communication network N can be configured by, for example, a SAN (Storage Area Network).
  • the SAN can be configured by, for example, Fiber Channel, Ethernet (registered trademark), and / or Infiniband.
  • the communication network N may be a LAN, the Internet network, a leased line network, or a combination thereof.
  • the host I / F 11 is an I / F for connecting the communication network N and the controller 10.
  • the host I / F 11 can also be referred to as, for example, “upper communication unit”, “first communication unit”, “upper device interface unit”, and the like.
  • the host I / F 11 is interposed between the communication network N and the internal bus 15 and controls transmission / reception of data blocks.
  • the host I / F 11 receives an I / O (Input / Output) request from the host 2.
  • Information indicating the I / O destination (access destination information) and an I / O command are associated with the I / O request.
  • the I / O destination information includes information for identifying the I / O destination logical volume and address information for specifying the I / O destination area in the logical volume.
  • identification information of the logical volume of the I / O destination for example, there is LUN (Logical Unit Unit Number).
  • As address information for specifying an I / O destination area in a logical volume for example, there is LBA (Logical Block Address).
  • the I / O command is a write command or a read command.
  • the CPU 12 implements various functions F1, F2, and F3 by executing predetermined computer programs (hereinafter referred to as “programs”).
  • the program may be stored in a non-volatile memory area (not shown) in the controller 10, or may be stored in an HDD (Hard Disk Disk Drive) 21 or the like outside the controller.
  • the storage configuration management unit F1 is a function that manages various storage configurations such as a RAID group configuration, a pool configuration, and a virtual volume configuration.
  • the command control unit F2 has a function of processing a read command and a write command received from the host 2 and returning the result to the host 2.
  • the compression / decompression unit F3 has a function of compressing data according to a predetermined algorithm and decompressing the compressed data. In the following description, it may be referred to as a compression unit F3.
  • the compression / decompression unit F3 includes a lossless data compression algorithm such as LZ77.
  • the CPU 12 When the CPU 12 receives the I / O command from the host 2, the CPU 12 extracts I / O destination information associated with the I / O command, and specifies the I / O destination area from the I / O destination information. The CPU 12 specifies one or more HDDs 21 that respectively provide one or more logical pages corresponding to the specified I / O destination area. Then, the CPU 12 transmits an I / O command associated with the logical page address to each identified HDD 21. The I / O command sent to each HDD 21 may be associated with identification information (for example, drive number) for specifying the destination HDD 21 of the I / O command in addition to the logical page address.
  • identification information for example, drive number
  • the CM 13 temporarily holds data blocks.
  • the data block may be abbreviated as data.
  • the CM 13 may be configured by a nonvolatile memory.
  • the nonvolatile memory may be a flash memory or a magnetic disk memory.
  • the CM 13 may be configured to include a backup power source in a volatile memory.
  • the volatile memory may be DRAM (Dynamic Random Access Memory) or the like.
  • the backup power source may be a battery such as a lithium ion secondary battery.
  • the host I / F 11, CPU 12, and / or drive I / F 14 may input / output data blocks to / from the CM 13 via the internal bus 15.
  • the drive I / F 14 is an I / F for connecting the controller 10 and the drive enclosure 20.
  • the drive I / F 14 can also be called, for example, a “lower communication unit”, “second communication unit”, “storage device interface unit”, and the like.
  • the drive I / F 14 is interposed between the internal bus 15 and the HDD 21 and controls transmission / reception of data blocks.
  • the drive I / F 14 may be an I / F corresponding to SAS or Fiber Channel.
  • the drive I / F 14 may transmit the data block received from the HDD 21 to the CM 13.
  • the drive enclosure 20 has a plurality of storage devices.
  • the HDD 21 (# 0, # 1, # 2, # 3) is shown as a storage device.
  • the HDDs 21 (# 0, # 1, # 2, and # 3) are not distinguished, they are simply referred to as “HDD 21”.
  • the drive enclosure 20 may have any number of HDDs 21.
  • another non-volatile memory such as an SSD (Solid State Drive) may be connected to the drive enclosure 20.
  • the drive I / F 14 and the HDD 21 may be connected by SAS (Serial Attached SCSI), FC (Fibre Channel), or SATA (Serial AT Attachment).
  • the HDD 21 of the drive enclosure 20 receives an I / O command (write command or read command) in which the address of the logical page provided by the HDD 21 is specified from the controller 10, the HDD 21 executes processing corresponding to the I / O command. .
  • I / O command write command or read command
  • the HDD 21 may be referred to as a Physical Device (PDEV).
  • PDEV Physical Device
  • data exceeding the physical capacity of the PDEV can be stored by data compression. That is, there are two types of PDEVs that provide physical capacity as they are and virtual PDEVs that can store data that exceeds physical capacity by data compression.
  • a PDEV that provides a physical capacity as it is is called a real PDEV 105
  • a virtual PDEV that can store data larger than the physical capacity is called a virtual PDEV 104.
  • the storage system 1 may have two or more drive enclosures 20.
  • the drive I / F 14 may have a plurality of ports, and one drive enclosure 20 may be connected to one port of the drive I / F 14.
  • two or more drive enclosures 20 and one drive I / F 14 may be connected via a predetermined switch device (not shown).
  • two or more drive enclosures 20 may be cascaded.
  • FIG. 2 shows the relationship among the virtual volume 101, the storage pool 102, the RAID group 103, the virtual PDEV 104, the real PDEV 105, the virtual page 110, the real page 111, the stripe 120, the sub-stripe 121, and the physical chunk 122.
  • the controller 10 provides a capacity virtualization function.
  • the RAID group is also called a parity group.
  • the virtual volume 101 provided to the host 2 is divided into a plurality of virtual pages 110.
  • a storage area composed of one or more RAID groups 103 is divided into a plurality of real pages 111.
  • a set of a plurality of real pages 111 is called a storage pool 102.
  • capacity virtualization the storage capacity of the virtual volume 101 can appear larger than the actual capacity. For this reason, the number of virtual pages 110 is generally larger than the number of real pages 111.
  • the controller 10 allocates a free real page 111 from the storage pool 102 to the virtual page 110 belonging to the write destination address requested to be written from the host 2, and writes the write data to the real page 111. Details of the write process will be described later.
  • the real page 111 is a set of storage areas called stripes 120.
  • the stripe 120 refers to a minimum continuous area allocated to each PDEV when configuring a RAID.
  • the stripe size corresponds to the “first size” and is the maximum size of data that can be read from the PDEV 105 (HDD 21) at a time.
  • the real PDEV 105 corresponds to the HDD 21 and manages the physical capacity.
  • the actual PDEV 105 stores the compressed data.
  • the compressed data may be referred to as compressed data.
  • the physical storage area of the real PDEV 105 is divided and managed in units called physical chunks 122.
  • the size of the physical chunk 122 may be referred to as a chunk size or a physical chunk size.
  • Chunk size corresponds to “second size” and has the same or smaller size than the stripe. For example, it can be determined from the stripe size and a predetermined data compression rate set in advance.
  • the chunk size may be set in advance, or may be changed by the storage administrator through an appropriate management interface. Further, it may be variable length according to the compressed data length.
  • a plurality of chunk sizes such as 64 KB, 128 KB, 256 KB, and 512 KB may be prepared, and a physical chunk of an appropriate size may be allocated depending on the result of compressing the stripe 512 KB.
  • a plurality of chunk sizes such as 64 KB, 128 KB, 256 KB, and 512 KB may be prepared, and a physical chunk of an appropriate size may be allocated depending on the result of compressing the stripe 512 KB.
  • the virtual PDEV 104 is a storage space for storing data exceeding the physical capacity by compression.
  • the virtual PDEV 104 manages uncompressed data (uncompressed data).
  • the storage area of the virtual PDEV 104 is divided and managed for each stripe 120.
  • Each stripe 120 is divided and managed for each storage area called a finer sub-stripe 121.
  • the size of the sub-stripe 121 corresponds to the “third size”, which is a fraction of the stripe size and set to a value smaller than both the stripe size and the chunk size.
  • the size of the sub stripe 121 may be set in consideration of a typical I / O size of the host 2 that uses the virtual volume 101. For example, when a database (not shown) mounted on the host 2 accesses the virtual volume 101 in units of 4 KB, the size of the sub stripe 121 can be set to 4 KB. “4” is a reduction of 512 KB, which is the stripe size, and is smaller than both the stripe size (512 KB) and the chunk size (64 KB).
  • the sub stripe size “4” can divide the chunk size and the stripe size.
  • the sub stripe size may be defined as a value selected based on the I / O size of the host 2 that uses the virtual volume 101 among the common divisors of the stripe size and the chunk size. *
  • the size of the sub stripe 121 may be set to 2 KB.
  • the above stripe size, sub stripe size, and chunk size are examples for understanding the present embodiment, and are not intended to limit the scope of the present invention to those values.
  • the capacity of the virtual PDEV 104 is defined to be larger than the capacity of the actual PDEV 105. As many physical chunks 122 as necessary are allocated to a certain stripe 120 according to the data size after compression.
  • Allocation of the physical chunk 122 to the stripe 120 of the virtual PDEV 104 is managed by a physical chunk mapping table 2410 in the stripe management table 24 as described later.
  • the physical chunk size is smaller than the stripe size, and a plurality of physical chunks 122 can be allocated to one stripe 120. Since the storage system 1 can consume only the physical capacity corresponding to the data size after compression by the capacity virtualization function described above, the capacity efficiency is improved.
  • the write position of the compressed data in the physical chunk 122 is managed by the sub stripe mapping table 2420 of the stripe management table 24 as described later.
  • the data of the sub stripe 121 is compressed, it is stored in the physical chunk 122 in a so-called left-justified manner.
  • To store the data in the left-justified format means to write the compressed data in the physical chunk 122 in the order in which the host 102 writes the data in the virtual volume 101 without leaving a gap.
  • the correspondence relationship between the virtual volume 101 and the storage pool 102 can be known from a virtual volume number 311 and a pool number 314 in the virtual volume management table 31 described later.
  • the correspondence between the storage pool 102 and the RAID group 103 can be known from the storage pool number 321 and the RAID group list 322 of the storage pool management table 32 described later.
  • the correspondence between the virtual PDEV 104 that stores uncompressed data and the real PDEV 105 that stores compressed data can be known from a virtual PDEV number 341 and a real PDEV number 342 in the PDEV management table 34 described later.
  • FIG. 3 shows a logical configuration of the storage area of the CM 13.
  • the CM 13 has, for example, a virtual volume management table 31, a storage pool management table 32, a RAID group management table 33, a PDEV management table 34, a virtual page management table 35, and a real page.
  • a management table 36, a free real page management table 37, a cache memory area 38, and a buffer area 39 are provided. Details of each table will be described later with reference to the drawings.
  • the cache memory area 38 is used for temporarily storing data written from the host 2 and data read from the HDD 21 (PDEV). For example, when the controller 10 receives a write command and a data block to be written (hereinafter “write data”) from the host 2, the controller 10 stores the write data block in the cache memory area 38 and returns a completion response to the host 2. .
  • write data a data block to be written
  • the controller 10 returns a completion response to the host 2 before storing the write data in the HDD 21.
  • the write performance (write speed) is higher in the cache memory area 38 than the HDD 21 (because it is faster), so by returning a completion response to the host 2 when write data is written to the cache memory area 38, The response performance with respect to the host 2 of the storage system 1 can be improved.
  • the buffer area 39 is used as a temporary storage area when compressing compressed data or compressing non-compressed data.
  • FIG. 4 is a block diagram showing a logical configuration of the storage area of the HDD 21.
  • the HDD 21 includes, for example, a metadata area (control information area) 22 and a data area 23 as a logical configuration of the storage area.
  • the data area 23 stores the data block written from the controller 10.
  • Information for controlling the data area 23 is stored in the control information area 22.
  • the metadata area 22 is an area for storing control information, and includes, for example, a stripe management table 24, a physical chunk management table 25, and a free physical chunk management table 26. Details of the tables 24 to 26 will be described later. All or a part of the tables 24 to 26 may be cached in the CM 13 so that the controller 10 can access the information in the tables at high speed.
  • the tables 24 to 26 may be stored in a memory (for example, the CM 13) in the controller 10 instead of the HDD 21.
  • FIG. 5 shows a data configuration example of the table 31 for managing the virtual volume.
  • the virtual volume management table 31 has information regarding the virtual volume 101.
  • the virtual volume management table 31 includes, for example, a volume number 311, a volume capacity 312, an allocated capacity 313, a pool number 314, and a volume attribute 315 as items.
  • “number” is shown as #.
  • the volume number 311 is an identifier (ID) for identifying each virtual volume 101 provided by the controller 10.
  • the controller 10 can create a plurality of virtual volumes 101 and have one or a plurality of hosts 2 use them.
  • the volume capacity 312 is the volume size of the virtual volume 101.
  • the allocated capacity 313 is the capacity allocated to the virtual volume 101, that is, the total size of the real pages 111 allocated to the virtual volume 101.
  • the pool number 314 is an ID for identifying the storage pool 102 associated with the virtual volume 101.
  • the pool number 314 corresponds to the storage pool number 321 shown in FIG.
  • the real page 111 assigned to the virtual volume 101 is selected from the real pages 111 included in each RAID group 103 included in the pool number 314.
  • the volume attribute 315 stores information indicating performance characteristics and capacity characteristics of the virtual volume 101.
  • the volume attribute 315 can store information indicating whether the entire virtual volume 101 is compressed.
  • the volume attribute 315 may store information indicating the data processing status of the virtual volume 101.
  • the information indicating the data processing state can include information indicating that data is being compressed or data is being decompressed.
  • the storage administrator can appropriately change the value of the volume attribute 315 by using an appropriate management interface. For example, the storage administrator can switch the state of the virtual volume 101 between “compressed” and “uncompressed”. When the virtual volume 101 is switched from “uncompressed” to “compressed”, processing for compressing and re-storing all data stored in the virtual volume 101 is executed. Conversely, when the virtual volume 101 is switched from “compressed” to “uncompressed”, a process of decompressing and re-storing the entire data stored in the virtual volume 101 is executed.
  • the volume attribute of the virtual volume 101 is set to “compressed”, every time data is read or written to the virtual volume 101, a process of expanding or compressing the data occurs. Therefore, the throughput performance of the virtual volume 101 decreases.
  • FIG. 6 shows a data configuration example of the table 32 for managing the storage pool 102.
  • the storage pool management table 32 has information regarding the storage pool 102.
  • the storage pool management table 32 includes, as items, a storage pool number 321, a RAID group list 322, a pool attribute 323, and a number of free virtual pages 324.
  • the storage pool number 321 is an ID for identifying each storage pool 102 under the management of the controller 10.
  • the RAID group list 322 holds the numbers of one or more RAID groups 103 that make up the storage pool 102.
  • the pool attribute 323 stores information representing the performance characteristics and capacity characteristics of the storage pool 102. For example, information indicating the types of physical storage devices constituting the RAID group 103 associated with the storage pool 102 may be stored. As a type of the storage device, for example, there is an HDD 21 or an SSD (Solid State Drive).
  • the pool attribute 323 may store information indicating whether the entire storage pool 102 is compressed. When the entire storage pool 102 is compressed, the volume attributes of each virtual volume 101 associated with the storage pool 102 are all “compressed”. The storage administrator can switch the attribute of the storage pool 102 between “compressed” and “uncompressed” by an appropriate management interface.
  • the storage administrator sets the attributes of the storage pool 102 based on an index indicating whether or not performance degradation can be tolerated.
  • FIG. 7 shows a data configuration example of the table 33 that manages the RAID group 103.
  • the RAID group management table 33 has information regarding the RAID group 103.
  • the RAID group management table 33 has RAID group number 331, RAID level 332, and PDEV number 333 as items.
  • the RAID group number 331 is an ID for identifying the RAID group 103 managed by the controller 10.
  • the RAID level 332 is information representing the RAID level of the RAID group 103.
  • the RAID level “10” indicates that the configuration is RAID (1 + 0).
  • RAID level “5” indicates a RAID 5 configuration.
  • the PDEV number 333 stores the identifier (ID) of the virtual PDEV 104 that constitutes the RAID group 103.
  • the PDEV number 333 stores a plurality of PDEV numbers.
  • the PDEV number stored in the PDEV number 333 corresponds to the virtual PDEV number 341 in the PDEV management table 34.
  • FIG. 8 shows a data configuration example of the table 34 that manages the virtual PDEV 104 and the real PDEV 105.
  • the PDEV management table 34 manages the correspondence between the virtual PDEV 104 and the real PDEV number 105.
  • the PDEV management table 34 includes, as items, a virtual PDEV number 341, a real PDEV number 342, a physical capacity 343 number, a logical use capacity 344, and a physical use capacity 345.
  • the virtual PDEV number 341 is an ID for identifying each virtual PDEV 104 under the control of the controller 10.
  • the real PDEV number 342 is an ID for identifying each real PDEV 105 under the control of the controller 10.
  • the virtual PDEV number and the actual PDEV number match, but may be different.
  • the physical capacity 343 represents the maximum size of data that can be stored in the HDD 21 corresponding to the actual PDEV 105.
  • the logical usage amount 344 represents a data amount when the compressed data stored in the actual PDEV 105 is converted into non-compressed data.
  • the physical usage amount 345 represents the data size actually stored in the real PDEV 105.
  • the physical usage amount 345 corresponds to the data size after compression.
  • FIG. 9 shows a data configuration example of the table 35 for managing the virtual page 110.
  • the virtual page management table 35 indicates, for example, the correspondence relationship between the virtual volume 101, the virtual page 110, and the real page 111.
  • the virtual page management table 35 includes, as items, a virtual volume number 351, a real page pointer 352, a page attribute 353, and statistical information 354.
  • the virtual page management table 35 corresponds to each of the areas obtained by dividing the virtual volume 101 in units of pages. Therefore, there are as many virtual page management tables 35 as the number of virtual pages 110 constituting the virtual volume 101.
  • the virtual volume number 351 is an ID for identifying the virtual volume 101.
  • the real page pointer 352 is a pointer for indicating a correspondence relationship with the real page management table 36. When Null is entered, it indicates that a real page is not allocated.
  • the page attribute 353 represents the attribute of the virtual page 110.
  • the page attributes include “compressed” indicating that the virtual page 110 is compressed, and “uncompressed” indicating that it is not compressed.
  • the storage administrator can change the value of the page attribute 353 by using an appropriate management interface.
  • it is complicated for an administrator to specify page attributes in units of virtual pages.
  • the storage administrator switches the volume attribute 315 of the virtual volume 101 from compression to non-compression, or from non-compression to compression, the page attributes 353 of all virtual pages 110 associated with the virtual volume 101 are also automatically set. Change it. In this way, a change in the attribute of the virtual volume 101 may be reflected in the attribute of the virtual page 110.
  • the page attributes 353 of all virtual pages 110 associated with the storage pool 102 are also automatically Can be changed. As described above, the change of the attribute of the storage pool 102 may be reflected on the virtual page 110.
  • the statistical information 354 stores information indicating the access load from the host 2 for the data of the virtual page 110.
  • information indicating the access load for example, IOPS (Input / Output ⁇ ⁇ ⁇ Per Second) can be used.
  • IOPS Input / Output ⁇ ⁇ ⁇ Per Second
  • the last accessed time (year, month, day, hour, minute, second) may be stored in the statistical information 354.
  • the controller 10 may determine whether to compress the virtual page 110 based on the statistical information 354. For example, it is determined that a virtual page 110 having an access load less than a predetermined value is a compression target, and a virtual page 110 is a compression target when a predetermined period (for example, one month) has elapsed since the last access. Criteria can be mentioned.
  • the storage administrator may be able to change the criterion for determining whether or not to compress the virtual page 110 by using an appropriate management interface.
  • the controller 10 can automatically switch the attribute of each virtual page 110 to compression or non-compression based on the statistical information 354 and the determination criteria. As a result, the capacity compression function can be appropriately used as long as the performance of the storage system 1 is not affected.
  • the storage administrator does not need to manually set the attributes of each virtual page 110 while referring to the statistical information 354, so that the efficiency of management work is increased and convenience is improved.
  • FIG. 10 shows a data configuration example of the table 36 that manages the real page 111.
  • the real page management table 36 has information regarding the real page 111.
  • the real page 111 indicates an area obtained by dividing the RAID group 103 in units of pages.
  • the real page management table 36 is provided for each real page 111.
  • the real page management table 36 includes a RAID group number 361, a real page head address 362, and a free page pointer 363 as items.
  • the RAID group number 361 is an ID of the RAID group 103 under the management of the controller 10.
  • the real page head address 362 indicates the head address of the real page 111. As described with reference to FIG. 2, the real page 111 is configured using the stripe 120 of each virtual PDEV 104 that configures the RAID group 103.
  • the free page pointer 363 is used to manage the real page 111 that is not allocated to the virtual volume 101.
  • the real page 111 that is not assigned to the virtual volume 101 may be hereinafter referred to as a free real page or a free real page.
  • a data structure for managing a free real page will be described with reference to FIG.
  • FIG. 11 shows a data configuration example of the table 37 for managing the free real pages.
  • the free real page management table 37 is a linked list for managing free real pages that are not allocated to the virtual volume 101.
  • the free real page management table 37 is managed by a free page management pointer 371.
  • the free page management pointer 371 points to the first real page management table 36 from the free real page group.
  • the empty page pointer 362 in the first real page management table 36 indicates the next real page management table 36 in the empty real page group.
  • the empty page pointer 362 of the last real page management table 36 points to the empty page management pointer 371, but it may be a NULL value.
  • the controller 10 When the controller 10 receives a write request for the virtual page 110 to which the real page 111 is not assigned from the host 2, the controller 10 is associated with the RAID group 103 from one of the RAID groups 103 associated with the virtual volume 101. A free real page is searched using the free page management pointer 371. The controller 10 assigns the found free real page to the virtual page 110 to be written. For example, the controller 10 can select the RAID group 103 having the largest number of free real pages from among the RAID groups 103 corresponding to the virtual volume 101.
  • FIG. 12 shows a data configuration example of the table 24 for managing the stripe 120.
  • the stripe management table 24 is a table for managing to which address in the storage area of the actual PDEV 105 the compressed data is stored.
  • the stripe management table 24 is stored in the HDD 21. Instead of this, some frequently used data in the stripe management table 24 may be stored in the memory 13 in the controller 10.
  • the stripe management table 24 includes a stripe physical address 2400, a tail physical chunk number 2401, a tail physical chunk pointer 2402, a valid data size (uncompressed) 2403, a valid data size (compressed) 2404, and a physical chunk mapping table 2410. And a sub-stripe mapping table 2420.
  • the stripe physical address 2400 is an address (or stripe number) indicating where in the storage area of the real PDEV 105 the stripe 120 corresponds.
  • the tail physical chunk number 2401 indicates a number that identifies the physical chunk 122 that lastly stores the write data for the stripe 120 identified by the stripe physical address 2400.
  • the tail physical chunk pointer 2402 indicates the tail address of the write data stored in the tail physical chunk.
  • the trailing physical chunk number 2401 and the trailing physical chunk pointer 2402 are managed in combination.
  • the controller 10 can immediately specify the location where the write data is to be stored.
  • Effective data size (uncompressed) 2403 indicates the total value of uncompressed data written to the stripe 120.
  • the effective data size (compression) 2404 indicates the total value of the compressed data written to the stripe 120.
  • the physical chunk mapping table 2410 is a table for managing the physical chunk 122 allocated to the stripe 120.
  • the physical chunk mapping table 2410 has, as its constituent elements, an intra-stripe physical chunk number 2411 and a physical chunk address 2412.
  • the intra-stripe physical chunk number 2411 is identification information that identifies the physical chunk 122 assigned to the stripe 120.
  • the physical chunk address 2412 indicates the head address of the physical chunk 122 assigned to the stripe 120. In the case of Null, it indicates that the physical chunk 122 is not allocated.
  • the sub stripe mapping table 2420 is a table for managing in which storage area of the HDD 21 (actual PDEV 105) the compressed data is stored for each sub stripe 121 obtained by dividing the stripe 120 at a fixed length. is there.
  • the sub stripe mapping table 2420 associates, for example, a sub stripe number 2421, a storage destination physical chunk number 2422, a physical chunk offset 2423, a compression valid flag 2424, and a post-compression data length 2425.
  • the sub stripe number 2421 is information (ID) for identifying each sub stripe 121.
  • the storage destination physical chunk number 2422 is identification information that identifies the physical chunk 122 that stores the compressed data stored in the sub-stripe 121.
  • the physical chunk offset 2423 indicates an offset value from the head address of the storage destination physical chunk 122 to the head address of the data written to the physical chunk 122.
  • the compression effective flag 2424 is information indicating whether or not the data stored in the physical chunk 122 is compressed. “ON” is set when compression is performed, and “OFF” is set when compression is not performed.
  • the post-compression data length 2425 indicates the size of the compressed data written in the physical chunk 122.
  • FIG. 13 shows a data configuration example of the table 25 that manages the physical chunk 122.
  • the physical chunk management table 25 has information regarding the physical chunk 122.
  • the physical chunk 122 is an area obtained by dividing the storage area of the real PDEV 105 by a fixed length.
  • the physical chunk management table 25 is provided for each physical chunk 122. In this embodiment, according to the data size after compressing the uncompressed data, as many physical chunks 122 as necessary to store the compressed data are allocated to the stripe 120.
  • the physical chunk management table 25 has a physical chunk head address 2500 and a free physical chunk pointer 2501 as its constituent elements.
  • the physical chunk head address 2500 is a pointer indicating which address in the storage area of the HDD 21 (real PDEV 105) the physical chunk 122 corresponds to.
  • the free physical chunk pointer 2501 is used to manage the physical chunk 122 that is not allocated to the virtual PDEV 104.
  • the physical chunk 122 that is not allocated to the virtual PDEV 104 may be referred to as an empty physical chunk or a free physical chunk.
  • a data structure for managing the free physical chunk will be described with reference to FIG.
  • FIG. 14 shows a data configuration example of the table 26 for managing the free physical chunk.
  • the free physical chunk management table 26 is a linked list for managing free physical chunks that are not assigned to the virtual PDEV 104.
  • the free physical chunk management table 26 is managed by a free physical chunk management pointer 2601.
  • the free physical chunk management pointer 2601 indicates the first physical chunk management table 25 in the free physical chunk management table.
  • a free physical chunk pointer 2501 in the first physical chunk management table 25 indicates the management table 25 of the next free physical chunk.
  • the free physical chunk pointer 2501 of the last physical chunk management table 25 indicates the free physical chunk management pointer 2601, but it may be a NULL value instead.
  • the physical chunk allocation method will be described later.
  • each HDD 21 There may be a plurality of free physical chunk management pointers 2601.
  • the physical chunk 122 connected to a certain free physical chunk management pointer 2601 is selected.
  • a plurality of secured physical chunks 122 may not be continuous on the HDD, but since their physical addresses are within a certain zone, it is possible to secure relatively nearby physical chunks.
  • a plurality of physical chunks 122 that are close to each other on the HDD 21 can be allocated to the stripe 120.
  • data stored in the stripe 120 is read (for example, sequential read)
  • data can be read from a plurality of consecutive physical chunks 122, so that the response time of the HDD 21 can be shortened.
  • FIG. 15 is a flowchart showing a write process when the controller 10 receives a write command from the host 2.
  • the controller 10 analyzes the write command and specifies the virtual page number to be written (step 5101).
  • the write command includes information such as the virtual volume number to be written, the LBA on the virtual volume, and the size of the write data.
  • the controller 10 can specify the virtual page number from the result of dividing the LBA by the virtual page size.
  • the controller 10 determines whether or not the real page 111 has been allocated to the write-target virtual page 110 based on whether the real page pointer 352 of the virtual page management table 35 is included (step 5102). If a real page has been assigned to the virtual page 110 to be written (step 5102: No), the process proceeds to step 5106 described later.
  • the controller 10 assigns a new real page 111 having the same size as the virtual page to the write-target virtual page 110 (step 5103). .
  • the controller 10 refers to the empty page management pointer 371 and identifies one unused real page 111.
  • the controller 10 associates the identified unused real page 111 with the virtual page management table 35 for the virtual page 110 to be written. As a result, the real page 111 can be newly allocated to the virtual page 110.
  • the controller 10 determines whether the volume attribute 315 of the write target virtual volume 101 or the pool attribute 323 of the storage pool 102 associated with the virtual volume 101 is compression (step 5104). If both the volume attribute 315 of the virtual volume 101 and the pool attribute 323 of the storage pool 102 are not compressed (step 5104: No), the process proceeds to step 5108. In step 5108, a certain free physical chunk management pointer 2601 is associated with a certain real page 111 so that the physical storage destination of the data of the real page 111 is a continuous area, and always the free physical chunk management pointer. A physical chunk 122 linked to 2601 is allocated. By storing data using successive physical chunks 122, the overhead for accessing the stripe management table 24 can be reduced during non-compression.
  • the physical storage destination of the data of the real page 111 is managed by the stripe management table 24 for each stripe 120 configuring the real page 111. Since the stripe management table 24 is stored on the HDD 21, it takes time for the controller 10 to access it. Furthermore, since a physical storage destination is assigned to each sub-stripe 121, when reading data across a plurality of sub-stripes 121, the addresses of the plurality of physical storage destinations must be specified, which increases the processing load on the controller 10.
  • a physical chunk 122 having a size corresponding to the actual page 111 is secured in a continuous area, and the start address is stored in the actual page start address 362 of the actual page management table 36.
  • the physical chunk 122 in a continuous area, for example, when the attribute of the virtual page 110 is set to compression (when the compression attribute is valid) and when the attribute of the virtual page 110 is set to non-compression ( Different free physical chunk management pointers 2601 may be used for the compression attribute when invalid.
  • the controller 10 When the controller 10 stores uncompressed data in the virtual page 110, the controller 10 uses the physical chunk 122 that constitutes the continuous area, and thus only refers to the real page management table 36 without referring to the stripe management table 24.
  • the physical storage destination can be specified. Thereby, the overhead of the controller 10 can be reduced.
  • the process proceeds to step 5106. *
  • step 5104 When either the volume attribute 315 of the virtual volume 101 or the pool attribute 323 of the storage pool 102 is set to compression (step 5104: Yes), the controller 10 changes the attribute 353 of the write target virtual page 110 to compression. (Step 5105). Thereafter, the process proceeds to step 5106.
  • the controller 10 transfers the write target data (write data formed from one or more data blocks) to the cache memory area 38 (step 5106).
  • the cache memory area 38 in the CM 13 may be referred to as a cache memory or a cache.
  • controller 10 notifies the host 2 that is the issuer of the write command via the host I / F 11 that the writing of the write data has been completed (step 5107).
  • FIG. 16 is a flowchart showing the destage processing.
  • the destaging process is a process of storing data that has not been written to the HDD 21 among the data stored in the cache 38 in a predetermined area of the HDD 21.
  • the destage processing can be performed asynchronously with the timing of processing the write request from the host 2 (step 5200).
  • the controller 10 determines whether the data stored in the real page 111 to be destaged is based on RAID 5 or RAID 6 (step 5201). The determination may be made by confirming the RAID level 332 of the RAID group # 361 in the real page management table 36 with the RAID group management table 33. When the destage target data is stored in RAID5 or RAID6, the controller 10 generates a parity for the destage target data (step 5202).
  • the controller 10 determines whether or not the attribute of the real page 111 to be destaged is compression based on the page attribute 353 of the virtual page management table 35 (step 5203).
  • the controller 10 compresses the data of the real page 111 and performs destage processing (step 5204). This process will be described later with reference to FIG.
  • the controller 10 When the compression attribute is not attached to the destage target real page 111 (step 5203: No), the controller 10 refers to the real page management table 36 and acquires the physical address storing the destage target data. Step 5205). As described above, when destaging to the real page 111 having no compression attribute, data is stored by overwriting the same physical address. By doing so, the physical area can be reused, so that the capacity efficiency of the physical area is improved. Then, the controller 10 transfers the destage target data from the cache 38 to the HDD 21 for writing (step 5206).
  • FIG. 17 shows a flowchart of the process of destaged compressed data. This process is the detail of step 5204 in FIG. This flowchart is executed for dirty data in the cache, and the maximum dirty size to be processed at one time is the stripe size.
  • the controller 10 secures a buffer area 39 for storing compressed data in the CM 13 (step 5301).
  • the controller 10 compresses the destage target data on the cache 38 in units of sub-stripe 121 using the compression / decompression unit F3 according to a predetermined algorithm, and stores the compressed data in the buffer 39 secured in step 5301 (step 5302). ).
  • the controller 10 determines whether or not the allocated physical chunk 122 exists for the stripe 120 having the destage target data based on whether or not the physical chunk address 2412 is managed (step 5303). If no physical chunk 122 is assigned to the stripe 120 to be destaged (step 5303: No), the process proceeds to step 5307 described later. When one or more physical chunks 122 are assigned to the target stripe 120 (step 5303: Yes), the process proceeds to step 5304.
  • the controller 10 determines whether there is enough free space in the physical chunk 122 assigned to the target stripe 120 to store the destage target data (step 5304). If there is no free space in the physical chunk 122 for storing the destage target data (step 5304: No), the process proceeds to step 5307. Note that since the compressed data is stored right-justified in the physical chunk 121, the physical chunk address 2412 to the end physical chunk pointer 2402 of the physical chunk 122 is a used area, and the physical chunk address 2402 to the physical chunk Up to the end of the chunk 122 is the free capacity in the physical chunk 122. If there is free space (step 5304: Yes), the process proceeds to step 5305.
  • the controller 10 writes the compressed data to the address pointed to by the end physical chunk pointer 2402 of the stripe management table 24 (step 5305).
  • step 5307 the controller 10 executes physical chunk allocation processing (step 5307). This process will be described later with reference to FIG. After newly allocating the physical chunk 122, the controller 10 writes the compressed data at the head of the allocated physical chunk 122 (step 5308). The head of the physical chunk 122 is obtained by referring to the physical chunk address 2412. Finally, the controller 10 updates the stripe management table 24 (step 5306).
  • FIG. 18 shows a flowchart of processing for allocating physical chunks. This process shows details of step 5307 in FIG.
  • the controller 10 determines whether or not the size of the destage target data is equal to the stripe size (step 5401).
  • the controller 10 secures a free physical chunk 122 by referring to the free physical chunk management table 26 and assigns it to the target stripe 120 ( Step 5407).
  • the controller 10 determines whether the number of physical chunks 122 assigned to the target stripe 120 is equal to or less than a predetermined threshold ThPC (step). 5402).
  • the predetermined threshold ThPC is, for example, the maximum number of physical chunks that can be assigned to one stripe 120, that is, the number of physical chunks when the stripe size matches the total size of physical chunks assigned to the stripe. When the maximum compression rate is 1/8, the threshold ThPC is 8.
  • the controller 10 refers to the free physical chunk management pointer 2601 to secure a free physical chunk (step 5403).
  • the controller 10 preferentially secures physical chunks that have already been allocated and physical chunks that are nearby on the HDD 21. Specifically, the physical chunk 122 connected to the same free physical chunk management pointer 2601 as the already allocated physical chunk is selected and secured.
  • the controller 10 updates the physical chunk management table 25 (step 5404) and ends this process.
  • step 5402 determines whether the number of physical chunk allocations exceeds the threshold ThPC (step 5402: No). If the number of physical chunk allocations exceeds the threshold ThPC (step 5402: No), the process proceeds to step 5405 described later.
  • old data remains in the physical chunk 122 in order to prioritize the use of the free area in the already allocated physical chunk. Since write data is written to the physical chunk 122 in a so-called left-justified manner, the old data to be overwritten remains in the physical chunk 122.
  • the controller 10 refers to the physical chunk mapping table 2410 and reads all data from the eight physical chunks 122 assigned to the target stripe 120.
  • the sub stripe mapping table 2420 only the data corresponding to each sub stripe is stored in the newly allocated physical chunk 122 in a left-justified manner.
  • an empty area is generated in the physical chunk 122.
  • step 5405 the controller 10 reads the data of all physical chunks 122 associated with the target stripe 120 into the buffer 39, and proceeds to step 5406.
  • step 5406 the controller 10 rearranges the data read to the buffer 39 in step 5405 in the order of the sub stripe number on the buffer 39.
  • the sub-stripe including the compressed data to be destaged is replaced with the new data compressed at step 5302 instead of the data read to the buffer 39 at step 5405.
  • step 5407 the controller 10 refers to the free physical chunk management pointer 2601, and as in step 5403, newly reserves the physical chunk 122 necessary for storing the compressed data from the closest possible area, and proceeds to step 5408. move on.
  • step 5408 the controller 10 registers the free physical chunk 122 in the free physical chunk management table 26. Finally, the controller 10 updates the physical chunk management table 25 (step 5404).
  • FIG. 19 shows a flowchart for processing the read command.
  • the controller 10 analyzes the read command received from the host 2 and identifies the read target LBA (step 5501).
  • the controller 10 determines whether the read target data is stored in the cache memory 38 (step 5502). When the read target data is stored in the cache memory 38 (Step 5502: Yes), the controller 10 transfers the read target data stored in the cache memory 38 to the host 2 via the host I / F 11 (Step S502). 5505).
  • the controller 10 secures a new cache slot for storing the read target data on the cache memory 38 (step 5503).
  • the controller 10 executes a staging process for the cache memory 38 (step 5504).
  • the staging process to the cache memory 38 is a process for transferring the read target data in the HDD 21 (real PDEV 105) to the cache memory 38 and storing it. This process will be described later with reference to FIG.
  • the controller 10 transfers the read target data on the cache memory 38 to the host 2 via the host I / F 11.
  • FIG. 20 shows a flowchart of the cache staging process. This process shows the details of step 5504 in FIG. In this process, the read target data is read from the HDD 21 and stored in the cache memory 38.
  • the controller 10 calculates the number of the virtual page 110 to be read based on the read target address extracted from the read command (step 5601).
  • the controller 10 can specify the virtual page number from the result of dividing the LBA by the virtual page size, for example.
  • the controller 10 acquires the real page pointer 352 in the virtual page management table 35 (step 5602).
  • the controller 10 determines whether the real page pointer 352 is not NULL (step 5603).
  • the process proceeds to step 5607.
  • the case where the real page pointer 352 is NULL is a case where the host 2 has never written data to the virtual page 110 and there is no data to be read. Therefore, the controller 10 stores 0 data in the cache memory 38 and ends this processing.
  • step 5603 determines whether or not the attribute of the virtual page 110 to be read is compressed (5604). The controller 10 determines Step 5604 by referring to the page attribute 353 included in the virtual page management table 35. If the decision result in the step 5604 is Yes, the process proceeds to a step 5605 to execute a compressed data staging process (step 5605). If the determination result of step 5604 is No, the process proceeds to step 5606.
  • step 5606 the controller 10 reads the read target data into the cache memory 38.
  • the controller 10 since the page attribute is not compression, the controller 10 does not refer to the stripe management table 24, but the physical address storing the target data from the real page start address 362 in the real page management table 36. Can be identified. And the controller 10 complete
  • FIG. 21 shows a flowchart of a process for staging the compressed data. This process shows details of step 5605 in FIG.
  • the controller 10 acquires the physical address storing the read target data by referring to the stripe management table 24 corresponding to the read target stripe (step 5701). The controller 10 determines whether to read data in units of stripes or in units of sub-stripes according to the data size requested by the host 2 (step 5702).
  • step 5702 the number of reads to the HDD 21 can be reduced by using either the reading method in the physical chunk size (first read mode) or the reading in the sub stripe size unit (second read mode). Judgment on the basis of. This is because the throughput performance at the time of data reading of the HDD 21 can be improved as the number of reads is reduced.
  • a value obtained by dividing the size that the host 2 requests to read by the size of the sub stripe 121 is the stripe. It is determined whether it is larger than the number of physical chunks 122 assigned to 120 (step 5702).
  • the number of physical chunks 122 assigned to the stripe 120 is equal to the number of reads to the HDD 21 when data is read in units of physical chunks.
  • the controller 10 can obtain the number of physical chunks allocated to the stripe 120 by referring to the physical chunk mapping table 2410 and counting the number of physical chunks in which the physical chunk address 2412 corresponding to the physical chunk in the stripe is not NULL. .
  • the controller 10 can read data from the HDD 21 in units of physical chunks.
  • “request size / sub-stripe size” is equal to the number of reads to the HDD 21 when data is read in units of sub-stripe. Therefore, the size of the number of reads to the HDD 21 can be determined by comparing a value obtained by dividing the size requested by the host 2 by the sub stripe size with the number of physical chunks 122 allocated to the stripe 120. it can.
  • step 5702 When the value of (request size / sub-stripe size) is larger than the number of allocated physical chunks (step 5702: Yes), the number of reads to the HDD 21 is smaller when the data is read in stripe units.
  • the controller 10 secures a buffer 39 having a size necessary for reading data corresponding to the stripe size (step 5703).
  • the controller 10 refers to the physical chunk mapping table 2410, and reads data (compressed data) of all physical chunks 122 associated with the stripe 120 into the buffer area 39 (step 5704).
  • the controller 10 decompresses the compressed data stored in the buffer 39 in the order of the sub stripe number, stores the read target data returned to the non-compressed state in the cache 38, and then ends this processing.
  • step 5702 when the value of (request size / sub-stripe size) is less than or equal to the number of allocated physical chunks (step 5702: No), the number of times of reading to the HDD 21 is smaller when data is read in units of sub-stripe.
  • the controller 10 secures a buffer 39 that is at least equal to the data size requested by the host 2 (step 5706).
  • the controller 10 reads the data of the read target sub stripe from the HDD 21 and stores it in the buffer 39 by referring to the sub stripe mapping table 2420 (step 5707).
  • the controller 10 decompresses the compressed data on the buffer 39 and stores it in the cache memory 38 (step 5708). Then, the controller 10 ends this process.
  • the controller 10 sets the offset value in the physical chunk to write the compressed data in the physical chunk size storage area by using the sub-stripe size as a compression / decompression unit.
  • the location of the compressed data can be grasped only by managing. Therefore, the physical storage destination of the compressed data can be managed efficiently.
  • the table size can be reduced, and the storage area of the CM 12 can be used efficiently.
  • the data when reading large data, the data is read in units of chunks and expanded in units of sub-stripes, and the data is rearranged in the order of logical addresses on the cache memory 38.
  • a sequential read request having a large size can be processed in units of chunks, so that the processing load on the controller 10 can be reduced and the number of accesses to the HDD 21 can be reduced to reduce the load on the HDD 21.
  • the throughput performance of the HDD 21 can be improved when the controller 10 sequentially reads the compressed data.
  • Example is an example for understanding and implementing this invention, and this invention is not limited to what is equipped with all the structures mentioned above.
  • a part of the configuration of the embodiment can be replaced with another configuration, a part of the configuration can be deleted, or a configuration and another configuration can be combined into one configuration.
  • each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • 1 storage device
  • 2 host computer
  • 10 controller
  • 101 virtual volume
  • 102 storage pool
  • 103 RAID group
  • 104 virtual PDEV
  • 105 real PDEV
  • 110 virtual page
  • 111 real page
  • 120 Stripe
  • 121 Sub-stripe
  • 122 Physical chunk

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　本発明は、効率を高めることができるようにしたストレージシステムを提供する。ストレージシステムは、記憶デバイス１０５から一回で読み出せるデータの最大サイズである第１サイズ１２０と、第１サイズ以下の第２サイズ１２２と、第１サイズの約数であって、第１サイズおよび第２サイズよりも小さい値に設定される第３サイズ１２１とを予め定義する。コントローラは、複数の仮想ページで構成される仮想ボリュームを提供し、仮想ボリュームへのライト要求を受けると、第１のサイズを有する複数のストライプで構成されるプール領域を仮想ページサイズで割り当て、ライト要求のデータをキャッシュに格納し、キャッシュに格納されるデータを記憶デバイスに書き込む場合に、データを第３サイズ単位で圧縮して圧縮データを生成し、記憶デバイスの有する記憶領域を第２サイズ単位で選択し、選択した第２サイズの記憶領域へ圧縮データを第２サイズの記憶領域の空き領域の先頭アドレスから順に間を空けずに書き込む。

Description

ストレージシステムおよび記憶デバイスの制御方法
　本発明は、ストレージシステムおよび記憶デバイスの制御方法に関する。
　ストレージのビットコストを削減するため、データ量を削減する技術へのニーズが高くなっている。データ量を削減する技術としては、データ圧縮技術が知られている。一方、データの格納に使用する容量を削減する技術として、容量仮想化技術が知られている。容量の仮想化技術とは、ストレージシステムが利用可能な物理的記憶容量よりも大きな仮想的容量を、ストレージシステムの外側に在るホスト装置などに見せる技術である。
　特許文献１では、データ圧縮技術と容量仮想化技術を用いて、圧縮後のデータサイズに応じて、プール内の格納先領域を動的に、その圧縮後のデータに割当てる。これにより、特許文献１では、記憶容量の使用効率を高めることができる。さらに、特許文献１では、ユーザは、圧縮後のデータサイズに合致するサイズのボリュームを準備する必要がないため、使い勝手も向上する。
米国特許出願公開第２００９／０１４４４９６号明細書
　一般に、データを圧縮伸張する単位とストレージコントローラの処理負荷とは、トレードオフの関係にある。圧縮伸張の単位を小さくする場合を検討する。この場合、ホストから小サイズのデータ読出しを要求される場合には、要求されたデータだけを伸張すればよく、要求されていないデータは伸張する必要がないため、データの読出し性能は向上する。
　しかし、一般に圧縮伸張の単位は、ストレージコントローラが圧縮伸張回路に圧縮伸張の指示を出す単位や、ホストがアクセスする論理アドレスと最終記憶媒体の物理アドレスとの対応付けを行う単位にもなる。従って、圧縮伸張単位を小さくすると、大きいサイズのデータを読み出す場合、圧縮伸張回路に圧縮伸張を指示する回数と最終記憶媒体の物理アドレスとの対応付けを行う回数とが増えるため、ストレージコントローラの負荷が増大する。さらに、ハードディスクなどの最終記憶媒体に対するデータの読み出し回数も増えるため、最終記憶媒体の負荷も増加する。
　一方で、圧縮伸張単位を大きくすれば、読み出しサイズが大きい場合にストレージコントローラの負荷は減少する。しかし、圧縮伸張単位よりも小さいサイズのデータを読み出す場合であっても、圧縮伸張単位でデータを読み出す必要がある。このため、ストレージコントローラは、圧縮伸張単位の全データを読み出して伸張し、その中から小サイズのデータを取り出すことになる。従って、圧縮伸張単位を大きくすると、小サイズのデータの読み出し性能が低下する。
　このように、圧縮伸張単位とストレージコントローラの処理負荷とはトレードオフの関係に立つが、特許文献１では圧縮伸張単位を固定しており、上述のトレードオフについて考慮していない。
　本発明は、上記の問題に鑑みてなされたもので、その目的は、効率を高めることができるようにしたストレージシステムおよび記憶デバイスの制御方法を提供することにある。本発明の他の目的は、小さいサイズでデータを読み書きする場合の性能と、大きいサイズでデータを読み出す場合の性能とを両立できるようにしたストレージシステムおよび記憶デバイスの制御方法を提供することにある。
　本発明の一つの観点では、少なくとも一つの記憶デバイスと、記憶デバイスを制御するコントローラと、キャッシュとを有するストレージシステムであって、記憶デバイスから一回で読み出せるデータの最大サイズである第１サイズと、第１サイズ以下の第２サイズと、第１サイズの約数であって、第１サイズおよび第２サイズよりも小さい値に設定される第３サイズとが予め定義されており、コントローラは、複数の仮想ページで構成される仮想ボリュームを提供し、仮想ボリュームへのライト要求を受けると、第１のサイズを有する複数のストライプで構成されるプール領域を仮想ページサイズで割り当て、ライト要求のデータをキャッシュに格納し、キャッシュに格納されるデータを記憶デバイスに書き込む場合に、データを第３サイズ単位で圧縮して圧縮データを生成し、記憶デバイスの有する記憶領域を第２サイズ単位で選択し、選択した第２サイズの記憶領域へ圧縮データを第２サイズの記憶領域の空き領域の先頭アドレスから順に間を空けずに書き込む。
　本発明によれば、所定の第３サイズを圧縮伸張単位とし、第２サイズの記憶領域内に第２サイズの記憶領域の先頭アドレスから順に間を空けずに圧縮データを書き込むため、第２サイズの記憶領域におけるオフセットを管理するだけで圧縮データの所在を把握できる。従って、管理効率を高めることができる。
図１は、ストレージシステムの構成を示す。 図２は、仮想ボリューム、プール、仮想ページ、実ページ、ストライプ、サブストライプ、物理チャンクなどの関係を示す説明図である。 図３は、キャッシュメモリの記憶内容を示すブロック図である。 図４は、記憶デバイスの一例としてのハードディスクドライブの記憶内容を示すブロック図である。 図５は、仮想ボリュームを管理するテーブルの構成例を示す。 図６は、ストレージプールを管理するテーブルの構成例を示す。 図７は、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）グループを管理するテーブルの構成例を示す。 図８は、ＰＤＥＶ（Physical Device）としてのハードディスクドライブを管理するテーブルの構成例を示す。 図９は、仮想ページを管理するテーブルの構成例を示す。 図１０は、実ページを管理するテーブルの構成例を示す。 図１１は、空き実ページ（フリーの実ページ）を管理するテーブルの構成例を示す。 図１２は、ストライプを管理するテーブルの構成例を示す。 図１３は、物理チャンクを管理するテーブルの構成例を示す。 図１４は、空き物理チャンク（フリーの物理チャンク）を管理するテーブルの構成例を示す。 図１５は、ライト処理のフローチャートを示す。 図１６は、デステージ処理のフローチャートを示す。 図１７は、圧縮データをデステージする処理のフローチャートを示す。 図１８は、物理チャンクを割り当てる処理のフローチャートを示す。 図１９は、リード処理のフローチャートを示す。 図２０は、キャッシュへデータをステージングする処理のフローチャートを示す。 図２１は、圧縮データをキャッシュへステージングする処理のフローチャートを示す。
　以下、図面を参照しながら本発明の実施の形態を説明する。なお、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。「記憶デバイス」の一例としてハードディスクドライブを挙げて説明するが、本実施形態の少なくとも一部はフラッシュメモリデバイスにも適用することができる。
　また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＣＰＵ（Central Processing Unit）によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源（例えばメモリ）及び通信インタフェース装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布ホストコンピュータ又は記憶メディアなどで提供されるものであっても良い。
　また、各要素は番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。本発明の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
　本実施形態では、小さいサイズのデータを読み出す場合に、目的のデータ以外の不要なデータまで伸張してしまうのを抑制し、さらに、大きいサイズのデータを読み出す場合に、コントローラ及びハードディスクドライブの負荷を低減する。
　詳細は後述するが、本実施形態では、論理アドレス領域を、ＲＡＩＤグループを構成するストライプで分割する。ストライプサイズは「第１サイズ」に該当する。ハードディスクの有する物理的記憶領域は、ストライプよりも小さいチャンク（物理チャンク）という単位で分割して管理する。物理チャンクサイズは「第２サイズ」に該当する。ストレージシステムのコントローラは、ストライプに対してデータを圧縮し、圧縮後のデータサイズに応じて必要なだけチャンクを割り当てる。
　コントローラは、ストライプサイズに満たないサイズのデータに対する読み出し要求および書込み要求に対応すべく、ストライプサイズよりもさらに小さいサブストライプサイズ単位で、データの圧縮および伸張を行う。サブストライプサイズは「第３サイズ」に該当する。ストライプはサブストライプ単位で分割されており、サブストライプサイズの領域が圧縮および伸張の単位となっている。
　大きいサイズのデータを読み出すときは、チャンク単位でデータを読み出し、サブストライプ単位で伸張し、キャッシュメモリ上でデータを論理アドレス順に並び替える。大きいサイズのシーケンシャルリード要求をチャンク単位で処理できるため、コントローラの処理負荷を軽減できると共に、ハードディスクへのアクセス回数を削減してハードディスクの負荷を低減することができる。コントローラが圧縮データをシーケンシャルに読み出す場合に、ハードディスクドライブのスループット性能を向上できる。
　さらに、小サイズのデータは、サブストライプ単位でデータを読み書きする。これにより、目的のデータのみを圧縮または伸張すればよく、不要なデータの圧縮または伸張を行う必要がない。従って、処理性能が向上する。
　図１は、ストレージシステム１の全体構成を示すブロック図である。ストレージシステム１は、例えば、コントローラ１０と、ドライブエンクロージャ２０とを備える。ストレージシステム１は、通信ネットワークＮを介して、ホスト計算機２とデータブロックを送受信する。コントローラ１０は、１つであっても良いし、２つ以上であっても良い。ドライブエンクロージャ２０は、１つであっても良いし、２つ以上であっても良い。以下、ホスト計算機２をホスト２と略記する場合がある。
　コントローラ１０は、例えば、ホストＩ／Ｆ（Interface）１１と、ＣＰＵ（Central Processing Unit）１２と、キャッシュメモリ１３（以下、ＣＭと略記する場合がある）と、ドライブＩ／Ｆ１４と、を有する。これらの要素１１～１４は、何れも２つ以上であっても良い。これらの要素１１～１４は、双方向のデータ伝送が可能な内部バス１５によって接続されている。
　通信ネットワークＮは、例えば、ＳＡＮ（Storage Area Network）によって構成することができる。ＳＡＮは、例えば、Ｆｉｂｒｅ　Ｃｈａｎｎｅｌ、Ｅｔｈｅｒｎｅｔ（登録商標）、および／または、Ｉｎｆｉｎｉｂａｎｄ等によって構成することができる。通信ネットワークＮは、ＬＡＮ、インターネット網、専用線網、またはそれらの組み合わせであっても良い。
　ホストＩ／Ｆ１１は、通信ネットワークＮとコントローラ１０とを接続するためのＩ／Ｆである。ホストＩ／Ｆ１１は、例えば、「上位通信部」、「第１通信部」、「上位装置用インターフェース部」等と呼ぶこともできる。ホストＩ／Ｆ１１は、通信ネットワークＮと内部バス１５との間に介在しており、データブロックの送受信を制御する。
　ホストＩ／Ｆ１１は、ホスト２からＩ／Ｏ（Input/Output）要求を受信する。Ｉ／Ｏ要求には、Ｉ／Ｏ先を示す情報（アクセス先情報）と、Ｉ／Ｏコマンドとが関連付けられている。Ｉ／Ｏ先情報は、Ｉ／Ｏ先の論理ボリュームを識別する情報と、その論理ボリュームにおけるＩ／Ｏ先領域を特定するアドレス情報とを含む。Ｉ／Ｏ先の論理ボリュームの識別情報としては、例えば、ＬＵＮ（Logical Unit Number）がある。論理ボリュームにおけるＩ／Ｏ先領域を特定するアドレス情報としては、例えばＬＢＡ（Logical Block Address）がある。Ｉ／Ｏコマンドは、ライトコマンドまたはリードコマンドである。
　ＣＰＵ１２は、所定のコンピュータプログラム（以下「プログラム」という）を実行することで、様々な機能Ｆ１、Ｆ２、Ｆ３を実現する。プログラムは、コントローラ１０内の不揮発性メモリ領域（不図示）に格納されても良いし、コントローラ外のＨＤＤ（Hard Disk Drive）２１等に格納されても良い。ストレージ構成管理部Ｆ１は、例えば、ＲＡＩＤグループの構成、プール構成、仮想ボリューム構成などのストレージの各種構成を管理する機能である。コマンド制御部Ｆ２は、ホスト２から受領したリードコマンドやライトコマンドなどを処理し、その結果をホスト２に返す機能である。圧縮／伸張部Ｆ３は、所定のアルゴリズムに従ってデータを圧縮したり、圧縮データを伸張したりする機能である。なお、以下の説明では、圧縮部Ｆ３と呼ぶ場合がある。圧縮／伸張部Ｆ３は、たとえばＬＺ７７などのような可逆データ圧縮アルゴリズムを備えている。
　ＣＰＵ１２は、ホスト２からＩ／Ｏコマンドを受領すると、Ｉ／Ｏコマンドに関連付けられているＩ／Ｏ先情報を抽出し、Ｉ／Ｏ先情報からＩ／Ｏ先領域を特定する。ＣＰＵ１２は、特定したＩ／Ｏ先領域に対応する１以上の論理ページをそれぞれ提供する１以上のＨＤＤ２１を特定する。そして、ＣＰＵ１２は、特定した各ＨＤＤ２１に対し、論理ページのアドレスが関連付けられたＩ／Ｏコマンドを送信する。各ＨＤＤ２１に送られるＩ／Ｏコマンドには、論理ページのアドレスの他に、そのＩ／Ｏコマンドの送信先ＨＤＤ２１を特定するための識別情報（例えばドライブ番号）が関連付けられてよい。
　ＣＭ１３は、データブロックを一時的に保持する。以下、データブロックをデータと略記する場合がある。ＣＭ１３は、不揮発性メモリによって構成されても良い。不揮発性メモリは、フラッシュメモリ、または磁気ディスクメモリ等であっても良い。若しくは、ＣＭ１３は、揮発性メモリにバックアップ電源を備える構成であっても良い。揮発性メモリは、ＤＲＡＭ（Dynamic Random Access Memory）等であっても良い。バックアップ電源は、例えば、リチウムイオン二次電池などのバッテリであっても良い。ホストＩ／Ｆ１１、ＣＰＵ１２、および／または、ドライブＩ／Ｆ１４は、内部バス１５を介して、ＣＭ１３にデータブロックを入出力してもよい。
　ドライブＩ／Ｆ１４は、コントローラ１０とドライブエンクロージャ２０とを接続するためのＩ／Ｆである。ドライブＩ／Ｆ１４は、例えば、「下位通信部」、「第２通信部」、「記憶デバイス用インターフェース部」等と呼ぶこともできる。
　ドライブＩ／Ｆ１４は、内部バス１５とＨＤＤ２１との間に介在しており、データブロックの送受信を制御する。ドライブＩ／Ｆ１４は、ＳＡＳまたはＦｉｂｒｅ　Ｃｈａｎｎｅｌ等に対応するＩ／Ｆであっても良い。ドライブＩ／Ｆ１４は、ＨＤＤ２１から受信したデータブロックをＣＭ１３に送信しても良い。
　ドライブエンクロージャ２０は、複数の記憶デバイスを有する。図１では、記憶デバイスとして、ＨＤＤ２１（＃０、＃１、＃２、＃３）を示す。以下、各ＨＤＤ２１（＃０、＃１、＃２、＃３）を区別しない場合は、単に「ＨＤＤ２１」という。ドライブエンクロージャ２０の有するＨＤＤ２１の数は、幾つであっても良い。ドライブエンクロージャ２０には、ＨＤＤ２１に代えてまたはＨＤＤ２１と共に、ＳＳＤ（Solid State Drive）等の他の不揮発性メモリが接続されても良い。また、ドライブＩ／Ｆ１４とＨＤＤ２１は、ＳＡＳ（Serial Attached SCSI）、ＦＣ（Fibre Channel）、またはＳＡＴＡ（Serial AT Attachment）によって接続されても良い。
　ドライブエンクロージャ２０のＨＤＤ２１は、そのＨＤＤ２１が提供する論理ページのアドレスが指定されたＩ／Ｏコマンド（ライトコマンドまたはリードコマンド）をコントローラ１０から受信すると、そのＩ／Ｏコマンドに応じた処理を実行する。
　以下では、ＨＤＤ２１のことを、Ｐｈｙｓｉｃａｌ　Ｄｅｖｉｃｅ（ＰＤＥＶ）と呼ぶことがある。また、本実施形態では、データ圧縮によってＰＤＥＶの物理容量以上のデータを格納可能である。すなわち、物理的な容量をそのまま提供するＰＤＥＶと、データ圧縮によって物理容量以上のデータを格納可能な仮想的なＰＤＥＶの二種類が存在する。以下、物理的な容量をそのまま提供するＰＤＥＶを実ＰＤＥＶ１０５と呼び、物理容量以上のデータを格納可能な仮想的なＰＤＥＶを仮想ＰＤＥＶ１０４と呼ぶことにする。
　ストレージシステム１は、２つ以上のドライブエンクロージャ２０を有しても良い。この場合、ドライブＩ／Ｆ１４が複数のポートを有しており、１つのドライブエンクロージャ２０が、ドライブＩ／Ｆ１４の１つのポートに接続されても良い。または、２つ以上のドライブエンクロージャ２０と、１つのドライブＩ／Ｆ１４とが、所定のスイッチ装置（不図示）を介して接続されても良い。または、２つ以上のドライブエンクロージャ２０が、カスケード接続されても良い。
　図２は、仮想ボリューム１０１、ストレージプール１０２、ＲＡＩＤグループ１０３、仮想ＰＤＥＶ１０４、実ＰＤＥＶ１０５、仮想ページ１１０、実ページ１１１、ストライプ１２０、サブストライプ１２１、物理チャンク１２２の関係を示す。本構成により、コントローラ１０は、容量仮想化機能を提供する。なお、ＲＡＩＤグループをパリティグループとも呼ぶ。
　ホスト２に提供される仮想ボリューム１０１は、複数の仮想ページ１１０に分割されている。１以上のＲＡＩＤグループ１０３から構成される記憶領域は、複数の実ページ１１１に分割されている。複数の実ページ１１１の集合をストレージプール１０２と呼ぶ。容量仮想化においては、仮想ボリューム１０１の記憶容量を、実際の容量よりも大きく見せることができる。このため、一般に仮想ページ１１０の数は、実ページ１１１の数よりも多い。
　コントローラ１０は、ホスト２からライト要求されたライト先アドレスに属する仮想ページ１１０に対して、空いている実ページ１１１をストレージプール１０２から割り当て、その実ページ１１１にライトデータを書き込む。ライト処理の詳細は後述する。
　実ページ１１１は、ストライプ１２０と呼ぶ記憶領域の集合である。ストライプ１２０とは、ＲＡＩＤを構成する際に、各ＰＤＥＶに割り当てる最小の連続領域のことを指している。ストライプサイズは「第１サイズ」に該当し、ＰＤＥＶ１０５（ＨＤＤ２１）から一回で読み出すことのできるデータの最大サイズである。
　上述の通り、実ＰＤＥＶ１０５はＨＤＤ２１に対応し、物理的な容量を管理する。実ＰＤＥＶ１０５には、圧縮後のデータが格納される。圧縮後のデータを圧縮データと呼ぶことがある。実ＰＤＥＶ１０５の有する物理的記憶領域は、物理チャンク１２２と呼ぶ単位で分割管理されている。物理チャンク１２２のサイズを、チャンクサイズまたは物理チャンクサイズと呼ぶ場合がある。
　チャンクサイズは「第２サイズ」に該当し、前記ストライプと同じかそれ以下のサイズを有する。例えばストライプサイズと予め設定される所定のデータ圧縮率とから決定することができる。所定のデータ圧縮率とは、本実施形態では、最大圧縮率である。例えば、ストライプサイズが５１２ＫＢ、最大圧縮率が１／８と設定されている場合、チャンクサイズは６４ＫＢ（＝５１２＊１／８）である。チャンクサイズはあらかじめ設定されていても良いし、適切な管理インタフェースによって、ストレージ管理者によって変更されても良い。また、圧縮後のデータ長に応じて可変長にしても良い。たとえば、６４ＫＢ、１２８ＫＢ、２５６ＫＢ、５１２ＫＢなどの複数のチャンクサイズを用意し、ストライプ５１２ＫＢを圧縮した結果によって、適切なサイズの物理チャンクを割り当てても良い。このように、あらかじめ複数のサイズのチャンクを用意しておくことで、複数の物理チャンクを割り当てる処理にかかるオーバヘッドを削減することができる。
　仮想ＰＤＥＶ１０４は、圧縮によって、物理的な容量以上のデータを格納するための記憶空間である。仮想ＰＤＥＶ１０４は、圧縮していないデータ（非圧縮データ）を管理している。仮想ＰＤＥＶ１０４の有する記憶領域は、ストライプ１２０ごとに分割して管理されている。各ストライプ１２０は、さらに細かいサブストライプ１２１と呼ぶ記憶領域ごとに分割して管理されている。
　サブストライプ１２１のサイズは「第３サイズ」に該当し、ストライプサイズの約分であって、かつ、ストライプサイズおよびチャンクサイズのいずれよりも小さい値に設定されている。サブストライプ１２１のサイズは、仮想ボリューム１０１を使用するホスト２の典型的なＩ／Ｏサイズを考慮して設定してもよい。例えば、ホスト２に搭載されたデータベース（不図示）が４ＫＢ単位で仮想ボリューム１０１にアクセスする場合、サブストライプ１２１のサイズを４ＫＢに設定することができる。「４」は、ストライプサイズである５１２ＫＢの約分であり、かつ、ストライプサイズ（５１２ＫＢ）およびチャンクサイズ（６４ＫＢ）のいずれよりも小さい。なお、サブストライプサイズ「４」は、チャンクサイズを割り切ることができると共に、ストライプサイズも割り切ることができる。つまり、サブストライプサイズは、ストライプサイズおよびチャンクサイズの公約数のうち、仮想ボリューム１０１を使用するホスト２のＩ／Ｏサイズに基づいて選択される値である、と定義してもよい。　
　ホスト２が２ＫＢ単位で仮想ボリューム１０１にアクセスすることが多い場合は、サブストライプ１２１のサイズを２ＫＢに設定してもよい。以上のストライプサイズ、サブストライプサイズ、チャンクサイズは、本実施形態を理解するための例示であり、本発明の範囲をそれらの数値に限定する意図はない。
　上述の通り、一般的には、仮想ＰＤＥＶ１０４の容量は、実ＰＤＥＶ１０５の容量よりも大きい値に定義する。或る１つのストライプ１２０に対して、圧縮後のデータサイズに応じて必要なだけの物理チャンク１２２を割り当てる。
　仮想ＰＤＥＶ１０４のストライプ１２０に対する物理チャンク１２２の割り当ては、後述するように、ストライプ管理テーブル２４の中の物理チャンクマッピングテーブル２４１０によって管理される。上述の通り、物理チャンクサイズは、ストライプサイズよりも小さく、１つのストライプ１２０に対して複数の物理チャンク１２２を割り当てることが可能である。ストレージシステム１は、上述の容量仮想化機能により、圧縮後のデータサイズに応じた物理容量だけを消費できるため、容量効率が向上する。
　物理チャンク１２２における圧縮データの書込み位置は、後述するように、ストライプ管理テーブル２４のサブストライプマッピングテーブル２４２０により管理される。サブストライプ１２１のデータは、圧縮されると、物理チャンク１２２内にいわゆる前詰めで格納される。前詰めで格納するとは、ホスト１０２が仮想ボリューム１０１に書き込んだ順番で、圧縮データを間をあけずに物理チャンク１２２に書き込むことである。
　なお、仮想ボリューム１０１とストレージプール１０２との対応関係は、後述する仮想ボリューム管理テーブル３１の仮想ボリューム番号３１１およびプール番号３１４から知ることができる。ストレージプール１０２とＲＡＩＤグループ１０３との対応関係は、後述するストレージプール管理テーブル３２のストレージプール番号３２１およびＲＡＩＤグループリスト３２２から知ることができる。
 　非圧縮データを記憶する仮想ＰＤＥＶ１０４と圧縮データを記憶する実ＰＤＥＶ１０５との対応関係は、後述するＰＤＥＶ管理テーブル３４の仮想ＰＤＥＶ番号３４１および実ＰＤＥＶ番号３４２から知ることができる。
　図３は、ＣＭ１３の記憶領域の論理的構成を示す。ＣＭ１３は、その記憶領域の論理的な構成として、例えば、仮想ボリューム管理テーブル３１と、ストレージプール管理テーブル３２と、ＲＡＩＤグループ管理テーブル３３と、ＰＤＥＶ管理テーブル３４と、仮想ページ管理テーブル３５と実ページ管理テーブル３６と、空き実ページ管理テーブル３７と、キャッシュメモリ領域３８と、バッファ領域３９とを有する。各テーブルの詳細は後で図を用いて説明する。
　キャッシュメモリ領域３８は、ホスト２から書き込まれたデータや、ＨＤＤ２１（ＰＤＥＶ）から読み出したデータを一時的に記憶するために利用される。例えば、コントローラ１０は、ライトコマンドおよびライトすべきデータブロック（以下「ライトデータ）をホスト２から受信すると、そのライト用データブロックをキャッシュメモリ領域３８に格納し、ホスト２に対して完了応答を返す。
　つまり、コントローラ１０は、ライトデータをＨＤＤ２１に格納する前に、ホスト２に対して完了応答を返す。一般的にライト性能（ライト速度）は、ＨＤＤ２１よりもキャッシュメモリ領域３８の方が高いので（高速なので）、キャッシュメモリ領域３８にライトデータを書き込んだ時点でホスト２へ完了応答を返すことにより、ストレージシステム１のホスト２に対する応答性能を高めることができる。
　バッファ領域３９は、圧縮データを伸張する場合、もしくは非圧縮データを圧縮する場合の、一時記憶領域として使用される。
　図４は、ＨＤＤ２１の記憶領域の論理的な構成を示すブロック図である。ＨＤＤ２１は、その記憶領域の論理的な構成として、例えば、メタデータ領域（制御情報領域）２２と、データ領域２３とを有する。
　データ領域２３は、コントローラ１０からライトされたデータブロックを格納する。制御情報領域２２には、データ領域２３を制御するための情報が格納される。メタデータ領域２２は、制御情報を記憶する領域であり、例えば、ストライプ管理テーブル２４と、物理チャンク管理テーブル２５と、空き物理チャンク管理テーブル２６とを有する。各テーブル２４～２６の詳細は後述する。これらのテーブル２４～２６の全部または必要な一部を、ＣＭ１３にキャッシュさせることにより、コントローラ１０がテーブル内の情報に高速にアクセスできるようにしてもよい。なお、テーブル２４～２６は、ＨＤＤ２１に代えて、コントローラ１０内のメモリ（例えばＣＭ１３）に格納してもよい。
　図５は、仮想ボリュームを管理するテーブル３１のデータ構成例を示す。仮想ボリューム管理テーブル３１は、仮想ボリューム１０１に関する情報を有する。
　仮想ボリューム管理テーブル３１は、項目として、例えば、ボリューム番号３１１と、ボリューム容量３１２と、割当済み容量３１３と、プール番号３１４と、ボリューム属性３１５とを有する。なお、図中では、「番号」を＃として示す。
　ボリューム番号３１１は、コントローラ１０が提供する各仮想ボリューム１０１を識別するための識別子（ＩＤ）である。コントローラ１０は、複数の仮想ボリューム１０１を作成し、一つまたは複数のホスト２に使用させることができる。
　ボリューム容量３１２は、仮想ボリューム１０１のボリュームサイズである。割当済み容量３１３は、仮想ボリューム１０１に割当済みの容量、すなわち仮想ボリューム１０１に割り当てられている実ページ１１１の合計サイズである。
　プール番号３１４は、仮想ボリューム１０１に関連付けられたストレージプール１０２を識別するＩＤである。プール番号３１４は、図６に示すストレージプール番号３２１に対応する。仮想ボリューム１０１に割り当てる実ページ１１１は、プール番号３１４に含まれる各ＲＡＩＤグループ１０３の有する実ページ１１１の中から選択される。
　ボリューム属性３１５は、仮想ボリューム１０１の性能特性や容量特性を表す情報を格納する。例えば、ボリューム属性３１５には、仮想ボリューム１０１の全体が圧縮されているかどうかを表す情報を格納することができる。ボリューム属性３１５には、仮想ボリューム１０１のデータの処理状態を示す情報を格納してもよい。データの処理状態を示す情報には、データを圧縮中である、もしくはデータを伸張中である、という情報を含めることができる。
　ストレージ管理者は、適切な管理インターフェースを用いることで、ボリューム属性３１５の値を適宜変更することができる。例えば、ストレージ管理者は、仮想ボリューム１０１の状態を「圧縮」と「非圧縮」の間で切り替えることができる。仮想ボリューム１０１が「非圧縮」から「圧縮」に切り替わった場合、仮想ボリューム１０１に格納されている全データを圧縮して格納しなおす処理が実行される。逆に、仮想ボリューム１０１が「圧縮」から「非圧縮」に切り替わった場合、仮想ボリューム１０１に格納されているデータ全体を伸張して格納しなおす処理が実行される。
　一般的に、仮想ボリューム１０１のボリューム属性を「圧縮」にすると、仮想ボリューム１０１へデータをリードまたはライトするたびに、そのデータを伸張または圧縮する処理が発生する。従って、仮想ボリューム１０１のスループット性能が低下する。
　そのため、頻繁にリード要求やライト要求が発生するデータは圧縮対象にならないように設計することが望まれる。ストレージ管理者は、例えば、ある仮想ボリュームにはバックアップデータしか格納されておらず、ほとんどアクセスが発生しないということがわかっている場合に、その仮想ボリュームを圧縮属性にするという性能設計を行う。
　図６は、ストレージプール１０２を管理するテーブル３２のデータ構成例を示す。ストレージプール管理テーブル３２は、ストレージプール１０２に関する情報を有する。ストレージプール管理テーブル３２は、項目として、ストレージプール番号３２１、ＲＡＩＤグループリスト３２２、プール属性３２３、空き仮想ページ数３２４を有する。
　ストレージプール番号３２１は、コントローラ１０の管理下にある各ストレージプール１０２を識別するＩＤである。ＲＡＩＤグループリスト３２２は、ストレージプール１０２を構成している１または複数のＲＡＩＤグループ１０３の番号を保持する。
　プール属性３２３は、ストレージプール１０２の性能特性や容量特性を表す情報を格納する。例えば、ストレージプール１０２に関連付けられているＲＡＩＤグループ１０３を構成している物理的記憶デバイスの種別を示す情報が格納されていても良い。記憶デバイスの種別としては、例えば、ＨＤＤ２１、もしくはＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）がある。
　プール属性３２３には、ストレージプール１０２の全体が圧縮されているかどうかを表す情報を格納してもよい。ストレージプール１０２の全体が圧縮されている場合、そのストレージプール１０２に関連付けられている各仮想ボリューム１０１のボリューム属性は全て「圧縮」になる。ストレージ管理者は、適切な管理インタフェースによって、ストレージプール１０２の属性を「圧縮」と「非圧縮」の間で切り替えることができる。
　ストレージプール１０２の属性を「圧縮」にすると、そのストレージプール１０２に関連する仮想ボリューム１０１へデータをリードまたはライトするたびに、データを伸張または圧縮する処理が発生するため、スループット性能が低下する。そのため、ストレージ管理者は、性能低下を許容できるかどうかという指標に基づいて、ストレージプール１０２の属性を設定する。
　図７は、ＲＡＩＤグループ１０３を管理するテーブル３３のデータ構成例を示す。ＲＡＩＤグループ管理テーブル３３は、ＲＡＩＤグループ１０３に関する情報を有する。ＲＡＩＤグループ管理テーブル３３は、項目として、ＲＡＩＤグループ番号３３１と、ＲＡＩＤレベル３３２と、ＰＤＥＶ番号３３３とを有する。
　ＲＡＩＤグループ番号３３１は、コントローラ１０の管理するＲＡＩＤグループ１０３を識別するＩＤである。ＲＡＩＤレベル３３２は、ＲＡＩＤグループ１０３のＲＡＩＤレベルを表す情報である。ＲＡＩＤレベル“１０”とは、ＲＡＩＤ（１＋０）の構成であることを示す。ＲＡＩＤレベル“５”とは、ＲＡＩＤ５構成であることを示す。ＰＤＥＶ番号３３３は、ＲＡＩＤグループ１０３を構成している仮想ＰＤＥＶ１０４の識別子（ＩＤ）を格納している。こＰＤＥＶ番号３３３には、複数のＰＤＥＶ番号が格納される。ＰＤＥＶ番号３３３に格納されているＰＤＥＶ番号は、ＰＤＥＶ管理テーブル３４の仮想ＰＤＥＶ番号３４１と対応している。
　図８は、仮想ＰＤＥＶ１０４および実ＰＤＥＶ１０５を管理するテーブル３４のデータ構成例を示す。ＰＤＥＶ管理テーブル３４は、仮想ＰＤＥＶ１０４と実ＰＤＥＶ番号１０５との対応関係を管理する。
　ＰＤＥＶ管理テーブル３４は、項目として、仮想ＰＤＥＶ番号３４１と、実ＰＤＥＶ番号３４２と、物理容量３４３番号と、論理使用容量３４４と、物理使用容量３４５とを有する。
　仮想ＰＤＥＶ番号３４１は、コントローラ１０の管理下にある各仮想ＰＤＥＶ１０４を識別するＩＤである。実ＰＤＥＶ番号３４２は、コントローラ１０の管理下にある各実ＰＤＥＶ１０５を識別するＩＤである。図８では、仮想ＰＤＥＶ番号と実ＰＤＥＶ番号とが一致しているが、異なっていてもよい。
　物理容量３４３は、実ＰＤＥＶ１０５に対応するＨＤＤ２１に格納可能なデータの最大サイズを表している。論理使用量３４４は、実ＰＤＥＶ１０５に格納されている圧縮データを非圧縮データに換算した場合のデータ量を表す。物理使用量３４５は、実ＰＤＥＶ１０５に実際に格納されているデータサイズを表す。物理使用量３４５は、圧縮後のデータサイズに相当する。
　図９は、仮想ページ１１０を管理するテーブル３５のデータ構成例を示す。仮想ページ管理テーブル３５は、例えば、仮想ボリューム１０１と、仮想ページ１１０と、実ページ１１１との対応関係を示す。仮想ページ管理テーブル３５は、項目として、仮想ボリューム番号３５１と、実ページポインタ３５２と、ページ属性３５３と、統計情報３５４とを有する。
　仮想ページ管理テーブル３５は、仮想ボリューム１０１をページ単位で分割した領域の１つずつに対応している。よって、仮想ページ管理テーブル３５は、仮想ボリューム１０１を構成する仮想ページ１１０の数だけ存在する。仮想ボリューム番号３５１は、仮想ボリューム１０１を識別するＩＤである。実ページポインタ３５２は、実ページ管理テーブル３６との対応関係を示すためのポインタである。Ｎｕｌｌと入っている場合には、実ページが割り当てられていないことを示す。ページ属性３５３は、仮想ページ１１０の属性を表す。ページ属性としては、仮想ページ１１０が圧縮されていることを示す「圧縮」、非圧縮であることを示す「非圧縮」がある。
　ストレージ管理者は、適切な管理インターフェースを用いることで、ページ属性３５３の値を変更することができる。しかし一般に、管理者が、仮想ページ単位でページ属性を指定するのは煩雑である。
　そこで、前述のとおり、仮想ボリューム単位やストレージプール単位で、圧縮するか否かを指定できるようにしてもよい。ストレージ管理者が、仮想ボリューム１０１のボリューム属性３１５を圧縮から非圧縮、もしくは非圧縮から圧縮に切り替えた場合、その仮想ボリューム１０１に関連付けられている全ての仮想ページ１１０のページ属性３５３も自動的に変更すればよい。このようにして、仮想ボリューム１０１の属性の変更が仮想ページ１１０の属性に反映されてもよい。
　ストレージ管理者が、ストレージプール１０２のプール属性３２３を圧縮から非圧縮に、もしくは非圧縮から圧縮に、切り替えた場合、そのストレージプール１０２に関連付けられている全ての仮想ページ１１０のページ属性３５３も自動的に変更できる。このように、ストレージプール１０２の属性の変更が仮想ページ１１０に反映されてもよい。
　統計情報３５４は、仮想ページ１１０のデータに対するホスト２からのアクセス負荷を示す情報を格納する。アクセス負荷を示す情報として、例えばＩＯＰＳ（Input/Output Per Second）を用いることができる。ＩＯＰＳに代えて、またはＩＯＰＳと共に、最後にアクセスされた時刻（西暦年月日時分秒）を統計情報３５４に格納してもよい。
　コントローラ１０は、統計情報３５４に基づいて仮想ページ１１０を圧縮するか否か判定してもよい。例えば、アクセス負荷が所定値より少ない仮想ページ１１０は圧縮対象とする、また最後のアクセス時から所定期間（例えば１ヶ月）経過している場合には仮想ページ１１０は圧縮対象とする、などの判定基準を挙げることができる。ストレージ管理者が適切な管理インタフェースを用いることで、仮想ページ１１０を圧縮するか否かの判定基準を変更できるようにしてもよい。
　コントローラ１０は、統計情報３５４および判定基準に基づいて、自動で各仮想ページ１１０の属性を圧縮または非圧縮に切り替えることができる。これにより、ストレージシステム１の性能に影響しない範囲で、容量圧縮機能を適切に使用できる。そして、ストレージ管理者は、統計情報３５４を参照しながら各仮想ページ１１０の属性を一つ一つ手動で設定する必要がないため、管理作業の効率が高まり、利便性が改善する。
　図１０は、実ページ１１１を管理するテーブル３６のデータ構成例を示す。実ページ管理テーブル３６は、実ページ１１１に関する情報を有する。実ページ１１１は、ＲＡＩＤグループ１０３をページ単位で分割した領域のことを指す。実ページ管理テーブル３６は、実ページ１１１ごとに設けられている。
　実ページ管理テーブル３６は、項目として、ＲＡＩＤグループ番号３６１と、実ページ先頭アドレス３６２と、空きページポインタ３６３とを有する。ＲＡＩＤグループ番号３６１は、コントローラ１０の管理下にあるＲＡＩＤグループ１０３のＩＤである。実ページ先頭アドレス３６２は、実ページ１１１の先頭アドレスを示す。図２で述べたように、実ページ１１１は、ＲＡＩＤグループ１０３を構成する各仮想ＰＤＥＶ１０４のストライプ１２０を用いて構成されている。
　空きページポインタ３６３は、仮想ボリューム１０１に割り当てられていない状態の実ページ１１１を管理するために使用する。このように、仮想ボリューム１０１に割り当てられていない状態の実ページ１１１のことを、以下では、空き実ページと呼んだり、フリー実ページと呼んだりすることがある。空き実ページを管理するためのデータ構造は、図１１を用いて説明する。
　図１１は、空き実ページを管理するテーブル３７のデータ構成例を示す。空き実ページ管理テーブル３７は、仮想ボリューム１０１に割り当てられていない状態の空き実ページを管理するための連結リストである。空き実ページ管理テーブル３７は、空きページ管理ポインタ３７１によって管理されている。
　空きページ管理ポインタ３７１は、空き実ページ群の中から、先頭の実ページ管理テーブル３６をさす。先頭の実ページ管理テーブル３６の中の空きページポインタ３６２は、空き実ページ群における次の実ページ管理テーブル３６をさす。図１１では、最後の実ページ管理テーブル３６の空きページポインタ３６２が、空きページ管理ポインタ３７１をさしているが、ＮＵＬＬ値でもよい。
　コントローラ１０は、実ページ１１１を割り当てていない仮想ページ１１０に対する書き込み要求をホスト２から受領すると、仮想ボリューム１０１に関連付けられているＲＡＩＤグループ１０３の中のいずれかから、そのＲＡＩＤグループ１０３に関連付けられた空きページ管理ポインタ３７１を用いて空き実ページを探し出す。コントローラ１０は、見つかった空き実ページを、書込み対象の仮想ページ１１０に割り当てる。コントローラ１０は、例えば、仮想ボリューム１０１に対応するＲＡＩＤグループ１０３のうち、空き実ページ数の最も多いＲＡＩＤグループ１０３を選択することができる。
　図１２は、ストライプ１２０を管理するテーブル２４のデータ構成例を示す。ストライプ管理テーブル２４は、圧縮データを実ＰＤＥＶ１０５の記憶領域のうちどのアドレスに格納したかを管理するためのテーブルである。
　ストライプ管理テーブル２４は、ＨＤＤ２１に格納される。これに代えて、ストライプ管理テーブル２４のうちよく使われる一部のデータを、コントローラ１０内のメモリ１３に記憶させてもよい。
　ストライプ管理テーブル２４は、ストライプ物理アドレス２４００と、末尾物理チャンク番号２４０１と、末尾物理チャンクポインタ２４０２と、有効データサイズ（非圧縮）２４０３と、有効データサイズ（圧縮）２４０４と、物理チャンクマッピングテーブル２４１０と、サブストライプマッピングテーブル２４２０とを有する。
　ストライプ物理アドレス２４００は、ストライプ１２０が実ＰＤＥＶ１０５の記憶領域のどこに対応しているかを示すアドレス（またはストライプ番号）である。末尾物理チャンク番号２４０１は、ストライプ物理アドレス２４００で特定されるストライプ１２０に対するライトデータを最後に格納した物理チャンク１２２を特定する番号を示す。末尾物理チャンクポインタ２４０２は、末尾物理チャンクに格納されたライトデータの末尾アドレスを示す。
　このように、末尾物理チャンク番号２４０１と末尾物理チャンクポインタ２４０２とを組み合わせて管理する。これにより、コントローラ１０は、当該ストライプ１２０に対してホスト２から次のライトデータを受領したときに、そのライトデータを格納するべき場所を直ちに特定することができる。
　有効データサイズ（非圧縮）２４０３は、ストライプ１２０にライトされた、非圧縮データの合計値を示す。有効データサイズ（圧縮）２４０４は、ストライプ１２０にライトされた圧縮データの合計値を示す。
　物理チャンクマッピングテーブル２４１０は、ストライプ１２０に割当済みの物理チャンク１２２を管理するためのテーブルである。物理チャンクマッピングテーブル２４１０は、その構成要素として、ストライプ内物理チャンク番号２４１１と、物理チャンクアドレス２４１２とを有する。ストライプ内物理チャンク番号２４１１は、ストライプ１２０に割り当てられている物理チャンク１２２を特定する識別情報である。物理チャンクアドレス２４１２は、ストライプ１２０に割り当てられている物理チャンク１２２の先頭アドレスを示す。Ｎｕｌｌの場合は、物理チャンク１２２が割り当てられていないことを示す。
　サブストライプマッピングテーブル２４２０は、ストライプ１２０を固定長で分割した各サブストライプ１２１に対して、圧縮データをＨＤＤ２１（実ＰＤＥＶ１０５）の記憶領域のうちいずれの領域に格納したかを管理するためのテーブルである。
　サブストライプマッピングテーブル２４２０は、例えば、サブストライプ番号２４２１と、格納先物理チャンク番号２４２２と、物理チャンク内オフセット２４２３と、圧縮有効フラグ２４２４と、圧縮後データ長２４２５とを対応付けている。
　サブストライプ番号２４２１は、各サブストライプ１２１を識別する情報（ＩＤ）である。格納先物理チャンク番号２４２２は、サブストライプ１２１に書き込まれたデータを圧縮して記憶している物理チャンク１２２を特定する識別情報である。物理チャンク内オフセット２４２３は、格納先物理チャンク１２２の先頭アドレスから当該物理チャンク１２２に書き込まれたデータの先頭アドレスまでのオフセット値を示す。
　圧縮有効フラグ２４２４は、物理チャンク１２２に格納されたデータが圧縮されているか否かを示す情報である。圧縮されている場合は「ＯＮ」、非圧縮の場合は「ＯＦＦ」が設定される。圧縮後データ長２４２５は、物理チャンク１２２に書き込まれた圧縮データのサイズを示す。
　図１３は、物理チャンク１２２を管理するテーブル２５のデータ構成例を示す。物理チャンク管理テーブル２５は、物理チャンク１２２に関する情報を有する。物理チャンク１２２は、上述の通り、実ＰＤＥＶ１０５の記憶領域を固定長で分割した領域である。物理チャンク管理テーブル２５は、物理チャンク１２２ごとに設けられる。本実施例では、非圧縮データを圧縮した後のデータサイズに応じて、その圧縮データを格納するのに必要なだけの物理チャンク１２２をストライプ１２０に割り当てる。
　物理チャンク管理テーブル２５は、その構成要素として、物理チャンク先頭アドレス２５００と、空き物理チャンクポインタ２５０１とを有する。物理チャンク先頭アドレス２５００は、物理チャンク１２２がＨＤＤ２１（実ＰＤＥＶ１０５）の記憶領域のうちいずれのアドレスに対応づいているかを示すポインタである。空き物理チャンクポインタ２５０１は、仮想ＰＤＥＶ１０４に割り当てられていない状態の物理チャンク１２２を管理するために使用する。以下、仮想ＰＤＥＶ１０４に割り当てられていない状態の物理チャンク１２２を、空き物理チャンク、フリー物理チャンクと呼ぶ場合がある。空き物理チャンクを管理するためのデータ構造は、図１４を用いて説明する。
　図１４は、空き物理チャンクを管理するテーブル２６のデータ構成例を示す。空き物理チャンク管理テーブル２６は、仮想ＰＤＥＶ１０４に割り当てられていない状態の空き物理チャンクを管理するための連結リストである。空き物理チャンク管理テーブル２６は、空き物理チャンク管理ポインタ２６０１によって管理されている。
　空き物理チャンク管理ポインタ２６０１は、空き物理チャンクの管理テーブルのうち先頭の物理チャンク管理テーブル２５をさす。先頭の物理チャンク管理テーブル２５の中の空き物理チャンクポインタ２５０１は、次の空き物理チャンクの管理テーブル２５を指し示す。図１４では、最後の物理チャンク管理テーブル２５の空き物理チャンクポインタ２５０１が、空き物理チャンク管理ポインタ２６０１を示しているが、これに代えて、ＮＵＬＬ値でもよい。物理チャンクの割り当て方は、後述する。
　空き物理チャンク管理ポインタ２６０１は、複数存在しても良い。ＨＤＤ２１の一般的な性能特性として、近傍のデータを連続して読み出す方がＨＤＤ２１の応答時間が良いことが知られている。そこで、ストライプ１２０に複数の物理チャンク１２２を割り当てる際には、なるべく近傍の物理チャンク１２２を割り当てることが性能上好ましい。しかし、物理チャンクは圧縮率によって、確保と解放を繰り返すため、常に連続した物理アドレスを持つ物理チャンクを割り当てることは難しい。そこで、各ＨＤＤ２１の記憶領域をいくつかの小領域（以下、ゾーン）に分割し、各ゾーンに含まれる物理チャンク１２２毎に異なる物理チャンク管理ポインタ２６０１に関連付けて管理する。なお、ゾーン分割数はたとえば３２などのようにあらかじめ決められていいてもよい。ストライプ１２０に複数の物理チャンク１２２を割り当てる際には、或る空き物理チャンク管理ポインタ２６０１に連結されている物理チャンク１２２を選択する。厳密には確保した複数の物理チャンク１２２は、ＨＤＤ上で連続ではないかもしれないが、その物理アドレスはあるゾーンの範囲に収まっているため、比較的近傍の物理チャンクを確保することが可能であるこれにより、ストライプ１２０に、ＨＤＤ２１上で近傍になる複数の物理チャンク１２２を割り当てることができる。この結果、そのストライプ１２０に格納したデータを読み出す場合（例えばシーケンシャルリード）、連続する複数の物理チャンク１２２からデータを読み出すことができるため、ＨＤＤ２１の応答時間を短くすることができる。
　図１５は、コントローラ１０がホスト２からライトコマンドを受領したときのライト処理を示すフローチャートである。
　コントローラ１０は、ライトコマンドを解析し、ライト対象となる仮想ページ番号を特定する（ステップ５１０１）。ライトコマンドは、例えばライト対象となる仮想ボリューム番号、仮想ボリューム上のＬＢＡ、ライトデータのサイズなどの情報を含む。コントローラ１０は、例えば、ＬＢＡを仮想ページサイズで割った結果から、仮想ページ番号を特定することができる。
　コントローラ１０は、ライト対象の仮想ページ１１０に実ページ１１１を割当済みかどうかを仮想ページ管理テーブル３５の実ページポインタ３５２が入っているかで判断する（ステップ５１０２）。ライト対象の仮想ページ１１０に実ページを割当済みである場合（ステップ５１０２：Ｎｏ）、後述のステップ５１０６に進む。
　ライト対象の仮想ページ１１０に実ページ１１１が割り当てられていない場合（ステップ５１０２：Ｙｅｓ）、コントローラ１０は、ライト対象の仮想ページ１１０に新しく仮想ページと同じサイズの実ページ１１１を割り当てる（ステップ５１０３）。コントローラ１０は、空きページ管理ポインタ３７１を参照し、未使用の実ページ１１１を１つ特定する。コントローラ１０は、特定した未使用の実ページ１１１をライト対象の仮想ページ１１０についての仮想ページ管理テーブル３５に関連付ける。これにより、仮想ページ１１０に実ページ１１１を新たに割り当てることができる。
　コントローラ１０は、ライト対象の仮想ボリューム１０１のボリューム属性３１５、もしくは仮想ボリューム１０１に関連付けられているストレージプール１０２のプール属性３２３が、圧縮であるか否か判断する（ステップ５１０４）。仮想ボリューム１０１のボリューム属性３１５およびストレージプール１０２のプール属性３２３がいずれも圧縮では無い場合（ステップ５１０４：Ｎｏ）、ステップ５１０８に進む。ステップ５１０８では、実ページ１１１のデータの物理格納先が連続領域となるように、ある実ページ１１１に対しては、或る１つの空き物理チャンク管理ポインタ２６０１を関連付け、常にその空き物理チャンク管理ポインタ２６０１に連結されている物理チャンク１２２を割り当てる。連続した物理チャンク１２２を使用してデータを格納することにより、非圧縮時において、ストライプ管理テーブル２４にアクセスするためのオーバヘッドを減らすことができる。
　その理由を説明する。本実施例では、実ページ１１１のデータの物理格納先は、実ページ１１１を構成するストライプ１２０ごとに、ストライプ管理テーブル２４によって管理されている。ストライプ管理テーブル２４は、ＨＤＤ２１上に格納されているため、コントローラ１０がアクセスするには時間がかかる。さらに、サブストライプ１２１ごとに物理格納先を割り当てるため、複数のサブストライプ１２１にまたがるデータを読み出す際は、複数の物理格納先のアドレスを特定しなければならず、コントローラ１０の処理負荷が増える。
　そこで、本実施例では、データの非圧縮時には、実ページ１１１分のサイズの物理チャンク１２２を連続領域で確保し、その先頭アドレスを実ページ管理テーブル３６の実ページ先頭アドレス３６２に格納する。物理チャンク１２２を連続領域で割り当てるために、例えば、仮想ページ１１０の属性が圧縮に設定されている場合（圧縮属性の有効時）と、仮想ページ１１０の属性が非圧縮に設定されている場合（圧縮属性の無効時）とで、それぞれ別々の空き物理チャンク管理ポインタ２６０１を用いてもよい。
　コントローラ１０は、仮想ページ１１０に非圧縮データを格納する場合に、連続領域を構成する物理チャンク１２２を用いることで、ストライプ管理テーブル２４を参照することなく、実ページ管理テーブル３６を参照するだけで、物理格納先を特定できる。これにより、コントローラ１０のオーバヘッドを削減できる。ステップ５１０８の後、ステップ５１０６に進む。　
　仮想ボリューム１０１のボリューム属性３１５またはストレージプール１０２のプール属性３２３のいずれかが圧縮に設定されている場合（ステップ５１０４：Ｙｅｓ）、コントローラ１０は、ライト対象の仮想ページ１１０の属性３５３を圧縮に変更する（ステップ５１０５）。その後、ステップ５１０６に進む。
　コントローラ１０は、ライト対象のデータ（一つ以上のデータブロックから形成されるライトデータ）をキャッシュメモリ領域３８へ転送する（ステップ５１０６）。以下、ＣＭ１３内のキャッシュメモリ領域３８をキャッシュメモリ、またはキャッシュと呼ぶ場合がある。
　最後にコントローラ１０は、ホストＩ／Ｆ１１を介して、ライトデータの書込みが完了した旨をライトコマンドの発行元であるホスト２に通知する（ステップ５１０７）。
　図１６は、デステージ処理を示すフローチャートである。デステージ処理とは、キャッシュ３８に格納されたデータのうちＨＤＤ２１には未だ書き込まれていないデータを、ＨＤＤ２１の所定領域に格納する処理である。デステージ処理は、ホスト２からのライト要求を処理するタイミングとは非同期に実施できる（ステップ５２００）。
　コントローラ１０は、デステージ対象の実ページ１１１に格納されているデータがＲＡＩＤ５、もしくはＲＡＩＤ６に基づいているか判定する（ステップ５２０１）。判定は、実ページ管理テーブル３６のＲＡＩＤグループ＃３６１のＲＡＩＤレベル３３２をＲＡＩＤグループ管理テーブル３３で確認すれば良い。デステージ対象データがＲＡＩＤ５，もしくはＲＡＩＤ６で記憶されている場合、コントローラ１０は、デステージ対象データについてパリティを生成する（ステップ５２０２）。
　コントローラ１０は、デステージ対象の実ページ１１１の属性が圧縮であるか対応づけられる仮想ページ管理テーブル３５のページ属性３５３で判定する（ステップ５２０３）。デステージ対象の実ページ１１１に圧縮属性が設定されている場合（ステップ５２０３：Ｙｅｓ）、コントローラ１０は、実ページ１１１のデータを圧縮してデステージ処理する（ステップ５２０４）。この処理は図１７で後述する。
　デステージ対象の実ページ１１１に圧縮属性が付いていない場合（ステップ５２０３：Ｎｏ）、コントローラ１０は、実ページ管理テーブル３６を参照し、デステージ対象データを格納している物理アドレスを取得する （ステップ５２０５）。このように、圧縮属性がついていない実ページ１１１へデステージする場合は、同じ物理アドレスに対して上書きでデータを格納する。このようにすることで、物理領域を再利用することができるため、物理領域の容量効率が向上する。そして、コントローラ１０は、デステージ対象データをキャッシュ３８からＨＤＤ２１に転送して書き込ませる（ステップ５２０６）。
　図１７は、圧縮データをデステージする処理のフローチャートを示す。本処理は、図１６中のステップ５２０４の詳細である。本フローチャートはキャッシュのダーティデータについて実行され、１回で処理するダーティサイズは最大でストライプサイズである。
　コントローラ１０は、圧縮データを格納するためのバッファ領域３９をＣＭ１３内に確保する（ステップ５３０１）。コントローラ１０は、キャッシュ３８上のデステージ対象データを、所定のアルゴリズムに従って圧縮／伸張部Ｆ３を用いてサブストライプ１２１単位で圧縮し、圧縮データをステップ５３０１で確保したバッファ３９へ格納する（ステップ５３０２）。
　コントローラ１０は、デステージ対象データを有するストライプ１２０に対して、割当済みの物理チャンク１２２が存在するかどうかを物理チャンクアドレス２４１２が管理されているかで判定する（ステップ５３０３）。デステージ対象のストライプ１２０に物理チャンク１２２が一つも割り当てられていない場合（ステップ５３０３：Ｎｏ）、後述のステップ５３０７に進む。対象ストライプ１２０に物理チャンク１２２が１つ以上割り当てられている場合（ステップ５３０３：Ｙｅｓ）、ステップ５３０４に進む。
　コントローラ１０は、対象ストライプ１２０に割り当てられている物理チャンク１２２内に、デステージ対象データを格納できるだけの空き容量があるかを判定する（ステップ５３０４）。その物理チャンク１２２内にデステージ対象データを記憶するための空き容量が無い場合（ステップ５３０４：Ｎｏ）、ステップ５３０７に進む。なお、圧縮データは物理チャンク１２１内で前詰めに格納されるため、当該物理チャンク１２２の物理チャンクアドレス２４１２から末尾物理チャンクポインタ２４０２までが使用済みの領域であり、末尾物理チャンクポインタ２４０２から当該物理チャンク１２２の終端までが当該物理チャンク１２２内の空き容量である。空き容量がある場合（ステップ５３０４：Ｙｅｓ）、ステップ５３０５に進む。
　コントローラ１０は、ストライプ管理テーブル２４の末尾物理チャンクポインタ２４０２が指すアドレスへ圧縮データを書き込む（ステップ５３０５）。
　一方、ステップ５３０７に進んだ場合、コントローラ１０は、物理チャンク割り当て処理（ステップ５３０７）を実行する。この処理は図１８で後述する。コントローラ１０は、物理チャンク１２２を新たに割り当てた後、その割り当てた物理チャンク１２２の先頭に圧縮データを書き込む（ステップ５３０８）。物理チャンク１２２の先頭は物理チャンクアドレス２４１２を参照することによって求められる。最後に、コントローラ１０は、ストライプ管理テーブル２４を更新する（ステップ５３０６）。
　図１８は、物理チャンクを割り当てる処理のフローチャートを示す。本処理は、図１７中のステップ５３０７の詳細を示す。
　コントローラ１０は、デステージ対象データのサイズがストライプサイズに等しいかどうかを判断する（ステップ５４０１）。
　デステージ対象データのサイズがストライプサイズに等しい場合（ステップ５４０１：Ｙｅｓ）、コントローラ１０は、空き物理チャンク管理テーブル２６を参照することによりフリーの物理チャンク１２２を確保して、対象ストライプ１２０に割り当てる（ステップ５４０７）。
　ストライプ１２０全体のデータをＨＤＤ２１へ上書きする場合、既に格納している旧データを全て捨てた後で、そのストライプ１２０へ新しい物理チャンク１２２を割り当てた方が、物理チャンク管理テーブル２５の更新処理が簡単になる。そこで、本実施例では、デステージ対象データのサイズがストライプサイズに一致する場合は、新しいフリーの物理チャンク１２２を対象ストライプ１２０に割当て直す。
　デステージ対象データのサイズがストライプサイズに等しくない場合（ステップ５４０１：Ｎｏ）、コントローラ１０は、対象ストライプ１２０に割り当てられている物理チャンク１２２の数が所定の閾値ＴｈＰＣ以下であるか判定する（ステップ５４０２）。所定の閾値ＴｈＰＣは、例えば、１つのストライプ１２０に割り当てることのできる最大物理チャンク数、つまり、ストライプのサイズとそのストライプに割り当てる物理チャンクの合計サイズとが一致する場合の物理チャンク数である。最大圧縮率を１／８とした場合、閾値ＴｈＰＣは８となる。
　割当済み物理チャンク数が閾値ＴｈＰＣ以下の場合（ステップ５４０２：Ｙｅｓ）、コントローラ１０は、空き物理チャンク管理ポインタ２６０１を参照することで、フリーの物理チャンクを確保する（ステップ５４０３）。コントローラ１０は、すでに割当済みの物理チャンクと、ＨＤＤ２１上で近傍にある物理チャンクとを優先的に確保する。具体的には、すでに割当済みの物理チャンクと同じ空き物理チャンク管理ポインタ２６０１に連結されている物理チャンク１２２を選択して確保する。できるだけ近い場所にある物理チャンク１２２を割り当てる方が、ストライプ１２０のデータを読み出す際に、ＨＤＤ２１のシーク時間を小さくでき、ＨＤＤ２１の応答時間を向上することができる。コントローラ１０は、物理チャンク管理テーブル２５を更新し（ステップ５４０４）、本処理を終了する。
　一方で、物理チャンク割り当て数が閾値ＴｈＰＣを超えていた場合（ステップ５４０２：Ｎｏ）、後述のステップ５４０５に進む。
　本実施例では、ストライプ１２０に格納したデータを更新する際に、既に割り当て済みの物理チャンク内の空き領域の利用を優先させるために、物理チャンク１２２内に旧データが残ってしまう。物理チャンク１２２には、ライトデータがいわゆる前詰めで書き込まれていくため、上書き対象の旧データは物理チャンク１２２内に残ったままである。
　そこで、本実施例では、ストライプ１２０に割り当てる物理チャンク１２２の合計サイズがストライプサイズを超える場合（割当済み物理チャンク数＞ＴｈＰＣ）、対象ストライプに関連する全ての物理チャンク１２２のデータを読み出し（ステップ５４０５）、ストライプ１２０に新規なフリー物理チャンク１２２を割当てし直し（ステップ５４０６）、必要なデータのみを前詰めで格納し直す（ステップ５４０７）。これにより、無駄なデータを除去し、物理チャンク１２２を有効に使用することができる。
　例えば、或るストライプ１２０への更新ライトを繰り返した結果として、不要なデータが蓄積されてしまい、そのストライプ１２０に対して閾値ＴｈＰＣを越える９個目の物理チャンク１２２を割り当てる必要が生じた場合を検討する。この場合、コントローラ１０は、物理チャンクマッピングテーブル２４１０を参照し、対象ストライプ１２０に割当済みの８個の物理チャンク１２２からデータを全て読み出しす。次に、サブストライプマッピングテーブル２４２０を参照し、各サブストライプに対応するデータだけを、新たに割り当てる物理チャンク１２２に前詰めで格納する。不要な旧データが取り除かれる結果、物理チャンク１２２に空き領域が生じる。不要な旧データの合計サイズが物理チャンクサイズ以上である場合、まるまる一つの物理チャンク１２２をフリー物理チャンクとして再利用できる。
　上述のように、ステップ５４０５では、コントローラ１０は、対象ストライプ１２０に関連付けられた全ての物理チャンク１２２のデータをバッファ３９に読み出し、ステップ５４０６に進む。 
　コントローラ１０は、ステップ５４０６において、ステップ５４０５でバッファ３９に読み出したデータをバッファ３９上でサブストライプ番号順に並べなおす。このとき、デステージ対象の圧縮データを含むサブストライプについては、ステップ５４０５でバッファ３９に読み出したデータではなく、ステップ５３０２で圧縮した新しいデータに置き換える。
　コントローラ１０は、ステップ５４０７において、空き物理チャンク管理ポインタ２６０１を参照し、ステップ５４０３と同様に圧縮データを格納するのに必要な物理チャンク１２２をできるだけ近い領域の中から新規に確保し、ステップ５４０８に進む。
　コントローラ１０は、ステップ５４０８において、フリーになった物理チャンク１２２を空き物理チャンク管理テーブル２６に登録する。最後にコントローラ１０は、物理チャンク管理テーブル２５を更新する（ステップ５４０４）。
　図１９は、リードコマンドを処理するフローチャートを示す。コントローラ１０は、ホスト２から受領したリードコマンドを解析し、リード対象のＬＢＡを特定する（ステップ５５０１）。
　コントローラ１０は、リード対象データがキャッシュメモリ３８に記憶されているかを判定する（ステップ５５０２）。リード対象データがキャッシュメモリ３８に記憶されている場合（ステップ５５０２：Ｙｅｓ）、コントローラ１０は、キャッシュメモリ３８に記憶されているリード対象データをホストＩ／Ｆ１１を介してホスト２に転送する（ステップ５５０５）。
　一方、リード対象データがキャッシュメモリ３８に記憶されていない場合（ステップ５５０２：Ｎｏ）、コントローラ１０は、キャッシュメモリ３８上にリード対象データを格納するためのキャッシュスロットを新規に確保する（ステップ５５０３）。
　コントローラ１０は、キャッシュメモリ３８へのステージング処理を実行する（ステップ５５０４）。キャッシュメモリ３８へのステージング処理とは、ＨＤＤ２１（実ＰＤＥＶ１０５）内のリード対象データをキャッシュメモリ３８へ転送して記憶させる処理である。この処理については図２０で後述する。コントローラ１０は、ＨＤＤ２１からキャッシュメモリ３８へのリード対象データの転送が完了すると、キャッシュメモリ３８上のリード対象データをホスト２へホストＩ／Ｆ１１を介して転送する。
　図２０は、キャッシュステージング処理のフローチャートを示す。本処理は、図１９中のステップ５５０４の詳細を示す。本処理では、ＨＤＤ２１からリード対象データを読み出して、キャッシュメモリ３８へ格納する。
　コントローラ１０は、リードコマンドから抽出されるリード対象アドレスに基づいて、リード対象となる仮想ページ１１０の番号を算出する（ステップ５６０１）。仮想ページ１１０のサイズが固定である場合、コントローラ１０は、例えば、ＬＢＡを仮想ページサイズで割った結果から、仮想ページ番号を特定することができる。
　コントローラ１０は、仮想ページ管理テーブル３５の中の実ページポインタ３５２を取得する（ステップ５６０２）。コントローラ１０は、実ページポインタ３５２がＮＵＬＬではないか否かを判断する（ステップ５６０３）。実ページポインタ３５２がＮＵＬＬの場合（ステップ５６０３：Ｎｏ）、ステップ５６０７に進む。実ページポインタ３５２がＮＵＬＬの場合とは、ホスト２が仮想ページ１１０にデータを一度も書き込んでおらず、リードすべきデータが存在しないという場合である。そこで、コントローラ１０は、０データをキャッシュメモリ３８に格納し、本処理を終了する。
　ステップ５６０３の判定結果がＹｅｓの場合、すなわち実ページポインタ３５２がＮＵＬＬでない場合、ステップ５６０４に進む。コントローラ１０は、リード対象の仮想ページ１１０の属性が圧縮になっているかどうかを判定する（５６０４）。コントローラ１０は、仮想ページ管理テーブル３５に含まれるページ属性３５３を参照することで、ステップ５６０４を判定する。ステップ５６０４の判定結果がＹｅｓの場合、ステップ５６０５に進み、圧縮データステージング処理（ステップ５６０５）を実行する。ステップ５６０４の判定結果がＮｏの場合、ステップ５６０６に進む。
　コントローラ１０は、ステップ５６０６において、リード対象データをキャッシュメモリ３８に読み出す。この場合、ページ属性は圧縮ではないので、コントローラ１０は、ストライプ管理テーブル２４を参照しなくても、実ページ管理テーブル３６内の実ページ先頭アドレス３６２から、対象データを格納している物理アドレスを特定できる。そして、コントローラ１０は、本処理を終了する。
　図２１は、圧縮データをステージングする処理のフローチャートを示す。本処理は、図２０中のステップ５６０５の詳細を示す。
　コントローラ１０は、リード対象のストライプに対応するストライプ管理テーブル２４を参照することで、リード対象データを格納している物理アドレスを取得する（ステップ５７０１）。コントローラ１０は、ホスト２が要求するデータサイズに応じて、ストライプ単位でデータを読み出すか、それともサブストライプ単位でデータを読み出すかを判断する（ステップ５７０２）。
　ステップ５７０２では、物理チャンクサイズ単位で読み出すか（第１リードモード）、サブストライプサイズ単位で読み出すか（第２リードモード）、いずれの読み出し方法を採用した方が、ＨＤＤ２１へのリード回数を少なくできるかという基準で判断する。リード回数が少なくなるほど、ＨＤＤ２１のデータ読み出し時のスループット性能を向上することができるからである。
　そこで、本実施例では、上述の判定基準を実現すべく、例えば、ホスト２が読み出しを要求するサイズをサブストライプ１２１のサイズで割った値（＝要求サイズ／サブストライプサイズ）の方が、ストライプ１２０に割当済みの物理チャンク１２２の数よりも大きいか判定する（ステップ５７０２）。
　ステップ５７０２の判定式を説明する。ここで、「ストライプ１２０へ割当済みの物理チャンク１２２の数」は、物理チャンク単位でデータを読み出す場合のＨＤＤ２１へのリード回数に等しい。コントローラ１０は物理チャンクマッピングテーブル２４１０を参照し、ストライプ内物理チャンクに対応する物理チャンクアドレス２４１２がＮＵＬＬでない物理チャンクの数を数えることにより、ストライプ１２０へ割当済みの物理チャンクの数を求めることができる。コントローラ１０は、物理チャンク単位でＨＤＤ２１からデータを読み出すことができる。一方、「要求サイズ／サブストライプサイズ」は、サブストライプ単位でデータを読み出す場合のＨＤＤ２１へのリード回数に等しい。従って、ホスト２が読み出しを要求するサイズをサブストライプサイズで割った値と、ストライプ１２０へ割当済みの物理チャンク１２２の数とを比較することで、ＨＤＤ２１へのリード回数の大小を判定することができる。
　（要求サイズ／サブストライプサイズ）の値が割当済み物理チャンク数よりも大きい場合（ステップ５７０２：Ｙｅｓ）、ストライプ単位でデータを読み出した方がＨＤＤ２１へのリード回数が少ない。
　そこで、コントローラ１０は、ストライプサイズ分のデータを読み出すために必要なサイズのバッファ３９を確保する（ステップ５７０３）。コントローラ１０は、物理チャンクマッピングテーブル２４１０を参照し、ストライプ１２０に関連付けられている全ての物理チャンク１２２のデータ（圧縮データ）をバッファ領域３９に読み出す（ステップ５７０４）。コントローラ１０は、サブストライプ番号順に、バッファ３９上に記憶した圧縮データを伸張し、非圧縮状態に戻したリード対象データをキャッシュ３８に格納した後、本処理を終了する。
　一方、（要求サイズ／サブストライプサイズ）の値が割当済み物理チャンク数以下の場合（ステップ５７０２：Ｎｏ）、サブストライプ単位でデータを読み出した方がＨＤＤ２１へのリード回数が少ない。
　そこで、コントローラ１０は、少なくともホスト２が要求するデータサイズに等しいだけのバッファ３９を確保する（ステップ５７０６）。コントローラ１０は、サブストライプマッピングテーブル２４２０を参照することで、リード対象のサブストライプのデータをＨＤＤ２１から読み出してバッファ３９に格納する（ステップ５７０７）。コントローラ１０は、バッファ３９上の圧縮データを伸張し、キャッシュメモリ３８に格納する（ステップ５７０８）。そして、コントローラ１０は本処理を終了する。
　このように構成される本実施例によれば、サブストライプサイズを圧縮伸張単位とし、物理チャンクサイズの記憶領域内に前詰めで圧縮データを書き込むため、コントローラ１０は、物理チャンク内のオフセット値を管理するだけで、圧縮データの所在を把握することができる。従って、圧縮データの物理格納先を効率的に管理することができる。さらに、オフセット値を管理すればよいので、テーブルサイズを小さくすることができ、ＣＭ１２の記憶領域を効率的に使用できる。
　本実施例では、図２１で述べたように、ＨＤＤ２１から圧縮データを読み出す場合のリードモードを２種類用意し、リード時のサイズを最適化することで、ＨＤＤ２１へのリード回数を低減する。従って、ＨＤＤ２１からデータを読み出す場合のスループット性能を改善することができる。
　本実施例では、小さいサイズのデータを読み出す場合に、目的のデータ以外の不要なデータまで伸張してしまうのを抑制でき、さらに、大きいサイズのデータを読み出す場合に、コントローラ１０及びＨＤＤ２１の負荷を低減できる。
　本実施例では、大きいサイズのデータを読み出すときは、チャンク単位でデータを読み出してサブストライプ単位で伸張し、キャッシュメモリ３８上でデータを論理アドレス順に並び替える。本実施例では、大きいサイズのシーケンシャルリード要求をチャンク単位で処理できるため、コントローラ１０の処理負荷を軽減できると共に、ＨＤＤ２１へのアクセス回数を削減してＨＤＤ２１の負荷を低減できる。本実施例では、コントローラ１０が圧縮データをシーケンシャルに読み出す場合に、ＨＤＤ２１のスループット性能を向上できる。
　本実施例では、小サイズのデータの場合、サブストライプ単位でデータを読み書きするため、目的のデータのみを圧縮または伸張すればよく、不要なデータの圧縮または伸張を行う必要がない。従って、処理性能が向上する。
　なお、上記実施例は本発明を理解し、実施するための一例であり、本発明は上述した全ての構成を備えるものに限定されない。実施例の構成の一部を、他の構成に置き換えたり、一部の構成を削除したり、ある構成と他の構成とを結合して一つの構成にまとめたりすることができる場合がある。
　上記の各構成、機能、処理部等は、それらの一部または全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよい。あるいは、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
　さらに、特許請求の範囲に記載の各構成は、明示した組合せ以外にも種々組み合わせることができる。
　１：ストレージ装置、２：ホスト計算機、１０：コントローラ、１０１：仮想ボリューム、１０２：ストレージプール、１０３：ＲＡＩＤグループ、１０４：仮想ＰＤＥＶ、１０５：実ＰＤＥＶ、１１０：仮想ページ、１１１：実ページ、１２０：ストライプ、１２１：サブストライプ、１２２：物理チャンク

Claims (15)

  1. 　少なくとも一つの記憶デバイスと、前記記憶デバイスを制御するコントローラと、キャッシュとを有するストレージシステムであって、
    　前記記憶デバイスから一回で読み出せるデータの最大サイズである第１サイズと、前記第１サイズ以下の第２サイズと、前記第１サイズの約数であって、前記第１サイズおよび前記第２サイズよりも小さい値に設定される第３サイズとが予め定義されており、
    　前記コントローラは、複数の仮想ページで構成される仮想ボリュームを提供し、
    前記仮想ボリュームへのライト要求を受けると、前記第１のサイズを有する複数のストライプで構成されるプール領域を前記仮想ページサイズで割り当て、前記ライト要求のデータを前記キャッシュに格納し、
    前記キャッシュに格納される前記データを前記記憶デバイスに書き込む場合に、
    　　前記データを前記第３サイズ単位で圧縮して圧縮データを生成し、
    　　前記記憶デバイスの有する記憶領域を前記第２サイズ単位で選択し、
    　　前記選択した第２サイズの記憶領域へ前記圧縮データを前記第２サイズの記憶領域の空き領域の先頭アドレスから順に間を空けずに書き込む、
    ストレージシステム。
  2. 　前記キャッシュに格納される前記データを有する前記ストライプのデータを既に格納している前記第２サイズの記憶領域に、前記圧縮データのサイズ以上の空き領域がある場合には、前記既に割り当てられている前記第２サイズの記憶領域の空き領域に前記圧縮データを書き込む、
    請求項１記載のストレージシステム。
  3. 　前記コントローラは　リード要求に基づいて、予め用意された第１リードモードと第２リードモードのうちいずれか一つを選択し、
    　前記第１リードモードを選択した場合は、前記リード要求の対象データを記録する前記第１サイズの記憶領域に関連付けられている全ての前記第２サイズの記憶領域から前記対象データの圧縮データを読み出して、前記リード要求に応答し、
    　前記第２リードモードを選択した場合は、前記リード要求の対象データを記録する前記第１サイズの記憶領域に関連付けられている前記第２サイズの記憶領域のうち前記対象データの圧縮データを前記第３サイズ単位で読み出して前記リード要求に応答する、
    請求項１に記載のストレージシステム。
  4. 　前記コントローラは、前記読み出した圧縮データを前記第３サイズ単位で伸張し、前記伸張したデータを所定の順番に並べ替えて前記リード要求に応答する請求項３に記載のストレージシステム。
  5. 　前記コントローラは、前記リード要求の前記対象データのサイズを前記第３サイズで割った値の方が前記第１サイズの記憶領域に割当済みの前記第２サイズの記憶領域の数よりも大きいと判定した場合に前記第１リードモードを選択し、そうではないと判定した場合に前記第２リードモードを選択する、
    請求項４に記載のストレージシステム。
  6. 　前記記憶デバイスはディスクドライブであって、
    　前記コントローラは、前記ディスクドライブの有する記憶領域を前記第２サイズ単位で選択する場合に、前記キャッシュに格納される前記データを有する前記ストライプのデータを既に格納している前記第２サイズの記憶領域と前記ディスクドライブ上で物理的距離が近い第２サイズの記憶領域を優先的に選択する、
    請求項１に記載のストレージシステム。
  7. 　前記コントローラは、前記選択した第２サイズの記憶領域へ前記圧縮データを書き込む場合に、前記ストライプのデータを既に格納している前記第２サイズの記憶領域へ書込み済みのデータのうち不要なデータを除去し、有効なデータだけを新たに選択された前記第２サイズの記憶領域の先頭アドレスから順に間を空けずに書き込む、
    請求項６に記載のストレージシステム。
  8. 　前記コントローラは、前記記憶デバイスへ前記圧縮データを書き込む場合において、前記圧縮データのサイズが前記第１サイズに一致する場合、前記記憶デバイスの物理的記憶領域から前記第２サイズの記憶領域を新規に選択する、
    請求項１に記載のストレージシステム。
  9. 　前記仮想ボリューム単位で、または、前記プール単位で、データを圧縮して管理するか否かを指定することができる、
    請求項１に記載のストレージシステム。
  10. 　前記仮想ボリュームを構成する仮想ページ単位で、前記データを圧縮して管理するか否かを指定することができる、
    請求項１に記載のストレージシステム。
  11. 　前記コントローラは、前記仮想ページの利用状況に応じて、前記データを圧縮して管理するか否かを自動的に決定する、
    請求項１０に記載のストレージシステム。
  12. 　少なくとも一つの記憶デバイスをコントローラにより制御するための方法であって、
    　前記記憶デバイスから一回で読み出せるデータの最大サイズである第１サイズと、前記第１サイズ以下の第２サイズと、前記第１サイズの約数であって、前記第１サイズおよび前記第２サイズよりも小さい値に設定される第３サイズとが予め定義されており、
    　前記コントローラは、複数の仮想ページで構成される仮想ボリュームを提供し、
    前記仮想ボリュームへのライト要求を受けると、前記第１のサイズを有する複数のストライプで構成されるプール領域を前記仮想ページサイズで割り当て、前記ライト要求のデータをキャッシュに格納し、
    前記キャッシュに格納される前記データを前記記憶デバイスに書き込む場合に、
    　　前記データを前記第３サイズ単位で圧縮して圧縮データを生成し、
    　　前記記憶デバイスの有する記憶領域を前記第２サイズ単位で選択し、
    　　前記選択した第２サイズの記憶領域へ前記圧縮データを前記第２サイズの記憶領域の空き領域の先頭アドレスから順に間を空けずに書き込む、
    記憶デバイスの制御方法。
  13. 　前記コントローラは、前記キャッシュに格納される前記データを有する前記ストライプのデータを既に格納している前記第２サイズの記憶領域に、前記圧縮データのサイズ以上の空き領域がある場合には、前記既に割り当てられている前記第２サイズの記憶領域の空き領域に前記圧縮データを書き込む、
    請求項１２記載の記憶デバイスの制御方法。
  14. 　前記コントローラは　リード要求に基づいて、予め用意された第１リードモードと第２リードモードのうちいずれか一つを選択し、
    　前記第１リードモードを選択した場合は、前記リード要求の対象データを記録する前記第１サイズの記憶領域に関連付けられている全ての前記第２サイズの記憶領域から前記対象データの圧縮データを読み出して、前記リード要求に応答し、
    　前記第２リードモードを選択した場合は、前記リード要求の対象データを記録する前記第１サイズの記憶領域に関連付けられている前記第２サイズの記憶領域のうち前記対象データの圧縮データを前記第３サイズ単位で読み出して前記リード要求に応答する、
    請求項１に記載のストレージシステム。
    請求項１２に記載の記憶デバイスの制御方法。
  15. 　前記コントローラは、前記読み出した圧縮データを前記第３サイズ単位で伸張し、前記伸張したデータを所定の順番に並べ替えて前記リード要求に応答する請求項１４に記載の記憶デバイスの制御方法。
PCT/JP2014/061238 2014-04-22 2014-04-22 ストレージシステムおよび記憶デバイスの制御方法 WO2015162681A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/128,089 US10222988B2 (en) 2014-04-22 2014-04-22 Efficient management storage system via defining of several size units in advance
PCT/JP2014/061238 WO2015162681A1 (ja) 2014-04-22 2014-04-22 ストレージシステムおよび記憶デバイスの制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/061238 WO2015162681A1 (ja) 2014-04-22 2014-04-22 ストレージシステムおよび記憶デバイスの制御方法

Publications (1)

Publication Number Publication Date
WO2015162681A1 true WO2015162681A1 (ja) 2015-10-29

Family

ID=54331876

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/061238 WO2015162681A1 (ja) 2014-04-22 2014-04-22 ストレージシステムおよび記憶デバイスの制御方法

Country Status (2)

Country Link
US (1) US10222988B2 (ja)
WO (1) WO2015162681A1 (ja)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017199424A1 (ja) * 2016-05-20 2017-11-23 株式会社日立製作所 計算機システム
CN107422983A (zh) * 2016-05-24 2017-12-01 三星电子株式会社 用于租户感知存储共享平台的方法和装置
KR20180009574A (ko) * 2016-07-19 2018-01-29 에스케이하이닉스 주식회사 입력 데이터를 압축하여 저장하는 데이터 저장 장치
US10242019B1 (en) * 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10311466B1 (en) 2007-01-31 2019-06-04 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US10402901B2 (en) 2007-01-31 2019-09-03 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US10580025B2 (en) 2013-11-15 2020-03-03 Experian Information Solutions, Inc. Micro-geographic aggregation system
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users
US10936629B2 (en) 2014-05-07 2021-03-02 Consumerinfo.Com, Inc. Keeping up with the joneses
US10963961B1 (en) 2006-10-05 2021-03-30 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11144445B1 (en) * 2016-03-28 2021-10-12 Dell Products L.P. Use of compression domains that are more granular than storage allocation units
CN106775456B (zh) * 2016-11-22 2019-11-26 华为技术有限公司 一种数据处理方法、装置及***
US10754557B2 (en) * 2017-09-26 2020-08-25 Seagate Technology Llc Data storage system with asynchronous data replication
KR102527265B1 (ko) * 2018-08-23 2023-05-02 에스케이하이닉스 주식회사 데이터 저장 장치 및 동작 방법, 이를 포함하는 스토리지 시스템
JP6898393B2 (ja) 2019-03-22 2021-07-07 株式会社日立製作所 ストレージシステム及びデータ転送方法
US10620868B1 (en) 2019-03-22 2020-04-14 Hitachi, Ltd. Storage system and data transfer method
US11520523B2 (en) * 2020-05-26 2022-12-06 Western Digital Technologies, Inc. Data integrity protection of ZNS needs
US11561717B2 (en) 2020-05-26 2023-01-24 Western Digital Technologies, Inc. Data integrity protection of SSDs utilizing streams
US11436153B2 (en) * 2020-05-26 2022-09-06 Western Digital Technologies, Inc. Moving change log tables to align to zones
JP2022095257A (ja) * 2020-12-16 2022-06-28 キオクシア株式会社 メモリシステム
US20230325101A1 (en) * 2022-04-12 2023-10-12 Samsung Electronics Co., Ltd. Systems and methods for hybrid storage

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07261938A (ja) * 1994-03-24 1995-10-13 Hitachi Ltd 記憶制御方法及びそれを用いた圧縮機能付きディスクシステム
US20090144496A1 (en) * 2007-11-30 2009-06-04 Hitachi, Ltd. Fast accessible compressed thin provisioning volume
JP2012504795A (ja) * 2009-01-30 2012-02-23 株式会社日立製作所 データ要素を圧縮して格納するストレージシステム及び記憶制御方法
JP2014506688A (ja) * 2011-06-07 2014-03-17 株式会社日立製作所 フラッシュメモリを含むストレージシステム、及び記憶制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07261938A (ja) * 1994-03-24 1995-10-13 Hitachi Ltd 記憶制御方法及びそれを用いた圧縮機能付きディスクシステム
US20090144496A1 (en) * 2007-11-30 2009-06-04 Hitachi, Ltd. Fast accessible compressed thin provisioning volume
JP2012504795A (ja) * 2009-01-30 2012-02-23 株式会社日立製作所 データ要素を圧縮して格納するストレージシステム及び記憶制御方法
JP2014506688A (ja) * 2011-06-07 2014-03-17 株式会社日立製作所 フラッシュメモリを含むストレージシステム、及び記憶制御方法

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10963961B1 (en) 2006-10-05 2021-03-30 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US11954731B2 (en) 2006-10-05 2024-04-09 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US11631129B1 (en) 2006-10-05 2023-04-18 Experian Information Solutions, Inc System and method for generating a finance attribute from tradeline data
US10891691B2 (en) 2007-01-31 2021-01-12 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US11176570B1 (en) 2007-01-31 2021-11-16 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US10311466B1 (en) 2007-01-31 2019-06-04 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US10402901B2 (en) 2007-01-31 2019-09-03 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US11908005B2 (en) 2007-01-31 2024-02-20 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US10650449B2 (en) 2007-01-31 2020-05-12 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US11443373B2 (en) 2007-01-31 2022-09-13 Experian Information Solutions, Inc. System and method for providing an aggregation tool
US10692105B1 (en) 2007-01-31 2020-06-23 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US11803873B1 (en) 2007-01-31 2023-10-31 Experian Information Solutions, Inc. Systems and methods for providing a direct marketing campaign planning environment
US10580025B2 (en) 2013-11-15 2020-03-03 Experian Information Solutions, Inc. Micro-geographic aggregation system
US11847693B1 (en) 2014-02-14 2023-12-19 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US11107158B1 (en) 2014-02-14 2021-08-31 Experian Information Solutions, Inc. Automatic generation of code for attributes
US11620314B1 (en) 2014-05-07 2023-04-04 Consumerinfo.Com, Inc. User rating based on comparing groups
US10936629B2 (en) 2014-05-07 2021-03-02 Consumerinfo.Com, Inc. Keeping up with the joneses
US10242019B1 (en) * 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US11010345B1 (en) 2014-12-19 2021-05-18 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US10445152B1 (en) 2014-12-19 2019-10-15 Experian Information Solutions, Inc. Systems and methods for dynamic report generation based on automatic modeling of complex data structures
WO2017199424A1 (ja) * 2016-05-20 2017-11-23 株式会社日立製作所 計算機システム
CN107422983A (zh) * 2016-05-24 2017-12-01 三星电子株式会社 用于租户感知存储共享平台的方法和装置
KR20180009574A (ko) * 2016-07-19 2018-01-29 에스케이하이닉스 주식회사 입력 데이터를 압축하여 저장하는 데이터 저장 장치
KR102525061B1 (ko) * 2016-07-19 2023-04-21 에스케이하이닉스 주식회사 입력 데이터를 압축하여 저장하는 데이터 저장 장치
US11550886B2 (en) 2016-08-24 2023-01-10 Experian Information Solutions, Inc. Disambiguation and authentication of device users
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users

Also Published As

Publication number Publication date
US10222988B2 (en) 2019-03-05
US20170123679A1 (en) 2017-05-04

Similar Documents

Publication Publication Date Title
WO2015162681A1 (ja) ストレージシステムおよび記憶デバイスの制御方法
US20180173632A1 (en) Storage device and method for controlling storage device
JP6553566B2 (ja) メモリシステムおよび制御方法
US20180349030A1 (en) Storage control device, storage control program, and storage system
US9256367B2 (en) Data storage and moving of relatively infrequently accessed data among storage of different types
JP5792313B2 (ja) ストレージシステム
US8271718B2 (en) Storage system and control method for the same, and program
WO2014102882A1 (en) Storage apparatus and storage control method
JP5816303B2 (ja) フラッシュメモリを含むストレージシステム、及び記憶制御方法
JP6685334B2 (ja) ストレージ装置
US10521122B2 (en) Storage apparatus and method of controlling same
WO2015162758A1 (ja) ストレージシステム
WO2017149592A1 (ja) ストレージ装置
WO2015015611A1 (ja) ストレージシステム及びデータライト方法
US10296229B2 (en) Storage apparatus
US20150363134A1 (en) Storage apparatus and data management
WO2016056104A1 (ja) ストレージ装置、及び、記憶制御方法
US20190243758A1 (en) Storage control device and storage control method
US20180307440A1 (en) Storage control apparatus and storage control method
US9183217B2 (en) Method for decompressing data in storage system for write requests that cross compressed data boundaries
WO2015068233A1 (ja) ストレージシステム
WO2015162755A1 (ja) データを圧縮して格納するストレージ装置
US10929299B2 (en) Storage system, method and non-transitory computer-readable storage medium
US11210214B2 (en) Storage system and compression method of storing compressed data from storage controller physical address space to logical and physical address space of nonvolatile memory
WO2015162766A1 (ja) ストレージシステム及び半導体記憶装置

Legal Events

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

Ref document number: 14890254

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15128089

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14890254

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP