WO2016038714A1 - ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム - Google Patents

ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム Download PDF

Info

Publication number
WO2016038714A1
WO2016038714A1 PCT/JP2014/074045 JP2014074045W WO2016038714A1 WO 2016038714 A1 WO2016038714 A1 WO 2016038714A1 JP 2014074045 W JP2014074045 W JP 2014074045W WO 2016038714 A1 WO2016038714 A1 WO 2016038714A1
Authority
WO
WIPO (PCT)
Prior art keywords
data block
hash value
storage
file
block
Prior art date
Application number
PCT/JP2014/074045
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 PCT/JP2014/074045 priority Critical patent/WO2016038714A1/ja
Priority to CN201480081653.5A priority patent/CN106663052A/zh
Priority to JP2016514208A priority patent/JPWO2016038714A1/ja
Publication of WO2016038714A1 publication Critical patent/WO2016038714A1/ja
Priority to US15/405,953 priority patent/US20170147598A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/174—Redundancy elimination performed by the file system
    • G06F16/1748—De-duplication implemented within the file system, e.g. based on file segments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G06F16/137—Hash-based
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/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/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G06F3/0641—De-duplication techniques
    • 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/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Definitions

  • Embodiments described herein relate generally to a file system, a data deduplication method, and a program for the file system.
  • Deduplication technology is generally divided into two types depending on the subject that performs deduplication.
  • the first deduplication technique is applied in the file system, and the second deduplication technique is applied in the storage apparatus.
  • the first deduplication technique is known as a technique for recording all or part of files having the same contents in the same location of the storage apparatus.
  • the second deduplication technique is known as a technique in which blocks having the same contents are grouped together and stored in a storage apparatus, and the same block is referenced from different access paths.
  • the storage apparatus since the deduplication is executed by the file system, the storage apparatus does not need a special function for deduplication.
  • the second deduplication technique since the deduplication is performed by the storage apparatus (more specifically, the controller of the storage apparatus), the file system does not need a special function for deduplication.
  • the problem to be solved by the present invention is to provide a file system, a data deduplication method, and a program for the file system that can reduce the overhead and data transfer amount associated with deduplication.
  • the file system includes a hash value calculation unit, an access controller, and a deduplication controller.
  • the hash value calculation unit calculates a hash value of at least one data block constituting a file to be stored in the storage.
  • the access controller uses the first hash value as an identifier when the at least one data block includes a first data block and a first cache value of the first data block is calculated. , Storing the first data block in a first location of the storage determined based on the first hash value.
  • the deduplication controller inhibits the first data block from being stored in the first location when a valid second data block is already stored in the first location.
  • FIG. 1 is a block diagram illustrating a typical configuration of a computer system according to one embodiment.
  • FIG. 2 is a diagram for explaining an outline of main functions of the file system shown in FIG.
  • FIG. 3 is a diagram showing an example of an i-node structure used for managing a plurality of blocks constituting a file in the embodiment.
  • FIG. 4 is a diagram illustrating a data structure example of a block object applied in the embodiment.
  • FIG. 5 is a diagram showing an example of two i-nodes of type directory applied in the embodiment.
  • FIG. 6 is a flowchart showing a typical procedure of file writing processing applied in the embodiment.
  • FIG. 7 is a flowchart showing a typical procedure of file read processing applied in the embodiment.
  • FIG. 8 is a flowchart showing a typical procedure of file deletion processing applied in the embodiment.
  • FIG. 1 is a block diagram illustrating a typical configuration of a computer system according to one embodiment.
  • the computer system shown in FIG. 1 includes a host computer (hereinafter referred to as a host) 10 and a storage apparatus 20.
  • a host hereinafter referred to as a host
  • the host 10 and the storage apparatus 20 are connected via a network 30.
  • the host 10 includes a file system 11 and an object controller 12.
  • the file system 11 and the object controller 12 have a common hardware configuration including a CPU 101, a memory 102, and a local hard disk drive (HDD) 103.
  • the file system 11 and the object controller 12 may have unique hardware configurations including a CPU, a memory, and a local HDD, respectively.
  • the CPU 101 functions as a main controller of the file system 11 and the object controller 12 by executing the file system program and the object control program, for example, in a time-sharing manner.
  • the file system program and the object control program are stored in the local HDD 103 in advance.
  • an initial program loader (IPL) executed by the CPU 101 when the host 10 is activated, at least a part of both of the above-described programs is loaded into the memory 102 and used by the CPU 101.
  • IPL initial program loader
  • the IPL is stored in advance in a non-volatile memory such as a flash ROM.
  • the storage device 20 includes a storage 21 and a storage controller 22.
  • the storage 21 is composed of an HDD array, for example, a RAID (Redundant Arrays of Inexpensive Disks or Redundant Arrays of Independent Disks) array configured using a plurality of HDDs.
  • the storage 21 may be a flash array configured using a plurality of flash memories (that is, a flash array having an access speed higher than that of the HDD array).
  • the storage 21 may be a hierarchical storage composed of a low-speed storage (for example, an HDD array) and a high-speed storage (for example, a flash array).
  • the flash array may be composed of a plurality of solid state drives (SSD) having compatibility with the HDD.
  • SSD solid state drives
  • the storage controller 22 accesses the storage 21 in response to an access request from the host 10 (more specifically, the object controller 12 of the host 10).
  • the storage controller 22 also manages the area of the storage 21 in units of blocks called blocks.
  • the storage controller 22 further manages the correspondence between the logical address (logical block address) of each block and the physical address assigned to the logical block address.
  • FIG. 2 is a diagram for explaining an outline of main functions of the file system 11.
  • the storage 21 of the storage apparatus 20 is recognized as the object storage 210 from the file system 11.
  • the object storage 210 is a kind of logical storage, and is used to store data (for example, file data) in units of objects.
  • the object size (data length) is variable.
  • the object size may be a fixed length.
  • FIG. 2 assumes a case where an application operating on the host 10 requests the file system 11 to store the file F in the object storage 210.
  • the main controller (that is, the CPU 101) of the file system 11 converts the file F into a plurality of data blocks, for example, four data blocks (hereinafter simply referred to as blocks) B1, as indicated by an arrow A1 in FIG. , B2, B3 and B4.
  • the sizes of the blocks B1 to B4 are fixed lengths. However, as will be described later, the block size may be variable.
  • the CPU 101 uses a well-known hash function HF such as SHA-256, for example, as indicated by an arrow A2 in FIG. 2, and the hash values H1, H2, H3 of the blocks B1, B2, B3 and B4 to B4, respectively. And H4.
  • a well-known hash function HF such as SHA-256
  • the number of bits constituting each of the hash values H1, H2, H3, and H4 is 256.
  • the hash values H1, H2, H3, and H4 are 1334, 3456, 1234, and 5628, respectively. That is, the hash values H1 and H3 are the same.
  • the data is stored in the object storage 210 as indicated by A3 (more specifically, arrows A31, A32, and A34).
  • a technique in which object storage is used for storing blocks in this way is called object storage technique.
  • the above ID and block are processed as an object ID and an object, respectively.
  • This object is also called an object corresponding to a block, a block object, or a data object.
  • the feature of this embodiment is that the CPU 101 uses a hash value of a block as an object ID indicating the object of the block.
  • the CPU 101 treats blocks corresponding to the same ID (object ID) as the same object in order to eliminate duplication. That is, the CPU 101 prevents the blocks B1 and B3 having the same contents from being stored in the object storage 210 in duplicate.
  • object ID object ID
  • FIG. 2 it is assumed that storage of blocks in the object storage 210 starts from the first block B1 of the file F. In this case, the CPU 101 prevents the block B3 from being stored in the object storage 210. Thereby, duplication of the blocks B1 and B3 in the object storage 210 is eliminated.
  • each file is managed using an i-node in accordance with the Linux (registered trademark) virtual file system (VFS) format.
  • Linux registered trademark
  • VFS virtual file system
  • the i-node iNp is also managed as one object (that is, an object of the i-node iNp).
  • the i-node iNp includes a block table 310.
  • the i-node iNp further includes attribute information 320 representing attributes of the file Fp.
  • the attribute information 320 of the file Fp is also called metadata of the file Fp.
  • the attributes of the file Fp include the size of the file Fp, the authority to access the file Fp, and a time stamp.
  • the time stamp includes the date and time when the file Fp was last accessed, the date and time when the file Fp was last changed, and the date and time when the file Fp was created.
  • the block table 310 is used to record information indicating the location of the block Bq (hereinafter referred to as block location information).
  • block location information information indicating the location of the block Bq
  • the address of the block Bq is used as the block location information.
  • the hash value Hq of the block Bq is used as the block location information.
  • the storage controller 22 manages the correspondence between the logical address (for example, logical block address) of the small area in the logical volume and the physical address of the small area in the physical volume using the address management table.
  • the location of the object OBq in the object storage 210 is mapped to a small area column in the logical volume. As described above, this location is indicated by the object ID of the object OBq. Therefore, the object controller 12 manages the correspondence between the object ID of the object OBq and the logical block address LBAq of the first small area of the small area column in the logical volume using the object management table.
  • the object management table is stored in the local HDD 103 of the host 10, for example. It is assumed that the number of bits constituting the logical block address LBAq is 64.
  • the file system 11 reads (or writes) the object OBq of the block Bq through the object controller 12 as follows. First, the file system 11 requests the object controller 12 to read (or write) the object OBq using the hash value Hq of the block Bq as an object ID indicating the object OBq of the block Bq. In response to this request, the object controller 12 logically reads (or writes) the object OBq from (or into) the location of the object storage 210 that is uniquely determined by the hash value Hq (object ID).
  • the object controller 12 refers to the object management table based on the object ID of the object OBq of the block Bq (that is, the hash value Hq of the block Bq). As a result, the object controller 12 acquires the logical block address LBAq associated with the object ID of the object OBq. Then, the object controller 12 requests the storage controller 22 of the storage apparatus 20 to read (or write) the contents of the object OBq based on the acquired logical block address LBAq and the size of the object OBq.
  • the storage controller 22 In response to a request from the object controller 12, the storage controller 22 refers to the address management table based on the logical block address LBAq. As a result, the storage controller 22 obtains a physical address associated with the logical block address LBAq. Then, the storage controller 22 reads (or writes) the contents of the object OBq from (or into) the location in the storage 21 indicated by the acquired physical address and the size of the object OBq. In the following description, for the sake of simplicity, description relating to physical reading or writing of objects is omitted.
  • the size of the i-node iNp (more specifically, the object of the i-node iNp) is assumed to be variable. Therefore, in this embodiment, it is possible to record the hash values of all the blocks Bq (B0 to Bm ⁇ 1) constituting the file Fp in the block table 310 of the i-node iNp. That is, in FIG. 3, for example, the hash values H0, H1,..., Hm-2, Hm-1 of the blocks B0, B1,. In this case, the blocks B0, B1,..., Bm-2, Bm-1 are locations determined by using the hash values H0, H1,..., Hm-2, Hm-1 recorded in the block table 310 as IDs. Stored directly.
  • the size of the i-node iNp may be a fixed length.
  • the number of blocks Bq constituting the file Fp is expressed as Np
  • the number of hash values that can be recorded in the block table 310 is expressed as Nq.
  • the hash values Hn and Hn + 1 of the blocks Bn and Bn + 1 are recorded in the indirect block IBx, and the hash value Hx of the indirect block IBx is recorded in the block table 310.
  • the addresses of the blocks Bn and Bn + 1 are recorded in the indirect block IBx, and the addresses of the indirect block IBx are recorded in the block table 310.
  • the CPU 101 may use, for example, a two-stage indirect block or a three-stage indirect block. In this case, the CPU 101 records the hash value of the next-stage indirect block, not the address of the next-stage indirect block, in the 2-stage indirect block or the 3-stage indirect block.
  • FIG. 4 shows an example of the data structure of the object OBq of the block Bq described above, which is applied in the present embodiment.
  • the object OBq is stored in a data area in the object storage 210.
  • the data area is allocated to the file system 11 and used by the file system 11.
  • the host 10 includes a plurality of file systems including the file system 11, the data area may be shared by the plurality of file systems.
  • first and second data areas may be prepared in the object storage 210.
  • the first file system (or first set of file systems) uses the first data area
  • the second file system (or second set of file systems) uses the second data.
  • the area is used.
  • the hash value of the first object to be stored in the first data area is the same as the hash value of the second object already stored in the second data area.
  • the first file system (or each first file system) has the same hash value
  • the first object is processed as an object different from the second object. That is, even if the second object exists, the first object is excluded from the deduplication target.
  • the i-node iNp shown in FIG. 3 is also called an i-node object and is stored in the i-node area in the object storage 210.
  • the i-node area is allocated to the file system 11 and is used by the file system 11.
  • the host 10 includes a plurality of file systems including the file system 11, individual i-node areas may be used by the plurality of file systems.
  • the object OBq is composed of metadata 410 and actual data 420.
  • the actual data 420 of the object OBq is the entity of the object OBq.
  • the actual data 420 matches the content of the block Bq.
  • the metadata 410 of the object OBq indicates management information related to the object OBq and includes a duplication count DCNTq.
  • the duplicate count DCNTq is also called a reference count and indicates the number of blocks Bq that match the actual data 420. That is, the duplication count DCNTq indicates the number of blocks having the same hash value as the hash value Hq of the actual data 420 (block Bq).
  • the metadata 410 further includes an object ID unique to the object OBq, information indicating the size of the actual data 420, and an address (for example, a logical block address) indicating the storage destination of the actual data 420. As the object ID of the object OBq, the hash value Hq of the block Bq corresponding to the object OBq is used.
  • L Inodes are generally classified into multiple types.
  • a file more specifically, a normal file
  • File inodes are used to manage files.
  • the type of inode iNp shown in FIG. 3 is a file.
  • an i-node whose type is a file may be referred to as a file inode
  • an i-node whose type is a directory may be referred to as a directory inode.
  • An i-node has an i-node number unique to the i-node regardless of the type of the i-node.
  • the i-node number of the i-node (that is, i-node object) is used as the object ID of the i-node object.
  • FIG. 5 shows an example of an i-node 500 of a directory type applied in the present embodiment.
  • the size of the i-node 500 is assumed to be variable length like that of the i-node iNp.
  • the i-node 500 is also managed as one object (that is, an object of the i-node 500). For this reason, the i-node 500 may be referred to as an i-node object 500.
  • the i-node 500 has an i-node number iNdn, for example, and includes a directory entry table (hereinafter referred to as an entry table) 510 and attribute information 520.
  • an entry table hereinafter referred to as an entry table
  • the entry table 510 is used to record a set of i-node numbers and file names of all files included in the directory indicated by the i-node 500.
  • a combination of the i-node number of the i-node corresponding to the file and the file name of the file is added to the empty entry in the entry table 510 of the i-node 500 by the file system 11, for example. .
  • the file may be a directory instead of a normal file.
  • the i-node number and directory name of the directory type are recorded in the entry table 510.
  • the size of the i-node (directory i-node) 500 may be a fixed length.
  • the file system 11 CPU 101
  • the ID of the object (that is, the list of directory entries) may be recorded in the i-node 500.
  • the file system 11 uses a special block for managing the file system 11.
  • This special block is called a super block, and is generated when the file system 11 is generated.
  • the super block is used for recording management information of the file system 11 (hereinafter referred to as file system management information), and is stored in an i-node area in the object storage 210, for example.
  • file system management information management information of the file system 11
  • Super blocks are also managed as objects. For this reason, a special object ID is assigned to the super block.
  • the file system management information includes i-node list information.
  • the i-node list information includes information (hereinafter referred to as i-node management information) regarding the storage destination for each i-node reserved in advance in the i-node area of the object storage 210.
  • the i-node management information includes an i-node number unique to the corresponding i-node.
  • the file system 11 can identify an i-node having the target i-node number as an ID by referring to the i-node management information included in the file system management information.
  • FIG. 6 is a flowchart showing a typical procedure of file writing processing applied in the present embodiment.
  • the size of the file Fp is an integer multiple of 4 KB.
  • an application program executed in the host 10 requests the file system 11 to write the file Fp.
  • the CPU 101 of the file system 11 starts file writing processing.
  • the plurality of blocks Bq are stored in the memory 102, for example.
  • the number of blocks Bq is m.
  • the CPU 101 initializes variables q and Q to 0 and m, respectively (step S2).
  • the variable q indicates the relative position of the block Bq in the file Fp.
  • the variable Q indicates the number of divided blocks Bq.
  • the CPU 101 functions as a hash value calculation unit, and calculates the hash value Hq of the contents of the block Bq stored in the work area of the memory 102 (step S3). Then, the CPU 101 proceeds to step S4.
  • step S4 the CPU 101 functions as a file management unit, and the calculated hash value Hq is described in the block table 310 of the i-node iNp having the i-node number iNpn associated with the file name of the file Fp as described below.
  • the CPU 101 refers to the entry table 510a of the i-node 500a based on the file name of the file Fp.
  • the CPU 101 acquires the i-node number iNpn associated with the file name of the file Fp. That is, the CPU 101 searches the i-node number iNpn associated with the file name of the file Fp from the entry table 510a of the i-node 500a.
  • the CPU 101 reads out the i-node iNp having the i-node number iNpn from the i-node area of the object storage 210 via the object controller 12 by using the searched i-node number iNpn as an ID.
  • the CPU 101 stores the read i-node iNp in the work area of the memory 102.
  • the CPU 101 records the hash value Hq of the block Bq in the block table 310 of the i-node iNp stored in the work area of the memory 102.
  • the CPU 101 functions as a deduplication controller. Then, using the hash value Hq of the block Bq as the object ID, the CPU 101 confirms the presence of the object OBq having the same object ID as the object ID as follows (step S5). That is, the CPU 101 uses the hash value Hq of the block Bq as an object ID to read out an object from a location in the object storage 210 that is uniquely determined by the hash value Hq via the object controller 12. Then, the CPU 101 confirms that the target object OBq exists on the condition that a valid object is stored in the above location.
  • the CPU 101 determines the result of confirmation of the target object OBq. That is, the CPU 101 determines whether the target object OBq exists at the above-described location (step S6).
  • the target object OBq does not exist in the above-described location (No in step S6). That is, it is assumed that there is no valid block having the same contents as the block Bq at a location (first location) uniquely determined by the hash value Hq of the block Bq.
  • the CPU 101 determines that the block Bq does not overlap with any of the blocks stored in the data area in the object storage 210 used by the file system 11, and therefore deduplication regarding the block Bq is unnecessary. To do.
  • the CPU 101 functions again as a file access controller. Then, the CPU 101 writes the block Bq (first block) as the object OBq having the hash value Hq as the object ID in the above-described location (step S7). This writing is executed by the object controller 12 when the CPU 101 requests the object controller 12 to write the object OBq.
  • the object OBq includes metadata 410 and actual data 420 as shown in FIG.
  • the metadata 410 includes an object ID that matches the hash value Hq.
  • the metadata 410 of the object OBq further includes a duplication count DCNTq having a value of 0 (initial value).
  • the actual data 420 matches the contents of the block Bq.
  • the target object OBq (more specifically, an object having a block having the same content as the block Bq) exists in the above location (Yes in step S6). That is, it is assumed that a valid block (second block) having the same content as the block Bq already exists at a location uniquely determined by the hash value Hq of the block Bq.
  • the CPU 101 determines that the block Bq overlaps with a valid block existing at the above-described location, and therefore deduplication regarding the block Bq is necessary. Therefore, the CPU 101 functions as a deduplication controller, skips step S7 for deduplication, and then proceeds to step S8. That is, the CPU 101 suppresses writing of the block Bq as the object OBq in the above-described location for the purpose of deduplication, and proceeds to step S8.
  • step S8 the CPU 101 increases the duplication count DCNTq in the metadata 410 of the object OBq by 1.
  • the duplication count DCNTq 1 indicates that the number of blocks Bq matching the actual data 420 of the object OBq is 1.
  • the duplication count DCNTq is an integer equal to or greater than 1, so the duplication count DCNTq is updated to a value greater than or equal to 2.
  • step S10 the variable q increased by 1 becomes equal to the variable Q (Yes in step S10).
  • the CPU 101 determines that no block Bq to be processed remains. Then, the CPU 101 proceeds to step S11.
  • step S11 the CPU 101 functions as a file management unit, and records new attribute information 320 of the file Fp in the i-node iNp stored in the work area of the memory 102. That is, the CPU 101 updates the old attribute information 320 of the i-node iNp to new attribute information 320.
  • the CPU 101 writes a new i-node iNp including the new block table 310 and attribute information 320 as an object OiNp having the i-node number iNpn as an ID in the i-node area in the object storage 210 (step S12). That is, the CPU 101 updates the old i-node iNp (old object OiNp) to the new i-node iNp (new object OiNp). As a result, the file writing process ends. Note that the writing of the object OiNp in step S12 is executed by the object controller 12 when the CPU 101 requests the object controller 12 to write the object OiNp.
  • FIG. 7 is a flowchart showing a typical procedure of file read processing applied in the present embodiment.
  • the CPU 101 of the file system 11 starts a file reading process.
  • the CPU 101 functions as a file access controller, and reads the object OiNp of the i-node iNp from the object storage 210 using the i-node number iNpn associated with the file Fp as an ID (step S21). This reading is executed by the object controller 12 when the CPU 101 requests the object controller 12 to read the object OiNp.
  • the read object OiNp of the i-node iNp is stored in the work area of the memory 102.
  • the i-node number iNpn is acquired by the CPU 101 referring to the entry table 510a of the i-node 500a based on the file name of the file Fp, as in the above-described file writing process.
  • the CPU 101 selects the hash value Hq of the block Bq not yet selected from the block table 310 of the i-node iNp included in the read object OiNp (step S22).
  • the CPU 101 reads the object OBq of the block Bq from the object storage 210 using the selected hash value Hq as the object ID (step S23). That is, the CPU 101 reads out an object OBq having the selected hash value Hq as an object ID.
  • the read object OBq is stored in the work area of the memory 102.
  • the CPU 101 determines whether all hash values Hq recorded in the block table 310 of the i-node iNp included in the object OiNp read in step S21 have been selected (step S24). If the hash value Hq not yet selected exists in the block table 310 of the i-node iNp (No in step S24), the CPU 101 returns to step S22. And CPU101 performs step S22 thru
  • Steps S22 to S24 are repeatedly executed for all hash values Hq recorded in the block table 310 of the i-node iNp (Yes in Step S24). In this case, the CPU 101 proceeds to step S25.
  • step S25 the CPU 101 functions as a file management unit, and records new attribute information 320 of the file Fp in the i-node iNp included in the object OiNp stored in the work area of the memory 102. That is, the CPU 101 updates the old attribute information 320 of the i-node iNp to new attribute information 320.
  • the CPU 101 sets the new i-node iNp including the new block table 310 and attribute information 320 as an object OiNp having the i-node number iNpn as an ID, and enters the i-node area in the object storage 210 via the object controller 12.
  • Write step S26.
  • the old i-node iNp old object OiNp
  • new object OiNp new object OiNp
  • FIG. 8 is a flowchart showing a typical procedure of file deletion processing applied in this embodiment.
  • the application program requests the file system 11 to delete the file Fp.
  • the CPU 101 of the file system 11 starts file deletion processing.
  • the CPU 101 functions as a file access controller, and reads the object OiNp of the i-node iNp from the object storage 210 using the i-node number iNpn associated with the file Fp as an ID (step S31).
  • the read object OiNp of the i-node iNp is stored in the work area of the memory 102.
  • the CPU 101 selects the hash value Hq of the block Bq that has not yet been selected from the block table 310 of the i-node iNp included in the read object OiNp (step S32).
  • the CPU 101 reads out the metadata 410 of the object OBq of the block Bq from the object storage 210 using the selected hash value Hq as the object ID (step S33).
  • the read metadata 410 of the object OBq is stored in the work area of the memory 102.
  • the CPU 101 functions as a file deletion controller and decrements the duplicate count DCNTq in the metadata 410 included in the object OBq read in step S33 by 1 (step S34). Then, the CPU 101 determines whether or not the duplication count DCNTq decremented by 1 is equal to 0 (step S35).
  • step S35 If the duplication count DCNTq decremented by 1 is equal to 0 (Yes in step S35), the CPU 101 determines that the number of blocks Bq that match the actual data 420 included in the object OBq is equal to the deletion of the current file Fp. It is judged that it becomes zero. In this case, the CPU 101 deletes the object OBq from the object storage 210 (step S36). Then, the CPU 101 proceeds to step S37.
  • step S35 the CPU 101 determines that the number of blocks Bq matching the actual data 420 included in the object OBq is the current file. It is determined that deletion of Fp does not become zero. In this case, the CPU 101 skips step S36 and proceeds to step S37.
  • step S37 the CPU 101 determines whether all the hash values Hq recorded in the block table 310 of the i-node iNp included in the read object OiNp have been selected, as in step S24 in the file reading process described above. judge. If a hash value Hq that has not yet been selected exists in the block table 310 of the i-node iNp (No in step S37), the CPU 101 returns to step S32. And CPU101 performs step S32 thru
  • Steps S32 to S37, or Steps S32 to 35 and S3 are repeatedly executed for all hash values Hq recorded in the block table 310 of the i-node iNp (Yes in Step S37).
  • the CPU 101 deletes the object OiNp from the object storage 210 (step S38). Note that the deletion of the object OiNp in step S38 is executed by the object controller 12 when the CPU 101 requests the object controller 12 to delete the object OiNp.
  • the CPU 101 reads the i-node (i-node object) 500a using the i-node number iNdn of the i-node (directory i-node) 500a as an ID (S39).
  • the read i-node 500 a is stored in the work area of the memory 102.
  • the CPU 101 deletes the combination of the i-node number iNpn and the file name of the file Fp from the entry table 510a of the i-node 500a read in step S39 (step S40).
  • the CPU 101 uses the i-node 500a including the entry table 510a from which the pair of the i-node number iNpn and the file name of the file Fp is deleted as an object having the i-node number iNdn of the i-node 500a as an ID in the object storage 210. Is written in the i-node area (step S41). Thereby, the file deletion process ends.
  • the CPU 101 creates a file i-node iNp in the work area of the memory 102, and records the attribute information of the file Fp in the file i-node iNp.
  • the CPU 101 writes the file i-node iNp in which the attribute information of the file Fp is recorded in the i-node area of the object storage 210 using the i-node number iNpn as an ID.
  • the CPU 101 reads the i-node (i-node object) 500a using the i-node number iNdn of the i-node (directory i-node) 500a as an ID.
  • the CPU 101 adds a set of the i-node number iNpn and the file name of the file Fp to the entry table 510 of the read i-node 500a.
  • the CPU 101 sets the i-node 500a including the entry table 510a to which the combination of the i-node number iNpn and the file name of the file Fp is added as an object having the i-node number iNdn as an ID in the i-node area in the object storage 210. Write. Thereby, the file creation process ends.
  • the file system 11 uses the hash value of the block calculated from the contents (that is, data) of the block to be written in the object storage 210 as the ID (object ID). Determine (or identify) the location of Therefore, for example, when it is necessary to write the block Bq to the object storage 210, the file system 11 accesses the above-described location using the hash value Hq of the block Bq as an ID. Only by this access, the file system 11 can easily determine whether a block having the same ID as the hash value Hq is already stored in the storage apparatus 20.
  • the file system 11 calculates a hash value of the valid block for the above determination, and uses the calculated hash value as a hash of the block Bq. It is not always necessary to compare with the value Hq.
  • the storage controller 22 may store the block Bq in a location uniquely determined by the hash value Hq of the block Bq in response to a request from the file system 11 side, and determination of duplication is unnecessary. It is.
  • the size of each of the Q blocks Bq is indicated by the size information included in the metadata 410 of the object OBq of each block Bq. Therefore, each of the Q blocks Bq may have a variable length.
  • the file Fp may be divided into a plurality of blocks so as to include blocks having the same contents as the contents of the blocks already stored in the object storage 210.
  • each of the plurality of files includes a plurality of continuous blocks having the same contents, for example, two blocks Ba and Bb.
  • the objects OBa and OBb of the blocks Ba and Bb may be combined into one object OBab. That is, the blocks Ba and Bb may be combined into one block Bab.
  • the CPU 101 functions as a file management unit, and the block size is variable, so that the deduplication rate can be improved. Further, the access performance can be improved by collecting a plurality of continuous blocks.
  • the object OBq of the block Bq is read using the hash value Hq selected in step S22 or S32 as an ID (step S23 or S33).
  • the CPU 101 may calculate a hash value of the real data 420 in the read object OBq, that is, a hash value of the block Bq, and compare the calculated hash value with the selected hash value Hq. . Based on the result of this comparison, the CPU 101 detects an error in reading the object OBq of the block Bq. That is, when the calculated hash value is not equal to the hash value Hq, the CPU 101 determines that an error has occurred in reading the object OBq of the block Bq. According to such a configuration, an error check can be realized without increasing the amount of calculation.
  • the storage 21 of the storage device 20 is a hierarchical storage composed of two types of storage having different access performance, for example, a high-speed storage and a low-speed storage, unlike the embodiment.
  • the metadata 410 of each object OBq may include the number of accesses (access count) to each object OBq.
  • the CPU 101 may function as a hierarchization management unit, and for example, an object whose access count exceeds a threshold value may be stored in the high-speed storage, and an object whose access count is less than the threshold value may be stored in the low-speed storage.
  • each object can be hierarchized according to the access count (that is, access frequency).
  • the object OBq is generally copied and recorded on a plurality of storage media, for example, a plurality of HDD disks constituting the storage 21.
  • the number of copies of the object OBq may be determined based on the duplication count DCNTq in the metadata 410 of the object OBq. That is, the CPU 101 may function as a duplication controller, and an object OBq having a larger value of the duplication count DCNTq may generate more duplicates of the object OBq. In this way, the access performance can be improved by increasing the number of duplicates of the object having many overlapping objects.
  • the storage 21 of the storage apparatus 20 is recognized as the object storage 210 by the file system 11. That is, the above embodiment is based on the case where the file system 11 has a configuration that uses object storage. For this reason, the host 10 requires the object controller 12.
  • the storage 21 of the storage apparatus 20 is recognized as a block storage from the file system 11. That is, this modification is based on the assumption that the file system 11 has a configuration that uses block storage but does not use object storage.
  • the CPU 101 of the file system 11 needs to store the block Bq in the block storage.
  • the CPU 101 functions as a file access controller, and a set of metadata (hereinafter referred to as block management metadata) corresponding to the metadata 410 of the object OBq of the block Bq and the contents of the block Bq (hereinafter referred to as meta).
  • Data block set) may be stored in the block storage.
  • the block management metadata includes a duplication count DCNTq, similar to the metadata 410 of the object OBq.
  • the CPU 101 determines an address indicating the write destination of the metadata block set, for example, the logical block address LBAq as follows.
  • the number of bits constituting the hash value Hq is 256.
  • the number of bits constituting the logical block address LBAq is 64. That is, the length of the hash value Hq is longer than the length of the logical block address LBAq. Therefore, the CPU 101 determines a predetermined 64-bit portion of the hash value Hq, for example, the first 64 bits as the logical block address LBAq.
  • the CPU 101 requests the storage controller 22 of the storage apparatus 20 to write the metadata block set based on the determined logical block address LBAq and the size SZq of the metadata block set. As a result, the CPU 101 can write the metadata block set in an area having a size SZq starting from the logical block address LBAq (an area in the block storage).
  • the operation of the storage controller 22 is the same as in the above embodiment.
  • the CPU 101 stores the hash value of the block Bq.
  • a recalculation operation (so-called re-hash operation) is executed. Specifically, the CPU 101 calculates a hash value Hq ′ of the hash value Hq based on the hash value Hq, and uses this hash value Hq ′ as the hash value of the block Bq. Note that the CPU 101 may add a constant value (for example, 1) to the hash value Hq and use the addition result as the hash value of the block Bq.
  • the CPU 101 determines that deduplication is necessary. In this case, the CPU 101 increments the duplication count DCNTq in the block management metadata of the metadata block set already stored in the LBAq area by one.
  • the storage used by the file system 11 is not an object storage but a general block storage, a function equivalent to the case of using the object storage can be realized regarding deduplication.
  • the host 10 uses the storage device 20 via the network 30.
  • a plurality of hosts including the host 10 may be connected to the network 30, and the plurality of hosts may use the storage apparatus 20 via the network 30.
  • a plurality of storage devices including the storage device 20 may be connected to the network 30, and the host 10 or the plurality of hosts may use the plurality of storage devices.
  • the host 10 (or a plurality of hosts) is connected to the storage apparatus 20 (a plurality of storage devices 20 via a connection means other than the network 30 such as a fiber channel (FC), a serial attached SCSI (SAS), or a serial AT attachment (SATA)). May also be used.
  • FC fiber channel
  • SAS serial attached SCSI
  • SATA serial AT attachment
  • the storage 21 and the storage controller 22 are provided independently from the host 10. However, the storage 21 and the storage controller 22 may be built in the host 10.
  • each of the file access controller, hash value calculation unit, file management unit, deduplication controller, file deletion controller, hierarchization management unit, and replication controller (functional elements) described above is stored by the CPU 101 of the file system 11. It is a software module realized by executing a control program. However, at least one of these functional elements may be realized by a hardware module.

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)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　実施形態によれば、ファイルシステムは、ハッシュ値算出部とアクセスコントローラと重複排除コントローラとを備える。前記ハッシュ値算出部は、ストレージに格納されるべきファイルを構成する少なくとも１つのデータブロックのハッシュ値を算出する。前記アクセスコントローラは、前記少なくとも１つのデータブロックが第１のデータブロックを含み、且つ前記第１のデータブロックの第１のキャッシュ値が算出された場合、前記第１のハッシュ値を識別子として用いて、前記第１のハッシュ値に基づいて決定される前記ストレージの第１のロケーションに、前記第１のデータブロックを格納する。前記重複排除コントローラは、前記第１のロケーションに有効なデータブロックが既に格納されている場合、前記第１のデータブロックが前記第１のロケーションに格納されるのを抑止する。

Description

ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム
　本発明の実施形態は、ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラムに関する。
　近年、ストレージ装置に格納されるべきデータの量は増大の一途をたどっている。このため、ストレージ装置の限られた記憶容量を有効に利用する技術が要求されている。このような技術の１つとして、重複排除技術が注目されている。重複排除技術によれば、同一内容のデータが重複してストレージ装置に格納されるのを防止する。
　重複排除技術は、一般に、重複排除を実行する主体の違いにより２つに大別される。第１の重複排除技術はファイルシステムで適用され、第２の重複排除技術はストレージ装置で適用される。第１の重複排除技術は、内容の一致するファイルの全体もしくは一部を、ストレージ装置の同一ロケーションに記録する手法として知られている。一方、第２の重複排除技術は、内容の一致するブロックを一つにまとめてストレージ装置内に格納し、異なるアクセスパスから同一のブロックを参照させる手法として知られている。
特開２００９－２５１７２５号公報 特開２０１２－９３８２７号公報
　第１の重複排除技術によれば、重複排除がファイルシステムによって実行されるため、ストレージ装置は重複排除のための特別な機能を必要としない。一方、第２の重複排除技術によれば、重複排除がストレージ装置（より詳細には、ストレージ装置のコントローラ）によって実行されるため、ファイルシステムは重複排除のための特別な機能を必要としない。
　しかし、第１の重複排除技術では、ファイルシステムにおいて重複排除のためのオーバヘッドが発生する。一方、第２の重複排除技術では、ストレージ装置において重複排除のためのオーバヘッドが発生する。しかも第２の重複排除技術では、ストレージ装置による重複の判定のために、全てのデータがファイルシステムによりストレージ装置に転送されることから、データ転送量は削減されない。
　本発明が解決しようとする課題は、重複排除に伴うオーバヘッドとデータ転送量とを減らすことができる、ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラムを提供することにある。
　実施形態によれば、ファイルシステムは、ハッシュ値算出部と、アクセスコントローラと、重複排除コントローラとを具備する。前記ハッシュ値算出部は、ストレージに格納されるべきファイルを構成する少なくとも１つのデータブロックのハッシュ値を算出する。前記アクセスコントローラは、前記少なくとも１つのデータブロックが第１のデータブロックを含み、且つ前記第１のデータブロックの第１のキャッシュ値が算出された場合、前記第１のハッシュ値を識別子として用いて、前記第１のハッシュ値に基づいて決定される前記ストレージの第１のロケーションに、前記第１のデータブロックを格納する。前記重複排除コントローラは、前記第１のロケーションに有効な第２のデータブロックが既に格納されている場合、前記第１のデータブロックが前記第１のロケーションに格納されるのを抑止する。
図１は、１つの実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。 図２は、図１に示されるファイルシステムの主要な機能の概要を説明するための図である。 図３は、同実施形態においてファイルを構成する複数のブロックの管理に用いられるｉノードの構造の例を示す図である。 図４は、同実施形態で適用される、ブロックのオブジェクトのデータ構造例を示す図である。 図５は、同実施形態で適用される、タイプがディレクトリの２つのｉノードの例を示す図である。 図６は、同実施形態で適用されるファイル書き込み処理の典型的な手順を示すフローチャートである。 図７は、同実施形態で適用されるファイル読み出し処理の典型的な手順を示すフローチャートである。 図８は、同実施形態で適用されるファイル削除処理の典型的な手順を示すフローチャートである。
　以下、種々の実施の形態につき図面を参照して説明する。　
　図１は、１つの実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。図１に示されるコンピュータシステムは、ホストコンピュータ（以下、ホストと称する）１０と、ストレージ装置２０とから構成される。本実施形態において、ホスト１０及びストレージ装置２０は、ネットワーク３０を介して接続されている。
　ホスト１０は、ファイルシステム１１及びオブジェクトコントローラ１２を備えている。本実施形態において、ファイルシステム１１及びオブジェクトコントローラ１２は、ＣＰＵ１０１、メモリ１０２及びローカルハードディスクドライブ（ＨＤＤ）１０３を含む共通のハードウェア構成を有している。しかし、ファイルシステム１１及びオブジェクトコントローラ１２が、それぞれ、ＣＰＵ、メモリ及びローカルＨＤＤを含む固有のハードウェア構成を有しても構わない。
　ＣＰＵ１０１は、ファイルシステムプログラム及びオブジェクト制御プログラムを例えば時分割で実行することにより、ファイルシステム１１及びオブジェクトコントローラ１２それぞれの主コントローラとして機能する。ファイルシステムプログラム及びオブジェクト制御プログラムは予めローカルＨＤＤ１０３に格納されている。本実施形態では、ホスト１０の起動時にＣＰＵ１０１によって実行されるイニシャルプログラムローダ（ＩＰＬ）に従って、上述の両プログラムの少なくとも一部がメモリ１０２にロードされて、当該ＣＰＵ１０１によって用いられる。図１では省略されているが、ＩＰＬは、フラッシュＲＯＭのような不揮発性メモリに予め格納されている。
　ストレージ装置２０は、ストレージ２１及びストレージコントローラ２２を備えている。本実施形態においてストレージ２１は、ＨＤＤアレイ、例えば複数のＨＤＤを用いて構成されるＲＡＩＤ（Redundant Arrays of Inexpensive DisksまたはRedundant Arrays of Independent Disks）アレイから構成される。なお、ストレージ２１が、複数のフラッシュメモリを用いて構成されるフラッシュアレイ（つまり、ＨＤＤアレイよりもアクセス速度が高速なフラッシュアレイ）であっても構わない。更にストレージ２１が、低速ストレージ（例えば、ＨＤＤアレイ）及び高速ストレージ（例えば、フラッシュアレイ）から構成される階層化ストレージであっても構わない。また、フラッシュアレイが、ＨＤＤとの互換性を有する複数のソリッドステートドライブ（ＳＳＤ）から構成されても構わない。更に、ストレージ２１が、必ずしもアレイ構造を有していなくても構わない。
　ストレージコントローラ２２は、ホスト１０（より詳細には、ホスト１０のオブジェクトコントローラ１２）からのアクセス要求を受けて、ストレージ２１にアクセスする。ストレージコントローラ２２はまた、ストレージ２１の領域をブロックと呼ばれる塊を単位に管理する。ストレージコントローラ２２は更に、各ブロックの論理アドレス（論理ブロックアドレス）と、当該論理ブロックアドレスに割り当てられる物理アドレスとの対応を管理する。
　次に、図１に示されるファイルシステム１１の主要な機能について、図２を参照して説明する。図２は、ファイルシステム１１の主要な機能の概要を説明するための図である。本実施形態においてストレージ装置２０のストレージ２１は、ファイルシステム１１からはオブジェクトストレージ２１０として認識されるものとする。オブジェクトストレージ２１０は一種の論理的なストレージであり、データ（例えば、ファイルのデータ）をオブジェクトを単位に格納するのに用いられる。本実施形態においてオブジェクトのサイズ（データ長）は可変長である。しかし、オブジェクトのサイズが固定長であっても構わない。
　図２は、ホスト１０上で動作するアプリケーションからファイルシステム１１に対して、ファイルＦをオブジェクトストレージ２１０に格納することが要求された場合を前提とする。この場合、ファイルシステム１１の主コントローラ（つまり、ＣＰＵ１０１）は、ファイルＦを、図２において矢印Ａ１で示されるように、複数のデータブロック、例えば４つのデータブロック（以下、単にブロックと称する）Ｂ１，Ｂ２，Ｂ３及びＢ４に分割する。本実施形態においてブロックＢ１乃至Ｂ４のサイズは、固定長であるものとする。しかし後述のように、ブロックのサイズが可変長であっても構わない。
　次にＣＰＵ１０１は、例えばＳＨＡ－２５６のような周知のハッシュ関数ＨＦを用いて、図２において矢印Ａ２で示されるように、ブロックＢ１，Ｂ２，Ｂ３及び至Ｂ４それぞれのハッシュ値Ｈ１，Ｈ２，Ｈ３及びＨ４を算出する。ハッシュ関数ＨＦがＳＨＡ－２５６である場合、ハッシュ値Ｈ１，Ｈ２，Ｈ３及びＨ４をそれぞれ構成するビットの数は２５６である。図２の例では、ハッシュ値Ｈ１，Ｈ２，Ｈ３及びＨ４は、それぞれ１２３４，３４５６，１２３４，及び５６２８である。つまり、ハッシュ値Ｈ１及びＨ３は同一である。
　ここで、ハッシュ値Ｈ１及びＨ３に対応するブロックＢ１及びＢ３の内容が異なっていると仮定する。この場合、ハッシュ値を構成するビットの数を本実施形態のように十分大きく取るならば、ブロックＢ１及びＢ３のハッシュ値が同一となるような、いわゆるハッシュ値の衝突の可能性を限りなくゼロに近づけることができる。つまり、ストレージ装置２０の故障や当該ストレージ装置２０内でのデータ化けが発生する可能性と比較して、ハッシュ値の衝突の可能性は無視できるほど小さくできる。そこでＣＰＵ１０１は、上述のようにハッシュ値Ｈ１及びＨ３が同一である場合、ブロックＢ１及びＢ３の内容は同一であり、データが重複していると判定する。
　ＣＰＵ１０１は、重複判定の結果に基づき、ハッシュ値Ｈ１（＝Ｈ３），Ｈ２及びＨ４をそれぞれ識別子（ＩＤ）として用いて、当該それぞれのＩＤに対応するブロックＢ１，Ｂ２及びＢ４を、図２において矢印Ａ３（より詳細には、矢印Ａ３１，Ａ３２及びＡ３４）に示されるように、オブジェクトストレージ２１０に格納する。このように、ブロックの格納にオブジェクトストレージが用いられる技術は、オブジェクトストレージ技術と呼ばれる。オブジェクトストレージ技術では、上述のＩＤ及びブロックは、それぞれ、オブジェクトＩＤ及びオブジェクトとして処理される。このオブジェクトは、ブロックに対応するオブジェクト、ブロックのオブジェクト、またはデータオブジェクトとも呼ばれる。本実施形態の特徴は、ＣＰＵ１０１が、ブロックのハッシュ値を、当該ブロックのオブジェクトを指し示すオブジェクトＩＤとして用いる点にある。
　さて、上述のブロック格納においてＣＰＵ１０１は重複排除のために、同一ＩＤ（オブジェクトＩＤ）に対応するブロックを同一オブジェクトとして扱う。つまり、ＣＰＵ１０１は、同一内容のブロックＢ１及びＢ３を重複してオブジェクトストレージ２１０に格納するのを抑止する。図２の例では、オブジェクトストレージ２１０へのブロックの格納が、ファイルＦの先頭のブロックＢ１から開始されるものとする。この場合、ＣＰＵ１０１は、ブロックＢ３をオブジェクトストレージ２１０に格納するのを抑止する。これにより、オブジェクトストレージ２１０内でのブロックＢ１及びＢ３の重複が排除される。
　次に、本実施形態で適用される、ファイルを構成するブロックを管理する仕組みについて説明する。本実施形態では、各ファイルは、Ｌｉｎｕｘ（登録商標）の仮想ファイルシステム（ＶＦＳ）の形式に従い、ｉノードを用いて管理される。
　図３は、本実施形態において、ファイルＦｐを構成するｍ個のブロックＢｑ（ｑ＝０，１，…，ｍ－１）の管理に用いられるｉノードｉＮｐの構造の例を示す。説明の簡略化のために、ブロックＢｑそれぞれのサイズは一定であり、例えば４キロバイト（ＫＢ）であるものとする。ｉノードｉＮｐも、１つのオブジェクト（つまり、ｉノードｉＮｐのオブジェクト）として管理される。図３において、ｉノードｉＮｐは、ブロック表３１０を含む。ｉノードｉＮｐは更に、ファイルＦｐの属性を表す属性情報３２０を含む。ファイルＦｐの属性情報３２０は、ファイルＦｐのメタデータとも呼ばれる。ファイルＦｐの属性は、当該ファイルＦｐのサイズ、当該ファイルＦｐへのアクセスの権限、及びタイムスタンプを含む。タイムスタンプは、ファイルＦｐが最後にアクセスされた日時、ファイルＦｐが最後に変更された日時、及びファイルＦｐが作成された日時を含む。
　ブロック表３１０は、ブロックＢｑのロケーションを示す情報（以下、ブロックロケーション情報と称する）を記録するのに用いられる。従来技術では、ブロックロケーション情報としてブロックＢｑのアドレスが用いられる。これに対して本実施形態では、ブロックロケーション情報としてブロックＢｑのハッシュ値Ｈｑが用いられる。
　このため、本実施形態においてブロックＢｑは、当該ブロックＢｑのハッシュ値ＨｑをオブジェクトＩＤとして一意に決定される、オブジェクトストレージ２１０のロケーションに論理的に格納される。つまり本実施形態では、ブロックＢｑのハッシュ値Ｈｑが、当該ブロックＢｑのオブジェクトＯＢｑのオブジェクトＩＤとして用いられる。これにより、ブロックＢｑのオブジェクトＯＢｑは、当該オブジェクトＯＢｑのオブジェクトＩＤ（＝当該ブロックＢｑのハッシュ値Ｈｑ）によって一意に決定されるロケーションに論理的に格納される。
　さて本実施形態では、ストレージ２１の物理記憶領域の少なくとも一部（以下、物理ボリュームと称する）は、一定サイズの小領域を単位に、ホスト１０によって認識される論理ボリュームにマッピングされる。そのためストレージコントローラ２２は、論理ボリューム内の小領域の論理アドレス（例えば、論理ブロックアドレス）と物理ボリューム内の小領域の物理アドレスとの対応を、アドレス管理テーブルを用いて管理する。
　また本実施形態では、オブジェクトＯＢｑのオブジェクトストレージ２１０におけるロケーションは、論理ボリューム内の小領域列にマッピングされる。上述のように、このロケーションは、オブジェクトＯＢｑのオブジェクトＩＤによって指し示される。そのためオブジェクトコントローラ１２は、オブジェクトＯＢｑのオブジェクトＩＤと論理ボリューム内の小領域列の先頭小領域の論理ブロックアドレスＬＢＡｑとの対応を、オブジェクト管理テーブルを用いて管理する。オブジェクト管理テーブルは、例えばホスト１０のローカルＨＤＤ１０３に格納されている。論理ブロックアドレスＬＢＡｑを構成するビットの数は６４であるものとする。
　ファイルシステム１１は、ブロックＢｑのオブジェクトＯＢｑの読み出し（または書き込み）を、オブジェクトコントローラ１２を介して次のように実行する。まずファイルシステム１１は、ブロックＢｑのハッシュ値Ｈｑを、当該ブロックＢｑのオブジェクトＯＢｑを指し示すオブジェクトＩＤとして用いて、当該オブジェクトＯＢｑの読み出し（または書き込み）をオブジェクトコントローラ１２に要求する。この要求に応じて、オブジェクトコントローラ１２は、ハッシュ値Ｈｑ（オブジェクトＩＤ）で一意に決定されるオブジェクトストレージ２１０のロケーションから（またはロケーションに）、オブジェクトＯＢｑを論理的に読み出す（または書き込む）。
　但し、オブジェクトＯＢｑ（より詳細には、オブジェクトＯＢｑの内容）は、物理的には、ストレージ装置２０のストレージ２１から読み出される（またはストレージ２１に書き込まれる）必要がある。そこで、この物理的な読み出し（または書き込み）のために、オブジェクトコントローラ１２は、ブロックＢｑのオブジェクトＯＢｑのオブジェクトＩＤ（つまり、ブロックＢｑのハッシュ値Ｈｑ）に基づいてオブジェクト管理テーブルを参照する。これによりオブジェクトコントローラ１２は、オブジェクトＯＢｑのオブジェクトＩＤに対応付けられた論理ブロックアドレスＬＢＡｑを取得する。そしてオブジェクトコントローラ１２は、取得された論理ブロックアドレスＬＢＡｑとオブジェクトＯＢｑのサイズとに基づいて、当該オブジェクトＯＢｑの内容の読み出し（または書き込み）を、ストレージ装置２０のストレージコントローラ２２に要求する。
　ストレージコントローラ２２はオブジェクトコントローラ１２からの要求に応じ、論理ブロックアドレスＬＢＡｑに基づいてアドレス管理テーブルを参照する。これによりストレージコントローラ２２は、論理ブロックアドレスＬＢＡｑに対応付けられた物理アドレスを取得する。そしてストレージコントローラ２２は、取得された物理アドレスとオブジェクトＯＢｑのサイズとで示される、ストレージ２１内のロケーションから（またはロケーションに）、当該オブジェクトＯＢｑの内容を読み出す（または書き込む）。以降の説明では、簡略化のために、オブジェクトの物理的な読み出しまたは書き込みに関する記載は省略する。
　本実施形態において、ｉノードｉＮｐ（より詳細には、ｉノードｉＮｐのオブジェクト）のサイズは可変長であるものとする。このため本実施形態では、ファイルＦｐを構成する全てのブロックＢｑ（Ｂ０乃至Ｂｍ－１）のハッシュ値をｉノードｉＮｐのブロック表３１０に記録することが可能である。つまり図３では、例えばブロックＢ０，Ｂ１，…，Ｂｍ－２，Ｂｍ－１それぞれのハッシュ値Ｈ０，Ｈ１，…，Ｈｍ－２，Ｈｍ－１は、ブロック表３１０に記録される。この場合、ブロックＢ０，Ｂ１，…，Ｂｍ－２，Ｂｍ－１は、ブロック表３１０に記録されているハッシュ値Ｈ０，Ｈ１，…，Ｈｍ－２，Ｈｍ－１をＩＤとして決定されるロケーションに直接格納される。
　なお、ｉノードｉＮｐのサイズが固定長であつても構わない。ここで、ファイルＦｐを構成するブロックＢｑの数をＮｐ、ブロック表３１０に記録可能なハッシュ値の数をＮｑと表記するものとする。まず、Ｎｐ≦Ｎｑであるならば、ＣＰＵ１０１は、全てのブロックＢｑを、ブロック表３１０を用いて直接管理することができる。これに対してＮｐ＞Ｎｑであるならば、ＣＰＵ１０１は、一部のブロックＢｑを、周知の間接ブロックを用いて管理すれば良い。ここで、ブロックＢｎ及びＢｎ＋１のハッシュ値Ｈｎ及びＨｎ＋１が間接ブロックＩＢｘを用いて管理されるものとする。この場合、ブロックＢｎ及びＢｎ＋１のハッシュ値Ｈｎ及びＨｎ＋１は、間接ブロックＩＢｘに記録され、ブロック表３１０には当該間接ブロックＩＢｘのハッシュ値Ｈｘが記録される。なお、従来技術では、ブロックＢｎ及びＢｎ＋１のアドレスが間接ブロックＩＢｘに記録され、当該間接ブロックＩＢｘのアドレスがブロック表３１０に記録される。
　もし、間接ブロックＩＢｘを用いても、ｉノードｉＮｐのブロック表３１０で全てのブロックＢｑを管理できない場合、ＣＰＵ１０１は、例えば２段間接ブロック、或いは３段間接ブロックを利用すれば良い。この場合、ＣＰＵ１０１は、２段間接ブロック、或いは３段間接ブロックに、次段の間接ブロックのアドレスではなくて、次段の間接ブロックのハッシュ値を記録する。
　図４は、本実施形態で適用される、上述のブロックＢｑのオブジェクトＯＢｑのデータ構造例を示す。オブジェクトＯＢｑは、オブジェクトストレージ２１０内のデータ領域に格納される。本実施形態では、データ領域は、ファイルシステム１１に割り当てられており、当該ファイルシステム１１により使用される。ホスト１０がファイルシステム１１を含む複数のファイルシステムを備えている場合、データ領域が、当該複数のファイルシステムにより共有されても良い。
　なお、オブジェクトストレージ２１０内に複数のデータ領域、例えば、第１及び第２のデータ領域が用意されても良い。ここで、第１のファイルシステム（または、第１のファイルシステムの集合）が第１のデータ領域を利用し、第２のファイルシステム（または、第２のファイルシステムの集合）が第２のデータ領域を利用するものとする。また、第１のデータ領域に格納されるべき第１のオブジェクトのハッシュ値が、第２のデータ領域に既に格納されている第２のオブジェクトのハッシュ値と同一であるものとする。この場合、第１のファイルシステム（または各第１のファイルシステム）は、同一のハッシュ値であっても、第１のオブジェクトを第２のオブジェクトとは別のオブジェクトとして処理する。つまり、第２のオブジェクトが存在しても、第１のオブジェクトは重複排除の対象から外される。
　一方、例えば、図３に示されるｉノードｉＮｐは、ｉノードオブジェクトとも呼ばれ、オブジェクトストレージ２１０内のｉノード領域に格納される。本実施形態では、ｉノード領域は、ファイルシステム１１に割り当てられており、当該ファイルシステム１１により使用される。ホスト１０がファイルシステム１１を含む複数のファイルシステムを備えている場合、当該複数のファイルシステムによりそれぞれ個別のｉノード領域が使用されても良い。
　オブジェクトＯＢｑは、メタデータ４１０と実データ４２０とから構成される。オブジェクトＯＢｑの実データ４２０は、当該オブジェクトＯＢｑの実体である。オブジェクトＯＢｑが本実施形態のようにファイルＦｐのブロックＢｑに対応する場合、実データ４２０は、当該ブロックＢｑの内容に一致する。
　一方、オブジェクトＯＢｑのメタデータ４１０は、当該オブジェクトＯＢｑに関する管理情報を示し、重複カウントＤＣＮＴｑを含む。重複カウントＤＣＮＴｑは参照カウントとも呼ばれ、実データ４２０に一致するブロックＢｑの数を示す。つまり重複カウントＤＣＮＴｑは、実データ４２０（ブロックＢｑ）のハッシュ値Ｈｑと同一のハッシュ値を持つブロックの数を示す。メタデータ４１０は更に、オブジェクトＯＢｑに固有のオブジェクトＩＤ、実データ４２０のサイズを示す情報、及び実データ４２０の格納先を示すアドレス（例えば、論理ブロックアドレス）を含む。オブジェクトＯＢｑのオブジェクトＩＤには、当該オブジェクトＯＢｑに対応するブロックＢｑのハッシュ値Ｈｑが用いられる。
　ｉノードは、一般に複数のタイプに分類される。ｉノードの代表的なタイプとして、ファイル（より詳細には、通常ファイル）、及びディレクトリが知られている。タイプがファイルのｉノードは、ファイルを管理するのに用いられる。図３に示されるｉノードｉＮｐのタイプは、ファイルである。以下の説明では、タイプがファイルのｉノードがファイルｉノードと表記され、タイプがディレクトリのｉノードがディレクトリｉノードと表記されることもある。ｉノードは、当該ｉノードのタイプに無関係に、当該ｉノードに固有のｉノード番号を持つ。ｉノード（つまり、ｉノードオブジェクト）のｉノード番号は、当該ｉノードオブジェクトのオブジェクトＩＤとして用いられる。
　図５は、本実施形態で適用される、タイプがディレクトリのｉノード５００の例を示す。ｉノード５００のサイズは、ｉノードｉＮｐのそれと同様に可変長であるものとする。ｉノード５００も、１つのオブジェクト（つまり、ｉノード５００のオブジェクト）として管理される。このため、ｉノード５００がｉノードオブジェクト５００と表記されることもある。ｉノード５００は、例えばｉノード番号ｉＮｄｎを持ち、ディレクトリエントリ表（以下、エントリ表と称する）５１０及び属性情報５２０を含む。エントリ表５１０は、ｉノード５００が指し示すディレクトリに含まれる全てのファイルの、ｉノード番号及びファイル名の組を記録するのに用いられる。ファイルが新規に作成される場合、当該ファイルが対応するｉノードのｉノード番号及び当該ファイルのファイル名の組が、ファイルシステム１１によって、例えばｉノード５００のエントリ表５１０の空きエントリに追加される。
　なお、ファイルは通常のファイルではなく、ディレクトリであっても構わない。この場合、タイプがディレクトリのｉノード番号とディレクトリ名とをエントリ表５１０に記録する。また、ｉノード（ディレクトリｉノード）５００のサイズが固定長であっても構わない。この場合、ファイルシステム１１（ＣＰＵ１０１）は、ｉノード５００のエントリ表５１０に保持されるべきｉノード番号及びファイル名の組の集合を別の複数のオブジェクトに分散して記録し、当該別の複数のオブジェクトのＩＤ（つまり、ディレクトリエントリのリスト）をｉノード５００に記録しても良い。
　ファイルシステム１１は、当該ファイルシステム１１の管理に特別のブロックを利用する。この特別のブロックは、スーパーブロックと呼ばれ、ファイルシステム１１が生成された際に生成される。スーパーブロックは、ファイルシステム１１の管理情報（以下、ファイルシステム管理情報と称する）を記録するのに用いられ、例えば、オブジェクトストレージ２１０内の、ｉノード領域に格納される。スーパーブロックも、オブジェクトとして管理される。このため、スーパーブロックには、特別のオブジェクトＩＤが割り当てられる。
　ファイルシステム管理情報は、ｉノードリスト情報を含む。ｉノードリスト情報は、オブジェクトストレージ２１０のｉノード領域内に予め確保されるｉノード毎の格納先に関する情報（以下、ｉノード管理情報と称する）を含む。ｉノード管理情報は、対応するｉノードに固有のｉノード番号を含む。ファイルシステム１１は、ファイルシステム管理情報に含まれているｉノード管理情報を参照することにより、目的のｉノード番号をＩＤとして持つｉノードを特定することができる。
　次に、本実施形態の動作について説明する。まず、ファイルシステム１１のＣＰＵ１０１によって実行されるファイル書き込み処理について、ファイルＦｐの書き込みを例に、図６を参照して説明する。図６は、本実施形態で適用されるファイル書き込み処理の典型的な手順を示すフローチャートである。ここでは説明の簡略化のために、ファイルＦｐのサイズは、４ＫＢの整数倍であるものとする。
　今、ホスト１０内で実行されるアプリケーションプログラムからファイルシステム１１に対して、ファイルＦｐの書き込みが要求されたものとする。するとファイルシステム１１のＣＰＵ１０１は、ファイル書き込み処理を開始する。まずＣＰＵ１０１はファイルアクセスコントローラとして機能して、ファイルＦｐを、例えば４ＫＢのサイズを有する複数のブロックＢｑ（ｑ＝０，１，…）に分割する（ステップＳ１）。複数のブロックＢｑは、例えばメモリ１０２に格納される。ここでは、ブロックＢｑの数がｍであるものとする。
　次にＣＰＵ１０１は、変数ｑ及びＱを、それぞれ０及びｍに初期設定する（ステップＳ２）。変数ｑは、ファイルＦｐにおけるブロックＢｑの相対位置を示す。変数Ｑは、分割されたブロックＢｑの数を示す。次にＣＰＵ１０１は、変数ｑ（＝０）で示されるブロックＢｑ（第１のブロック）をローカルＨＤＤ１０３から選択して、当該選択されたブロックＢｑをメモリ１０２のワーク領域に格納する。そしてＣＰＵ１０１はハッシュ値算出部として機能して、メモリ１０２のワーク領域に格納されたブロックＢｑの内容のハッシュ値Ｈｑを算出する（ステップＳ３）。するとＣＰＵ１０１は、ステップＳ４に進む。
　ステップＳ４においてＣＰＵ１０１はファイル管理部として機能して、算出されたハッシュ値Ｈｑを、ファイルＦｐのファイル名と対応付けられたｉノード番号ｉＮｐｎを持つｉノードｉＮｐのブロック表３１０に、以下に述べるように記録する。まずＣＰＵ１０１は、ファイルＦｐのファイル名に基づいて、ｉノード５００ａのエントリ表５１０ａを参照する。これによりＣＰＵ１０１は、ファイルＦｐのファイル名と対応付けられたｉノード番号ｉＮｐｎを取得する。即ちＣＰＵ１０１は、ファイルＦｐのファイル名と対応付けられたｉノード番号ｉＮｐｎを、ｉノード５００ａのエントリ表５１０ａから探索する。
　次にＣＰＵ１０１は、探索されたｉノード番号ｉＮｐｎをＩＤとして用いることにより、当該ｉノード番号ｉＮｐｎを持つｉノードｉＮｐを、オブジェクトストレージ２１０のｉノード領域から、オブジェクトコントローラ１２を介して読み出す。ＣＰＵ１０１は、読み出されたｉノードｉＮｐをメモリ１０２のワーク領域に格納する。そしてＣＰＵ１０１は、メモリ１０２のワーク領域に格納されたｉノードｉＮｐのブロック表３１０に、ブロックＢｑのハッシュ値Ｈｑを記録する。
　次にＣＰＵ１０１は重複排除コントローラとして機能する。そしてＣＰＵ１０１は、ブロックＢｑのハッシュ値ＨｑをオブジェクトＩＤとして用いて、当該オブジェクトＩＤと同一のオブジェクトＩＤを持つオブジェクトＯＢｑの存在を次のように確認する（ステップＳ５）。即ちＣＰＵ１０１は、ブロックＢｑのハッシュ値ＨｑをオブジェクトＩＤとして用いて、当該ハッシュ値Ｈｑで一意に決まるオブジェクトストレージ２１０内のロケーションからのオブジェクトの読み出しを、オブジェクトコントローラ１２を介して実行する。そしてＣＰＵ１０１は、上述のロケーションに有効なオブジェクトが格納されていることを条件に、目的のオブジェクトＯＢｑが存在することを確認する。
　次にＣＰＵ１０１は、目的のオブジェクトＯＢｑの確認の結果を判定する。即ちＣＰＵ１０１は、目的のオブジェクトＯＢｑが上述のロケーションに存在するかを判定する（ステップＳ６）。ここでは、目的のオブジェクトＯＢｑが上述のロケーションに存在しないものとする（ステップＳ６のＮｏ）。つまり、ブロックＢｑのハッシュ値Ｈｑで一意に決まるロケーション（第１のロケーション）に、当該ブロックＢｑと同一内容の有効なブロックが存在しないものとする。この場合、ＣＰＵ１０１は、ファイルシステム１１によって利用されるオブジェクトストレージ２１０内のデータ領域に格納されているブロックのいずれともブロックＢｑが重複しておらず、したがってブロックＢｑに関する重複排除は不要であると判断する。
　するとＣＰＵ１０１は再びファイルアクセスコントローラとして機能する。そしてＣＰＵ１０１は、ブロックＢｑ（第１のブロック）を、ハッシュ値ＨｑをオブジェクトＩＤとして持つオブジェクトＯＢｑとして、上述のロケーションに書き込む（ステップＳ７）。この書き込みは、ＣＰＵ１０１からオブジェクトコントローラ１２にオブジェクトＯＢｑの書き込みを要求することにより、当該オブジェクトコントローラ１２によって実行される。
　オブジェクトＯＢｑは、図４に示されるように、メタデータ４１０と実データ４２０とを含む。メタデータ４１０は、ハッシュ値Ｈｑに一致するオブジェクトＩＤを含む。オブジェクトＯＢｑのメタデータ４１０は更に、値が０（初期値）の重複カウントＤＣＮＴｑを含む。実データ４２０は、ブロックＢｑの内容に一致する。ＣＰＵ１０１は、ステップＳ７を実行すると重複排除コントローラとして機能して、ステップＳ８に進む。
　一方、上述の例とは異なって、目的のオブジェクトＯＢｑ（より詳細には、ブロックＢｑと同一内容のブロックを持つオブジェクト）が上述のロケーションに存在するものとする（ステップＳ６のＹｅｓ）。つまり、ブロックＢｑのハッシュ値Ｈｑで一意に決まるロケーションに、当該ブロックＢｑと同一内容の有効なブロック（第２のブロック）が既に存在しているものとする。この場合、ＣＰＵ１０１は、ブロックＢｑが、上述のロケーションに存在する有効なブロックと重複しており、したがってブロックＢｑに関する重複排除が必要であると判断する。そこでＣＰＵ１０１は重複排除コントローラとして機能して、重複排除のためにステップＳ７をスキップし、しかる後にステップＳ８に進む。即ちＣＰＵ１０１は、ブロックＢｑがオブジェクトＯＢｑとして上述のロケーションに書き込まれるのを、重複排除のために抑止して、ステップＳ８に進む。
　ステップＳ８においてＣＰＵ１０１は、オブジェクトＯＢｑのメタデータ４１０中の重複カウントＤＣＮＴｑを１増加する。これにより、目的のオブジェクトＯＢｑが存在しないと判定された場合であるならば（ステップＳ６のＮｏ）、重複カウントＤＣＮＴｑは初期値０から１に更新される。重複カウントＤＣＮＴｑ＝１は、オブジェクトＯＢｑの実データ４２０に一致するブロックＢｑの数が１であることを示す。これに対し、目的のオブジェクトＯＢｑ存在すると判定された場合であるならば（ステップＳ６のＹｅｓ）、重複カウントＤＣＮＴｑは１以上の整数であることから、当該重複カウントＤＣＮＴｑは２以上の値に更新される。
　次にＣＰＵ１０１はファイルアクセスコントローラとして機能して、変数ｑを１増加する（ステップＳ９）。そしてＣＰＵ１０１は、１増加された変数ｑが変数Ｑ（＝ｍ）に等しいかを判定する（ステップＳ１０）。もし、１増加された変数ｑが変数Ｑに等しくないならば（ステップＳ１０のＮｏ）、ＣＰＵ１０１は、処理されるべきブロックＢｑが残っていると判断する。この場合、ＣＰＵ１０１はステップＳ３に戻る。そしてＣＰＵ１０１は、ステップＳ３乃至Ｓ１０、またはステップＳ３乃至Ｓ６及びＳ８乃至Ｓ１０を、前述の場合と同様に実行する。なお、ステップＳ１０において、１増加された変数ｑが、変数Ｑ以上であるか、或いはＱ－１を超えているかを判定しても構わない。
　さて、ＣＰＵ１０１が上述の動作をＱ（＝ｍ）回繰り返すと、１増加された変数ｑが変数Ｑに等しくなる（ステップＳ１０のＹｅｓ）。この場合、ＣＰＵ１０１は、処理されるべきブロックＢｑは残っていないと判断する。すると、ＣＰＵ１０１はステップＳ１１に進む。
　ステップＳ１１においてＣＰＵ１０１はファイル管理部として機能して、メモリ１０２のワーク領域に格納されているｉノードｉＮｐに、ファイルＦｐの新たな属性情報３２０を記録する。即ちＣＰＵ１０１は、ｉノードｉＮｐの旧属性情報３２０を新たな属性情報３２０に更新する。
　次にＣＰＵ１０１は、新たなブロック表３１０及び属性情報３２０を含む新たなｉノードｉＮｐを、ｉノード番号ｉＮｐｎをＩＤとして持つオブジェクトＯｉＮｐとして、オブジェクトストレージ２１０内のｉノード領域に書き込む（ステップＳ１２）。即ちＣＰＵ１０１は、旧ｉノードｉＮｐ（旧オブジェクトＯｉＮｐ）を新たなｉノードｉＮｐ（新たなオブジェクトＯｉＮｐ）に更新する。これにより、ファイル書き込み処理は終了する。なお、ステップＳ１２におけるオブジェクトＯｉＮｐの書き込みは、ＣＰＵ１０１からオブジェクトコントローラ１２にオブジェクトＯｉＮｐの書き込みを要求することにより、当該オブジェクトコントローラ１２によって実行される。
　次に、ファイルシステム１１のＣＰＵ１０１によって実行されるファイル読み出し処理について、ファイルＦｐの読み出しを例に、図７を参照して説明する。図７は、本実施形態で適用されるファイル読み出し処理の典型的な手順を示すフローチャートである。
　今、アプリケーションプログラムからファイルシステム１１に対して、ファイルＦｐの読み出しが要求されたものとする。するとファイルシステム１１のＣＰＵ１０１は、ファイル読み出し処理を開始する。まずＣＰＵ１０１はファイルアクセスコントローラとして機能して、ファイルＦｐに対応付けられたｉノード番号ｉＮｐｎをＩＤとして用いて、ｉノードｉＮｐのオブジェクトＯｉＮｐをオブジェクトストレージ２１０から読み出す（ステップＳ２１）。この読み出しは、ＣＰＵ１０１からオブジェクトコントローラ１２にオブジェクトＯｉＮｐの読み出しを要求することにより、当該オブジェクトコントローラ１２によって実行される。
　読み出されたｉノードｉＮｐのオブジェクトＯｉＮｐは、メモリ１０２のワーク領域に格納される。ｉノード番号ｉＮｐｎは、前述のファイル書き込み処理と同様に、ＣＰＵ１０１が、ファイルＦｐのファイル名に基づいて、ｉノード５００ａのエントリ表５１０ａを参照することにより取得される。
　次にＣＰＵ１０１は、読み出されたオブジェクトＯｉＮｐに含まれているｉノードｉＮｐのブロック表３１０から、未だ選択されていないブロックＢｑのハッシュ値Ｈｑを選択する（ステップＳ２２）。ここでは、ブロック表３１０のｑ（＝０）番目のエントリから、ブロックＢｑのハッシュ値Ｈｑが選択される。
　次にＣＰＵ１０１は、選択されたハッシュ値Ｈｑを、オブジェクトＩＤとして用いて、ブロックＢｑのオブジェクトＯＢｑをオブジェクトストレージ２１０から読み出す（ステップＳ２３）。即ちＣＰＵ１０１は、選択されたハッシュ値ＨｑをオブジェクトＩＤとして持つオブジェクトＯＢｑを読み出す。読み出されたオブジェクトＯＢｑは、メモリ１０２のワーク領域に格納される。
　次にＣＰＵ１０１は、ステップＳ２１において読み出されたオブジェクトＯｉＮｐに含まれているｉノードｉＮｐのブロック表３１０に記録された全てのハッシュ値Ｈｑが選択されたかを判定する（ステップＳ２４）。もし、未だ選択されていないハッシュ値ＨｑがｉノードｉＮｐのブロック表３１０に存在するならば（ステップＳ２４のＮｏ）、ＣＰＵ１０１はステップＳ２２に戻る。そしてＣＰＵ１０１は、ステップＳ２２乃至Ｓ２４を、前述の場合と同様に実行する。
　さて、ｉノードｉＮｐのブロック表３１０に記録されている全てのハッシュ値Ｈｑについて、ステップＳ２２乃至Ｓ２４が繰り返し実行されたものとする（ステップＳ２４のＹｅｓ）。この場合、ＣＰＵ１０１はステップＳ２５に進む。
　ステップＳ２５においてＣＰＵ１０１はファイル管理部として機能して、メモリ１０２のワーク領域に格納されたオブジェクトＯｉＮｐに含まれているｉノードｉＮｐに、ファイルＦｐの新たな属性情報３２０を記録する。即ちＣＰＵ１０１は、ｉノードｉＮｐの旧属性情報３２０を新たな属性情報３２０に更新する。
　次にＣＰＵ１０１は、新たなブロック表３１０及び属性情報３２０を含む新たなｉノードｉＮｐを、ｉノード番号ｉＮｐｎをＩＤとして持つオブジェクトＯｉＮｐとして、オブジェクトストレージ２１０内のｉノード領域にオブジェクトコントローラ１２を介して書き込む（ステップＳ２６）。これにより、旧ｉノードｉＮｐ（旧オブジェクトＯｉＮｐ）は新たなｉノードｉＮｐ（新たなオブジェクトＯｉＮｐ）に更新され、ファイル読み出し処理は終了する。
　次に、ファイルシステム１１のＣＰＵ１０１によって実行されるファイル削除処理について、ファイルＦｐの削除を例に、図８を参照して説明する。図８は、本実施形態で適用されるファイル削除処理の典型的な手順を示すフローチャートである。
　今、アプリケーションプログラムからファイルシステム１１に対して、ファイルＦｐの削除が要求されたものとする。するとファイルシステム１１のＣＰＵ１０１は、ファイル削除処理を開始する。まずＣＰＵ１０１はファイルアクセスコントローラとして機能して、ファイルＦｐに対応付けられたｉノード番号ｉＮｐｎをＩＤとして用いて、ｉノードｉＮｐのオブジェクトＯｉＮｐをオブジェクトストレージ２１０から読み出す（ステップＳ３１）。読み出されたｉノードｉＮｐのオブジェクトＯｉＮｐは、メモリ１０２のワーク領域に格納される。
　次にＣＰＵ１０１は、読み出されたオブジェクトＯｉＮｐに含まれているｉノードｉＮｐのブロック表３１０から、未だ選択されていないブロックＢｑのハッシュ値Ｈｑを選択する（ステップＳ３２）。ここでは、ブロック表３１０のｑ（＝０）番目のエントリから、ブロックＢｑのハッシュ値Ｈｑが選択される。
　次にＣＰＵ１０１は、選択されたハッシュ値Ｈｑを、オブジェクトＩＤとして用いて、ブロックＢｑのオブジェクトＯＢｑのメタデータ４１０をオブジェクトストレージ２１０から読み出す（ステップＳ３３）。読み出されたオブジェクトＯＢｑのメタデータ４１０は、メモリ１０２のワーク領域に格納される。
　次にＣＰＵ１０１はファイル削除コントローラとして機能して、ステップＳ３３において読み出されたオブジェクトＯＢｑに含まれているメタデータ４１０中の重複カウントＤＣＮＴｑを１減らす（ステップＳ３４）。そしてＣＰＵ１０１は、１減らされた重複カウントＤＣＮＴｑが０に等しいかを判定する（ステップＳ３５）。
　もし、１減らされた重複カウントＤＣＮＴｑが０に等しいならば（ステップＳ３５のＹｅｓ）、ＣＰＵ１０１は、オブジェクトＯＢｑに含まれている実データ４２０に一致するブロックＢｑの数が、今回のファイルＦｐの削除でゼロになると判断する。この場合、ＣＰＵ１０１は、オブジェクトストレージ２１０からオブジェクトＯＢｑを削除する（ステップＳ３６）。そしてＣＰＵ１０１は、ステップＳ３７に進む。
　これに対し、１減らされた重複カウントＤＣＮＴｑが０に等しくないならば（ステップＳ３５のＮｏ）、ＣＰＵ１０１は、オブジェクトＯＢｑに含まれている実データ４２０に一致するブロックＢｑの数は、今回のファイルＦｐの削除でもゼロにならないと判断する。この場合、ＣＰＵ１０１はステップＳ３６をスキップして、ステップＳ３７に進む。
　ステップＳ３７においてＣＰＵ１０１は、上述のファイル読み出し処理におけるステップＳ２４と同様に、読み出されたオブジェクトＯｉＮｐに含まれているｉノードｉＮｐのブロック表３１０に記録された全てのハッシュ値Ｈｑが選択されたかを判定する。もし、未だ選択されていないハッシュ値ＨｑがｉノードｉＮｐのブロック表３１０に存在するならば（ステップＳ３７のＮｏ）、ＣＰＵ１０１はステップＳ３２に戻る。そしてＣＰＵ１０１は、ステップＳ３２乃至Ｓ３７、またはステップＳ３２乃至３５及びＳ３７を、前述の場合と同様に実行する。
　さて、ｉノードｉＮｐのブロック表３１０に記録されている全てのハッシュ値Ｈｑについて、ステップＳ３２乃至Ｓ３７、またはステップＳ３２乃至３５及びＳ３が繰り返し実行されたものとする（ステップＳ３７のＹｅｓ）。この場合、ＣＰＵ１０１は、オブジェクトストレージ２１０からオブジェクトＯｉＮｐを削除する（ステップＳ３８）。なお、ステップＳ３８におけるオブジェクトＯｉＮｐの削除は、ＣＰＵ１０１からオブジェクトコントローラ１２に当該オブジェクトＯｉＮｐの削除を要求することにより、当該オブジェクトコントローラ１２によって実行される。
　次にＣＰＵ１０１は、ｉノード（ディレクトリｉノード）５００ａのｉノード番号ｉＮｄｎをＩＤとして用いて、当該ｉノード（ｉノードオブジェクト）５００ａを読み出す（Ｓ３９）。読み出されたｉノード５００ａはメモリ１０２のワーク領域に格納される。
　次にＣＰＵ１０１は、ステップＳ３９において読み出されたｉノード５００ａのエントリ表５１０ａから、ｉノード番号ｉＮｐｎとファイルＦｐのファイル名との組を削除する（ステップＳ４０）。ＣＰＵ１０１は、ｉノード番号ｉＮｐｎとファイルＦｐのファイル名との組が削除されたエントリ表５１０ａを含むｉノード５００ａを、当該ｉノード５００ａのｉノード番号ｉＮｄｎをＩＤとして持つオブジェクトとして、オブジェクトストレージ２１０内のｉノード領域に書き込む（ステップＳ４１）。これにより、ファイル削除処理は終了する。
　次に、本実施形態で適用される周知のファイル作成処理について簡単に説明する。今、ホスト１０上で動作するアプリケーションからファイルシステム１１に対して、ファイルＦｐを新規に作成することが要求されたものとする。この場合、ファイルシステム１１のＣＰＵ１０１はファイル管理部として機能して、未使用のｉノード番号を取得する。ここでは、ｉノード番号ｉＮｐｎが取得されたものとする。
　次にＣＰＵ１０１は、メモリ１０２のワーク領域内にファイルｉノードｉＮｐを作成し、当該ファイルｉノードｉＮｐにファイルＦｐの属性情報を記録する。ＣＰＵ１０１は、ファイルＦｐの属性情報が記録されたファイルｉノードｉＮｐを、ｉノード番号ｉＮｐｎをＩＤとして用いて、オブジェクトストレージ２１０のｉノード領域に書き込む。
　次にＣＰＵ１０１は、ｉノード（ディレクトリｉノード）５００ａのｉノード番号ｉＮｄｎをＩＤとして用いて、当該ｉノード（ｉノードオブジェクト）５００ａを読み出す。ＣＰＵ１０１は、読み出されたｉノード５００ａのエントリ表５１０に、ｉノード番号ｉＮｐｎとファイルＦｐのファイル名との組を追加する。ＣＰＵ１０１は、ｉノード番号ｉＮｐｎとファイルＦｐのファイル名との組が追加されたエントリ表５１０ａを含むｉノード５００ａを、ｉノード番号ｉＮｄｎをＩＤとして持つオブジェクトとして、オブジェクトストレージ２１０内のｉノード領域に書き込む。これにより、ファイル作成処理は終了する。
　上述のように、本実施形態においてファイルシステム１１は、オブジェクトストレージ２１０に書き込まれるべきブロックの内容（つまり、データ）から算出された当該ブロックのハッシュ値をＩＤ（オブジェクトＩＤ）として用いて、当該ブロックのロケーションを決定（または特定）する。そこでファイルシステム１１は、例えばブロックＢｑをオブジェクトストレージ２１０に書き込む必要がある場合に、当該ブロックＢｑのハッシュ値ＨｑをＩＤとして用いて上述のロケーションにアクセスする。このアクセスだけで、ファイルシステム１１は、ハッシュ値Ｈｑと同一のＩＤを持つブロックが既にストレージ装置２０に格納されているかを簡単に判定することができる。つまり、上述のロケーションに有効なブロックが格納されている場合、上述の判定のためにファイルシステム１１が、当該有効なブロックのハッシュ値を算出して、当該算出されたハッシュ値をブロックＢｑのハッシュ値Ｈｑと比較することは必ずしも必要ない。
　このように本実施形態によれば、ファイルシステム１１側では、ブロックＢｑのロケーションを示す情報が、従来技術におけるアドレスから当該ブロックＢｑのハッシュ値Ｈｑに変わるだけである。このため、重複排除のためのオーバヘッドを低減できる。またストレージ装置２０側では、ストレージコントローラ２２は、ブロックＢｑを、ファイルシステム１１側からの要求に応じて、当該ブロックＢｑのハッシュ値Ｈｑで一意に決まるロケーションに格納すれば良く、重複の判定は不要である。
　ところで前記実施形態では、ファイルＦｐを分割して得られるＱ（＝ｍ）個のブロック（データブロック）Ｂｑのサイズは固定長である。Ｑ個のブロックＢｑそれぞれのサイズは、当該ブロックＢｑそれぞれのオブジェクトＯＢｑのメタデータ４１０に含まれているサイズ情報により示される。このため、Ｑ個のブロックＢｑそれぞれが可変長であっても構わない。また、オブジェクトストレージ２１０に既に格納されているブロックの内容と同一内容のブロックを含むように、ファイルＦｐが複数のブロックに分割されても構わない。
　ここで、複数のファイルがいずれも、内容が同一の連続する複数のブロック、例えば２つのブロックＢａ及びＢｂを含むものとする。このような場合に、ブロックＢａ及びＢｂのオブジェクトＯＢａ及びＯＢｂが、１つのオブジェクトＯＢａｂにまとめられても構わない。つまり、ブロックＢａ及びＢｂが１つのブロックＢａｂにまとめられても構わない。
　このように、ＣＰＵ１０１がファイル管理部として機能して、ブロックのサイズを可変長とすることで、重複排除率を向上することができる。また、連続する複数のブロックをまとめることで、アクセス性能を向上することができる。
　ここで、ＣＰＵ１０１がファイルアクセスコントローラとして機能した結果、例えばステップＳ２２またはＳ３２で選択されたハッシュ値ＨｑをＩＤとして、ブロックＢｑのオブジェクトＯＢｑを読み出したものとする（ステップＳ２３またはＳ３３）。この場合に、ＣＰＵ１０１が、読み出されたオブジェクトＯＢｑ中の実データ４２０のハッシュ値、つまりブロックＢｑのハッシュ値を算出し、算出されたハッシュ値を選択されたハッシュ値Ｈｑと比較しても良い。ＣＰＵ１０１は、この比較の結果に基づき、ブロックＢｑのオブジェクトＯＢｑの読み出しにおけるエラーを検出する。つまりＣＰＵ１０１は、算出されたハッシュ値がハッシュ値Ｈｑに等しくない場合、ブロックＢｑのオブジェクトＯＢｑの読み出しでエラーが発生したと判断する。このような構成によれば、計算量を増やすことなく、エラーチェックを実現できる。
　また、ストレージ装置２０のストレージ２１が、前記実施形態と異なって、アクセス性能の異なる２種類のストレージ、例えば高速ストレージ及び低速ストレージから構成される階層化ストレージであるものとする。この場合、オブジェクトＯＢｑそれぞれのメタデータ４１０が、当該オブジェクトＯＢｑそれぞれへのアクセスの回数（アクセスカウント）を含んでも構わない。このような構成において、ＣＰＵ１０１が階層化管理部として機能して、アクセスカウントが例えば閾値を超えるオブジェクトを高速ストレージに格納し、アクセスカウントが閾値以下のオブジェクトを低速ストレージ格納しても良い。これにより、各オブジェクトを、アクセスカウント（つまり、アクセス頻度）に応じて階層化することができる。
　ところで、オブジェクトストレージシステムでは、信頼性と性能の向上のために、オブジェクトＯＢｑを複数の記憶媒体、例えばストレージ２１を構成する複数のＨＤＤのディスクに複製して記録することが一般的である。このようなオブジェクトＯＢｑの複製を必要とするシステムでは、当該オブジェクトＯＢｑのメタデータ４１０中の重複カウントＤＣＮＴｑに基づいて、当該オブジェクトＯＢｑの複製の数が決定されても良い。つまり、ＣＰＵ１０１が複製コントローラとして機能して、重複カウントＤＣＮＴｑの値が大きいオブジェクトＯＢｑほど、当該オブジェクトＯＢｑの複製を多く生成しても良い。このように、重複数の多いオブジェクトの複製数を増やすことでアクセス性能を向上できる。
　＜変形例＞
　次に前記実施形態の変形例について説明する。前記実施形態では、ストレージ装置２０のストレージ２１は、ファイルシステム１１からはオブジェクトストレージ２１０として認識される。つまり前記実施形態は、ファイルシステム１１がオブジェクトストレージを利用する構成を有している場合を前提としている。このためホスト１０は、オブジェクトコントローラ１２を必要とする。これに対して本変形例では、ストレージ装置２０のストレージ２１が、ファイルシステム１１からブロックストレージとして認識される。つまり本変形例は、ファイルシステム１１が、ブロックストレージを利用するものの、オブジェクトストレージを利用しない構成を有している場合を前提としている。
　このような構成において、ファイルシステム１１のＣＰＵ１０１が、ブロックＢｑをブロックストレージに格納する必要があるものとする。この場合、ＣＰＵ１０１はファイルアクセスコントローラとして機能して、ブロックＢｑのオブジェクトＯＢｑのメタデータ４１０に相当するメタデータ（以下、ブロック管理メタデータと称する）と、ブロックＢｑの内容との組（以下、メタデータ・ブロック組と称する）を、ブロックストレージに格納すれば良い。ブロック管理メタデータは、オブジェクトＯＢｑのメタデータ４１０と同様に、重複カウントＤＣＮＴｑを含む。ブロック管理メタデータは、更に、ブロックＢｑのハッシュ値Ｈｑ（＝オブジェクトＯＢｑのオブジェクトＩＤ）、メタデータ・ブロック組全体のサイズＳＺｑを示す情報を含む。
　ＣＰＵ１０１は、ブロックＢｑの内容を含むメタデータ・ブロック組をブロックストレージに書き込むために、当該メタデータ・ブロック組の書き込み先を示すアドレス、例えば論理ブロックアドレスＬＢＡｑを次のように決定する。本実施形態では、ハッシュ値Ｈｑを構成するビットの数は２５６である。一方、論理ブロックアドレスＬＢＡｑを構成するビットの数は６４である。つまり、ハッシュ値Ｈｑの長さは、論理ブロックアドレスＬＢＡｑの長さよりも長い。そこで、ＣＰＵ１０１は、ハッシュ値Ｈｑの予め定められた６４ビットの部分、例えば先頭の６４ビットを、論理ブロックアドレスＬＢＡｑとして決定する。
　ＣＰＵ１０１は、決定された論理ブロックアドレスＬＢＡｑとメタデータ・ブロック組のサイズＳＺｑとに基づいて、当該メタデータ・ブロック組の書き込みを、ストレージ装置２０のストレージコントローラ２２に要求する。これによりＣＰＵ１０１は、メタデータ・ブロック組を、論理ブロックアドレスＬＢＡｑから始まるサイズがＳＺｑの領域（ブロックストレージ内の領域）に書くことができる。ここで、ストレージコントローラ２２の動作は、前記実施形態と同様である。
　本変形例では、ハッシュ値Ｈｑの一部が論理ブロックアドレスＬＢＡｑとして用いられる。このため論理ブロックアドレスＬＢＡｑが、ハッシュ値Ｈｑとは異なるハッシュ値Ｈｒに基づいて決定された論理ブロックアドレスＬＢＡｒに一致する可能性がある。
　そこで、ハッシュ値Ｈｒを持つメタデータ・ブロック組が、論理ブロックアドレスＬＢＡｑ（＝ＬＢＡｒ）から始まる領域（以下、ＬＢＡｑ領域と称する）に既に格納されている場合、ＣＰＵ１０１は、ブロックＢｑのハッシュ値を算出し直す動作（いわゆる、再ハッシュ動作）を実行する。具体的には、ＣＰＵ１０１は、ハッシュ値Ｈｑに基づいて、当該ハッシュ値Ｈｑのハッシュ値Ｈｑ’を算出し、このハッシュ値Ｈｑ’をブロックＢｑのハッシュ値として用いる。なお、ＣＰＵ１０１がハッシュ値Ｈｑに一定値（例えば１）を加算して、その加算結果を、ブロックＢｑのハッシュ値として用いても良い。またＬＢＡｑ領域に既に格納されているメタデータ・ブロック組がハッシュ値Ｈｑを持つ場合、ＣＰＵ１０１は、重複排除が必要であると判定する。この場合、ＣＰＵ１０１は、ＬＢＡｑ領域に既に格納されているメタデータ・ブロック組のブロック管理メタデータ中の重複カウントＤＣＮＴｑを１増加する。
　本変形例によれば、ファイルシステム１１が利用するストレージが、オブジェクトストレージではなくて、一般のブロックストレージである場合でも、重複排除に関し、オブジェクトストレージを利用する場合と同等の機能を実現できる。
　前記実施形態では、ホスト１０がネットワーク３０を介してストレージ装置２０を利用する。しかし、ホスト１０を含む複数のホストがネットワーク３０に接続されていて、当該複数のホストがネットワーク３０を介してストレージ装置２０を利用しても良い。また、ストレージ装置２０を含む複数のストレージ装置がネットワーク３０に接続されていて、ホスト１０、または複数のホストが、複数のストレージ装置を利用しても良い。また、ホスト１０（または複数のホスト）が、ファイバチャネル（ＦＣ）、シリアルアタッチドＳＣＳＩ（ＳＡＳ）、或いはシリアルＡＴアタッチメント（ＳＡＴＡ）のようなネットワーク３０以外の接続手段を介してストレージ装置２０（複数のストレージ装置を）を利用しても良い。
　また前記実施形態では、ストレージ２１及びストレージコントローラ２２がホスト１０から独立に設けられている。しかし、ストレージ２１及びストレージコントローラ２２がホスト１０に内蔵されていても良い。
　また、前述の、ファイルアクセスコントローラ、ハッシュ値算出部、ファイル管理部、重複排除コントローラ、ファイル削除コントローラ、階層化管理部、及び複製コントローラのそれぞれ（機能要素）は、ファイルシステム１１のＣＰＵ１０１が、ストレージ制御プログラムを実行することにより実現されるソフトウェアモジュールである。しかし、これらの機能要素の少なくとも１つがハードウェアモジュールによって実現されても構わない。
　以上説明した少なくとも１つの実施形態によれば、重複排除に伴うオーバヘッドとデータ転送量とを減らすことができる。
　本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (12)

  1. 　ストレージに格納されるべきファイルを構成する少なくとも１つのデータブロックのハッシュ値を算出するハッシュ値算出部と、
    　前記少なくとも１つのデータブロックが第１のデータブロックを含み、且つ前記第１のデータブロックの第１のキャッシュ値が算出された場合、前記第１のハッシュ値を識別子として用いて、前記第１のハッシュ値に基づいて決定される前記ストレージの第１のロケーションに、前記第１のデータブロックを格納するアクセスコントローラと、
    　前記第１のロケーションに有効な第２のデータブロックが既に格納されている場合、前記第１のデータブロックが前記第１のロケーションに格納されるのを抑止する重複排除コントローラと
    　を具備するファイルシステム。
  2. 　前記アクセスコントローラは、前記ファイルを、前記第１のデータブロックを含む複数のデータブロックに分割し、
    　前記ハッシュ値算出部は、前記複数のデータブロックそれぞれのハッシュ値を算出し、
    　前記重複排除コントローラは、前記複数のデータブロックそれぞれの算出されたハッシュ値に基づいて決定される前記ストレージのロケーションに、有効なデータブロックが格納されているかに基づいて、前記複数のデータブロックそれぞれの重複排除が必要であるかを判定し、
    　前記アクセスコントローラは、前記第１のデータブロックの重複排除が必要でないと判定された場合、前記第１のロケーションに前記第１のデータブロックを格納する
    　請求項１記載のファイルシステム。
  3. 　前記ファイルの前記複数のデータブロックそれぞれが格納される前記ストレージのロケーションを、前記ファイルに対応付けられたｉノードを用いて管理するファイル管理部を更に具備し、
    　前記アクセスコントローラは、前記ファイルの読み出しが必要な場合、前記ファイルに対応付けられた前記ｉノードに基づいて前記ファイルの前記複数のデータブロックそれぞれが格納される前記ストレージのロケーションを特定することにより、前記ストレージから前記複数のデータブロックを読み出す
    　請求項２記載のファイルシステム。
  4. 　前記ファイルに対応付けられたｉノードは、前記複数のデータブロックそれぞれの算出されたハッシュ値が記録されるブロック表を含む請求項３記載のファイルシステム。
  5. 　前記ハッシュ値算出部は、前記第１のロケーションから前記第１のデータブロックが読み出された場合に、当該読み出された第１のデータブロックのハッシュ値を算出し、
    　前記アクセスコントローラは、前記第１のデータブロックの前記重複排除が必要でないと判定された場合、前記第１のハッシュ値を含む前記第１のデータブロックのメタデータと前記第１のデータブロックとの組を前記第１のロケーションに格納し、前記第１のロケーションから前記第１のデータブロックが読み出され、且つ当該読み出された第１のデータブロックのハッシュ値が算出された場合、前記算出されたハッシュ値を前記第１のデータブロックの前記メタデータに含まれている前記第１のハッシュ値と比較することにより、前記第１のデータブロックの読み出しにおけるエラーを検出する
    　請求項３記載のファイルシステム。
  6. 　前記アクセスコントローラは、前記第２のデータブロックを前記第１のロケーションに格納する必要がある場合、前記第２のデータブロックのハッシュ値と同一のハッシュ値を持つデータブロックの数を示すのに用いられる重複カウントを含む前記第２のデータブロックのメタデータと前記第２のデータブロックとの組を前記第１のロケーションに格納し、
    　前記重複排除コントローラは、前記第１のデータブロックの前記重複排除が必要であると判定された場合、前記第１のロケーションに格納されている前記第２のデータブロックの前記メタデータ中の前記重複カウントを１増加する
    　請求項２記載のファイルシステム。
  7. 　前記ストレージに格納されたデータブロックそれぞれの複製を生成する複製コントローラを更に具備し、
    　前記複製コントローラは、前記第２のデータブロックの複製の数を、前記第２のデータブロックの前記メタデータ中の前記重複カウントに基づいて決定する請求項６記載のファイルシステム。
  8. 　前記アクセスコントローラは、前記第１のデータブロックの前記重複排除が必要でないと判定された場合、前記第１のデータブロックのハッシュ値と同一のハッシュ値を持つデータブロックの数を示すのに用いられる重複カウントを含む前記第１のデータブロックのメタデータと前記第１のデータブロックとの組を前記第１のロケーションに格納する請求項２記載のファイルシステム。
  9. 　前記ストレージはオブジェクトストレージであり、
    　前記オブジェクトストレージの前記第１のロケーションは、前記第１のデータブロックのメタデータと前記第１のデータブロックとの組を含む第１のオブジェクトのオブジェクト識別子に基づいて決定され、
    　前記アクセスコントローラは、前記第１のデータブロックの前記第１のハッシュ値を、前記第１のオブジェクトのオブジェクト識別子として用いて、前記第１のオブジェクトの前記オブジェクト識別子に基づいて決定される前記オブジェクトストレージの前記第１のロケーションに、前記第１のオブジェクトを格納する
    　請求項１記載のファイルシステム。
  10. 　前記ストレージはブロックストレージであり、
    　前記ブロックストレージの前記第１のロケーションを指定する第１のアドレスは、前記第１のデータブロックの前記第１のハッシュ値の所定の一部を用いて表され、
    　前記アクセスコントローラは、前記第１のデータブロックのメタデータと前記第１のデータブロックとの組を、前記第１のアドレスで指定される前記ブロックストレージの前記第１のロケーションに格納する
    　請求項１記載のファイルシステム。
  11. 　ファイルシステムに適用されるデータ重複排除方法であって、
    　ストレージに格納されるべきファイルを構成する少なくとも１つのデータブロックのハッシュ値を算出することと、
    　前記少なくとも１つのデータブロックが第１のデータブロックを含み、且つ前記第１のデータブロックの第１のキャッシュ値が算出された場合、前記第１のハッシュ値を識別子として用いて、前記第１のハッシュ値に基づいて決定される前記ストレージの第１のロケーションに、前記第１のデータブロックを格納することと、
    　前記第１のロケーションに有効な第２のデータブロックが既に格納されている場合、前記第１のデータブロックが前記第１のロケーションに格納されるのを抑止することと
    　を具備するデータ重複排除方法。
  12. 　コンピュータに、
    　ストレージに格納されるべきファイルを構成する少なくとも１つのデータブロックのハッシュ値を算出することと、
    　前記少なくとも１つのデータブロックが第１のデータブロックを含み、且つ前記第１のデータブロックの第１のキャッシュ値が算出された場合、前記第１のハッシュ値を識別子として用いて、前記第１のハッシュ値に基づいて決定される前記ストレージの第１のロケーションに、前記第１のデータブロックを格納することと、
    　前記第１のロケーションに有効な第２のデータブロックが既に格納されている場合、前記第１のデータブロックが前記第１のロケーションに格納されるのを抑止することと
    　を実行させるためのファイルシステムのためのプログラム。
PCT/JP2014/074045 2014-09-11 2014-09-11 ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム WO2016038714A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2014/074045 WO2016038714A1 (ja) 2014-09-11 2014-09-11 ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム
CN201480081653.5A CN106663052A (zh) 2014-09-11 2014-09-11 文件***、数据重复排除方法以及用于文件***的程序
JP2016514208A JPWO2016038714A1 (ja) 2014-09-11 2014-09-11 ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム
US15/405,953 US20170147598A1 (en) 2014-09-11 2017-01-13 File system, data deduplication method and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/074045 WO2016038714A1 (ja) 2014-09-11 2014-09-11 ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/405,953 Continuation US20170147598A1 (en) 2014-09-11 2017-01-13 File system, data deduplication method and storage medium

Publications (1)

Publication Number Publication Date
WO2016038714A1 true WO2016038714A1 (ja) 2016-03-17

Family

ID=55458502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/074045 WO2016038714A1 (ja) 2014-09-11 2014-09-11 ファイルシステム、データ重複排除方法、及びファイルシステムのためのプログラム

Country Status (4)

Country Link
US (1) US20170147598A1 (ja)
JP (1) JPWO2016038714A1 (ja)
CN (1) CN106663052A (ja)
WO (1) WO2016038714A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018020593A1 (ja) * 2016-07-27 2018-02-01 株式会社日立製作所 計算機システムおよびデータ格納方法
JP2022533942A (ja) * 2019-05-17 2022-07-27 ヒタチ ヴァンタラ エルエルシー オブジェクトベースファイルシステムを管理するための装置、システム及び方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10540323B2 (en) * 2017-05-30 2020-01-21 Western Digital Technologies, Inc. Managing I/O operations in a storage network
US20210056085A1 (en) * 2019-08-19 2021-02-25 Gsi Technology Inc. Deduplication of data via associative similarity search

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009543198A (ja) * 2006-06-29 2009-12-03 ネットアップ，インコーポレイテッド ブロック指紋を読み出し、ブロック指紋を使用してデータ重複を解消するシステム、及び方法
JP2013182476A (ja) * 2012-03-02 2013-09-12 Nec Corp ストレージシステム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5020673B2 (ja) * 2007-03-27 2012-09-05 株式会社日立製作所 重複したファイルの記憶を防ぐコンピュータシステム
US7870409B2 (en) * 2007-09-26 2011-01-11 Hitachi, Ltd. Power efficient data storage with data de-duplication
US9665304B2 (en) * 2011-09-07 2017-05-30 Nec Corporation Storage system with fast snapshot tree search
US9164688B2 (en) * 2012-07-03 2015-10-20 International Business Machines Corporation Sub-block partitioning for hash-based deduplication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009543198A (ja) * 2006-06-29 2009-12-03 ネットアップ，インコーポレイテッド ブロック指紋を読み出し、ブロック指紋を使用してデータ重複を解消するシステム、及び方法
JP2013182476A (ja) * 2012-03-02 2013-09-12 Nec Corp ストレージシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"OPEN Enterprise magazine", DATA BACKUP, vol. 5, no. 10, 1 October 2007 (2007-10-01), pages 32 - 39 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018020593A1 (ja) * 2016-07-27 2018-02-01 株式会社日立製作所 計算機システムおよびデータ格納方法
JPWO2018020593A1 (ja) * 2016-07-27 2018-12-06 株式会社日立製作所 計算機システムおよびデータ格納方法
JP2022533942A (ja) * 2019-05-17 2022-07-27 ヒタチ ヴァンタラ エルエルシー オブジェクトベースファイルシステムを管理するための装置、システム及び方法
JP7288085B2 (ja) 2019-05-17 2023-06-06 ヒタチ ヴァンタラ エルエルシー オブジェクトベースファイルシステムを管理するための装置、システム及び方法

Also Published As

Publication number Publication date
CN106663052A (zh) 2017-05-10
JPWO2016038714A1 (ja) 2017-04-27
US20170147598A1 (en) 2017-05-25

Similar Documents

Publication Publication Date Title
US7975115B2 (en) Method and apparatus for separating snapshot preserved and write data
JP6240071B2 (ja) ストレージシステムにおけるマッピングテーブルを効果的に管理するコンピューターシステムおよびその方法
JP6200886B2 (ja) フラッシュストレージアレイにおける論理セクタマッピング
JP5707540B1 (ja) 階層化ストレージシステム、ストレージコントローラ、及び階層間のデータ移動を代替する方法
US8478729B2 (en) System and method for controlling the storage of redundant electronic files to increase storage reliability and space efficiency
US11816093B2 (en) Storage tier verification checks
US9678672B2 (en) Selective erasure of expired files or extents in deduplicating virutal media for efficient file reclamation
US9933948B2 (en) Tiered storage system, computer using tiered storage device, and method of correcting count of accesses to file
US9075754B1 (en) Managing cache backup and restore
US9021222B1 (en) Managing incremental cache backup and restore
JP6677740B2 (ja) ストレージシステム
KR101369813B1 (ko) 광 디스크 저장 시스템에 저장된 미디어에의 액세스, 압축 및 추적
US20180307440A1 (en) Storage control apparatus and storage control method
US20170147598A1 (en) File system, data deduplication method and storage medium
WO2016013075A1 (ja) ストレージ、計算機およびその制御方法
JP2020086477A (ja) 大規模ストレージシステム及び大規模ストレージシステムにおけるデータ配置方法
JP6572775B2 (ja) 制御装置、ストレージ装置、データ管理プログラム及びデータ管理方法
JP6419662B2 (ja) ストレージシステム及びデータ重複検出方法
WO2019026221A1 (ja) ストレージシステム及びストレージ制御方法
US11803527B2 (en) Techniques for efficient data deduplication
JP5691234B2 (ja) ディスクアレイ装置、及び、ミラーリング制御方法
WO2017212515A1 (ja) ストレージシステム、計算機、およびストレージ制御方法
JP2022091062A (ja) 情報処理装置、重複除去方法及び重複除去プログラム
JP2016197357A (ja) データアーカイブシステム及びデータ記録方法

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2016514208

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 14901544

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14901544

Country of ref document: EP

Kind code of ref document: A1