JP6295742B2 - Storage system - Google Patents
Storage system Download PDFInfo
- Publication number
- JP6295742B2 JP6295742B2 JP2014050104A JP2014050104A JP6295742B2 JP 6295742 B2 JP6295742 B2 JP 6295742B2 JP 2014050104 A JP2014050104 A JP 2014050104A JP 2014050104 A JP2014050104 A JP 2014050104A JP 6295742 B2 JP6295742 B2 JP 6295742B2
- Authority
- JP
- Japan
- Prior art keywords
- block
- file
- seed
- information
- metadata
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、ストレージシステムにかかり、特に、仮想的なボリュームを有するストレージシステムに関する。 The present invention relates to a storage system, and more particularly to a storage system having a virtual volume.
バックアップソフトウェアを用いて、ストレージシステムのボリュームを評価対象のストレージシステムでバックアップする、あるいは、リストアする場合に、バックアップの評価やリストアの評価を行うことがある。バックアップの評価では、ストレージシステム上に作成したテスト用のボリュームを、評価対象のストレージシステムにバックアップする。リストアの評価では、評価対象のストレージシステムにバックアップしたボリュームを元のストレージシステム上にリストアし、バックアップ前のボリュームと比較する。この場合、テスト用のボリュームを作成したり、比較するためのストレージシステム、および、比較ソフトウェアが必要となる。 When a backup system is used to back up or restore a storage system volume in an evaluation target storage system, backup evaluation or restoration evaluation may be performed. In the backup evaluation, the test volume created on the storage system is backed up to the evaluation target storage system. In restoration evaluation, a volume backed up to the storage system to be evaluated is restored to the original storage system and compared with the volume before backup. In this case, a storage system and comparison software for creating or comparing test volumes are required.
ところが、近年、ストレージシステムの高性能化、高機能化により、テストボリュームについて以下の変化が出てきている。第１に、ストレージシステムの高性能化により、高速かつ大容量となったため、ボリュームのサイズが肥大化している。第２に、ストレージシステムが圧縮や重複排除などの機能を持つようになったため、重複排除されないデータの評価を行う際にテストボリュームを毎回作り直さなければならない。これらの変化により、テストボリュームを作成するための高性能、大容量なストレージシステムを用意するコストがかかる。また、巨大なテストボリュームを毎回作成しなおすために膨大な時間がかかる、という問題が出てきている。 However, in recent years, the following changes have occurred in the test volume due to the higher performance and higher functionality of storage systems. First, because the storage system has become high-performance and high-capacity due to high performance, the size of the volume is enlarged. Second, since the storage system has functions such as compression and deduplication, a test volume must be recreated every time when data that is not deduplicated is evaluated. These changes add to the cost of preparing a high-performance, large-capacity storage system for creating test volumes. Another problem is that it takes an enormous amount of time to recreate a huge test volume each time.
また、特に重複排除機能を持つストレージシステムに対してボリュームのフルバックアップを日次や週次で行うシステムの場合、フルバックアップ毎に前回のバックアップと同じ部分は重複排除されることとなる。このようなシステムにおけるバックアップを何度も繰り返して、ストレージシステムへの影響を調べる評価を行う場合、テストボリューム内のシステムの運用状況に合わせてファイルの更新（作成・削除など含む）をシミュレーションする必要がある。しかし、実際のストレージ上に用意したテストボリュームに対してこのファイル更新のシミュレーションを行うと、ボリュームへの多くの書き込み操作が必要なため、シミュレーションに時間がかかる。このため、多くの回数のバックアップの評価を行う場合に、多大な時間を要するという問題が有る。 Further, in the case of a system that performs a full volume backup daily or weekly for a storage system that has a deduplication function, the same part as the previous backup is deduplicated for each full backup. When performing an evaluation to examine the impact on the storage system by repeating backups in such a system many times, it is necessary to simulate file updates (including creation / deletion) according to the operation status of the system in the test volume. There is. However, if this file update simulation is performed on a test volume prepared on an actual storage, many write operations to the volume are required, and the simulation takes time. For this reason, there is a problem that it takes a lot of time to evaluate a large number of backups.
ここで、特許文献１における仮想ファイルシステムでは、ファイルシステム単位のバックアップを行う場合に関して、ファイルの作成、削除等が行え、データ保存用のストレージを必要としない評価用のファイルシステムを提供している。ところが、この技術では、ファイルシステムとしてのみデータ読み込みが可能であるが、ボリュームバックアップ等、物理アドレスによるボリューム操作を行うことができない。以上より、依然として、テストボリューム用のストレージシステムの容量増加や、テストボリュームの作成や変更に多大な時間を要する、という問題が生じる。 Here, the virtual file system disclosed in Patent Document 1 provides an evaluation file system that can create and delete files and does not require storage for data storage when performing backup in units of file systems. . However, with this technology, data can be read only as a file system, but volume operations using physical addresses such as volume backup cannot be performed. As described above, there still remains a problem that it takes much time to increase the capacity of the storage system for the test volume and to create or change the test volume.
このため、本発明の目的は、上述した課題である、ボリューム用のストレージシステムの容量増加や、ボリュームの作成や変更に多大な時間を要する、ということを解決することにある。 For this reason, an object of the present invention is to solve the above-mentioned problems that increase the capacity of a storage system for volumes and that it takes a lot of time to create or change a volume.
本発明の一形態であるストレージシステムは、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
という構成をとる。
A storage system according to an aspect of the present invention
Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
With
The configuration is as follows.
また、本発明の一形態であるプログラムは、
情報処理装置に、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させる、
という構成をとる。
In addition, a program which is one embodiment of the present invention is
In the information processing device,
Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
To realize,
The configuration is as follows.
また、本発明の一形態である情報処理方法は、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶すると共に、前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶し、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
という構成をとる。
An information processing method according to one aspect of the present invention includes:
For each file, metadata including physical address information that specifies a storage area that is a reference destination of a block that constitutes the file is stored, and data of the block is stored in the storage area that is specified by the physical address. Stores information that identifies the block seed from which to generate,
Identifying the block seed based on information identifying the block seed stored in the storage area identified by the physical address, and generating block data from the block seed,
The configuration is as follows.
本発明は、以上のように構成されることにより、ボリューム用のストレージシステムの容量を低減し、ボリュームの作成や変更にかかる時間を短縮することができる。 With the configuration as described above, the present invention can reduce the capacity of a volume storage system and can shorten the time required to create or change a volume.
＜実施形態１＞
本発明の第１の実施形態を、図１乃至図４を参照して説明する。図１は、システム全体の構成を示すブロック図である。図２は、ストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。図３は、ストレージシステムにおけるファイル作成時の動作を示すフローチャートであり、図４は、ブロック読み込み時の動作を示すフローチャートである。
<Embodiment 1>
A first embodiment of the present invention will be described with reference to FIGS. FIG. 1 is a block diagram showing the configuration of the entire system. FIG. 2 is a diagram showing a configuration of a virtual file system and a virtual volume in the storage system. FIG. 3 is a flowchart showing an operation when creating a file in the storage system, and FIG. 4 is a flowchart showing an operation when reading a block.
図１に示す情報処理システムは、ランダムデータファイルを持つ仮想ボリュームを構築するストレージシステム１０を備えている。そして、このストレージシステム１０により、後述するように、ボリュームの実データをストレージ上に格納することなく、仮想的なファイルシステムからファイルの作成、削除といった一般的なファイル操作を行え、かつ、物理アドレスでボリュームに対して読み書き操作ができる仮想的なボリュームを提供する。
The information processing system shown in FIG. 1 includes a
そして、情報処理システムは、ストレージシステム１０のボリュームのバックアップ先及びリストア元となり、当該バックアップの評価やリストアの評価対象となる評価対象ストレージ３１を有する評価対象ストレージシステム３０を備えている。また、情報処理システムは、ボリュームのバックアップやリストアの操作を行うクライアント３０を備えている。
The information processing system includes an evaluation
上記ストレージシステム１０は、図１に示すように、装備された演算装置にプログラムが組み込まれることで構築された、仮想ファイルシステム１１と仮想ボリュームインタフェース１２とを備えている。また、ストレージシステム１０は、装備された記憶装置に形成された、ディレクトリツリー構造記憶部１３、ファイルメタデータ記憶部１４、乱数シードマップ記憶部１５、を備えている。以下、各構成について詳述する。
As shown in FIG. 1, the
ディレクトリツリー構造記憶部１３は、ファイルシステムにおけるディレクトリのツリー構造を保存するための記憶領域である。ディレクトリには、ファイル名と、ファイルに対応するメタデータを識別するための識別子と、がペアで保存されることで、図２に示すように、ファイルとメタデータとが関連付けられる。また、ディレクトリには、サブディレクトリ名と、そのサブディレクトリのデータ（再帰的にサブディレクトリ内の、ファイル名と識別子のペアや、サブディレクトリ名とデータ情報のペアなど）が関連付けられる。
The directory tree
ファイルメタデータ記憶部１４（メタデータ記憶手段）は、個々のファイルのメタデータを保存する記憶領域で、識別子から対応するメタデータを検索することができる。具体的にメタデータ４０は、図２に示すように、ファイルのサイズ、作成日付、属性、アクセス許可設定など、ファイルシステムが一般的に持つファイルの実データ以外の付随情報を含む。そして、本発明におけるメタデータ４０は、さらに、ファイルがボリュームのどのブロックを利用しているかを示す、ブロックの物理アドレスリスト４１を含む。つまり、物理アドレスリスト４１に記憶される各物理アドレスは、ファイルを構成する各ブロックのそれぞれの参照先となる乱数シードマップ５０内の記憶領域を特定するアドレスである。
The file metadata storage unit 14 (metadata storage means) is a storage area for storing metadata of individual files, and can search corresponding metadata from the identifier. Specifically, as shown in FIG. 2, the
乱数シードマップ記憶部１５は、乱数シードマップ５０（S-map）を記憶している。乱数シードマップ５０は、ボリュームのブロック毎の乱数シード（ブロックシード）を保存する表であり、ブロックの物理アドレスから乱数シードを求めるのに使用される表である。なお、本実施形態では、ブロックの乱数シードは、当該ブロックの実データを生成するための元となる情報であり、かかる乱数シードから、後述するように疑似乱数アルゴリズムを用いて、ブロックの実データを生成する。つまり、本実施形態では、ブロックの実データは記憶していない。
The random number seed
仮想ファイルシステム１１（ブロックデータ生成手段、仮想ファイルシステム構築部）は、上述したディレクトリツリー構造記憶部１３、ファイルメタデータ記憶部１４及び乱数シードマップ記憶部１５内の情報を参照、更新することで、クライアント２０に対してファイルシステムを表現する。そして、仮想ファイルシステム１１は、クライアント２０がファイル単位の操作を可能としている。
The virtual file system 11 (block data generation means, virtual file system construction unit) refers to and updates the information in the directory tree
仮想ボリュームインターフェイス１２（ブロックデータ生成手段、仮想ボリューム構築部）は、上述した乱数シードマップ記憶部１５内の情報を参照することで、ボリュームを表現し、ブロック単位の操作を可能としている。
The virtual volume interface 12 (block data generation means, virtual volume construction unit) expresses a volume by referring to the information in the random number seed
クライアント２０は、ボリュームを準備するために、仮想ファイルシステム１１を用いてファイル、ディレクトリの作成や削除等のファイルシステムを操作するコンピュータである。また、クライアント２０は、ボリュームを準備するために、バックアップソフトウェアを用いて、仮想ボリュームインターフェイス１２に対してブロック単位の読み込み、書き込みを行ったり、それらのブロック単位のデータを評価対象ストレージシステム３０にバックアップ、リストアする操作を行うコンピュータである。
The
評価対象ストレージシステム３０は、上述したストレージシステム１に記憶されている仮想ボリュームがバックアップされたり、リストアされることにより、バックアップやリストアの評価の対象となるストレージシステムである。
The evaluation
次に、上述したストレージシステム１０に構築される仮想ボリュームへの操作、具体的に、ファイルの作成、ファイルの更新／削除、ボリュームの読み込み、ボリュームの書き込み、について、詳しく説明する。なお、ここで説明しないファイルシステム操作（ディレクトリ作成・削除、名前の変更、属性変更など）は、全て通常のファイルシステムと同様に、ディレクトリツリー構造／メタデータを参照、または更新することで可能である。
Next, operations on the virtual volume constructed in the
まず、「ファイルの作成」について説明する。ファイルは、格納するデータの乱数シード列を与えて作成する。仮想ファイルシステムは、通常のファイルシステムと同様に、仮想ボリューム上のどの部分にファイルのデータを置くかを決定し（ブロックの割り当て）、各々のブロックのデータの元となるブロックシードを更新する。そして、ファイルのメタデータとして、ファイルが使用するブロックの参照先のリスト（物理アドレスのリスト）を保存する。ここで、ブロックの乱数シードに関しては、ファイル名に特定の書式で埋め込まれた乱数シード値から擬似乱数アルゴリズムによって、ファイルが使うブロックの乱数シードをファイルの先頭から順に決定する。 First, “file creation” will be described. The file is created by giving a random number seed sequence of data to be stored. Similar to the normal file system, the virtual file system determines in which part of the virtual volume the file data is to be placed (block allocation), and updates the block seed that is the source of the data of each block. Then, a block reference list (physical address list) of blocks used by the file is stored as file metadata. Here, regarding the random number seed of the block, the random number seed of the block used by the file is determined in order from the top of the file by a pseudo random number algorithm from the random number seed value embedded in the file name in a specific format.
上述した「ファイルの作成」の具体例を、図３のフローチャートを参照して説明する。まず、クライアント２０は、仮想ファイルシステム１１に対して、「/dir1/file_16KB_12345」という名前のファイルの作成を要求する。仮想ファイルシステム１１は、このファイルに対応するファイルメタデータ（識別子500とする）を作成する（ステップＳ１）。メタデータに含まれる日付、アクセス許可情報や属性等は、一般的なファイルシステムと同様に作成する。ファイルサイズに関しては、ファイル名から16KBであると判定し、それをファイルサイズとして保存する。
A specific example of the “file creation” described above will be described with reference to the flowchart of FIG. First, the
そして、16KB分の空きブロックをファイルに割り当て（ステップＳ２）、それらのブロック群への物理アドレスのリスト４１を保存する。なお、一般的には、ファイルシステムは空きブロックをビットマップやリンクリスト等で管理しており、それらを用いて空きブロックを割り当てるが、ここでは本技術に直接関係ないため、詳細な説明は省略する。そして、ブロックサイズを4KBとし、ブロック100,101,102,150の4ブロックが割り当てられたとすると、このファイルのメタデータには、物理アドレスリスト４１として、100,101,102,150の4つのアドレスが保存される（ステップＳ３）。
Then, 16 KB free blocks are allocated to the file (step S2), and a list 41 of physical addresses for those blocks is stored. In general, the file system manages empty blocks using a bitmap or a link list, and assigns empty blocks using them. However, detailed explanation is omitted here because it is not directly related to this technology. To do. Then, assuming that the block size is 4 KB and four
続いて、ファイル名から乱数シード12345を用いて擬似乱数アルゴリズムを初期化し、4つの乱数を計算し、乱数12345, 67890, 35791, 46802を得たとする。この場合には、ブロック100の乱数シードとして12345、ブロック101の乱数シードとして67890、ブロック102の乱数シードとして35791、ブロック150の乱数シードとして46802を使うこととし、乱数シードマップ５０（S-map）上のこれら4ブロックの値を更新する（ステップＳ４）。
Subsequently, it is assumed that the pseudorandom algorithm is initialized from the file name using the random number seed 12345, four random numbers are calculated, and random numbers 12345, 67890, 35791, and 46802 are obtained. In this case, 12345 is used as the random number seed of the
その後、仮想ファイルシステム１１は、当該ファイルが作成されるディレクトリ「/dir1」に当該ファイル名「file_16KB_12345」と、当該ファイルのメタデータの識別子50とをペアで登録して、ファイル名とメタデータと関連付ける（ステップＳ５）。これでファイルの作成が完了したとして、仮想ファイルシステム１１はクライアント２０にファイル作成成功を返却する。
Thereafter, the virtual file system 11 registers the file name “file_16KB_12345” and the
そして、仮想ファイルシステム１１は、以下のようにしてファイルシステムを表現する。例えば、ファイルの読み出しを要求された場合には、まずファイルのメタデータ４０を参照して、ファイルを構成するブロックの物理アドレス４１を特定する。そして、後述する「ボリュームの読み込み」の処理と同様に、物理アドレス４１を用いてブロックの乱数シードを特定し、当該乱数シードからブロックのデータを生成して、ファイルを生成する。これにより、仮想的なファイルシステムを実現する。
The virtual file system 11 represents a file system as follows. For example, when reading of a file is requested, first, the physical address 41 of a block constituting the file is specified by referring to the
次に、「ファイルの更新や削除」について説明する。データを更新する場合、メタデータ４０を参照して、ファイルが使用しているブロックの乱数シードを、新しい乱数シードで更新する。ファイルの追記や削除により、ファイルのサイズが変わる場合は、新しいブロックを追加で割り当てたり、不要となるブロックを物理アドレスリスト４１から削除したりする。物理アドレスリスト４１から削除されたブロックの乱数シードは、特に初期化したりせずにそのままとする。これらの動作は実データをボリューム上に保存しない事以外は、通常のファイルシステムと同等である。
Next, “file update and deletion” will be described. When updating data, the
上述した「ファイルの削除」の具体例を説明する。クライアント２０が仮想ファイルシステム１１にファイル削除（上記ファイル作成の説明で作成した「/dir1/file_16KB_12345」の削除）を要求する。仮想ファイルシステム１１は、ディレクトリ「/dir1」からファイル名「file_16KB_12345」を探し、当該ファイル名とメタデータ識別子500のペアを当該ディレクトリから削除する。また、メタデータ識別子500で表される（当該ファイルの）メタデータも削除する。その後、クライアントに削除成功を返却する。このとき、乱数シードマップ５０（S-map）に関しては触れない。これは、ファイル削除ではファイルの管理情報が消えるだけで、ボリューム上の実際のデータを削除するわけではない一般的なファイルシステムと同等の動作となる。
A specific example of the “file deletion” described above will be described. The
次に、「ボリュームの読み込み」について説明する。ボリュームからデータを読み込む場合は、物理アドレスに対応するブロックの乱数シードを用いて擬似乱数アルゴリズムを初期化する。そして、この擬似乱数アルゴリズムを用いて乱数データを作成し、それをボリュームから読み込まれた当該ブロックのデータとしてクライアントに返却する。 Next, “volume reading” will be described. When reading data from the volume, the pseudorandom algorithm is initialized using the random number seed of the block corresponding to the physical address. Then, random number data is created using this pseudo random number algorithm, and it is returned to the client as data of the block read from the volume.
上述した「ボリュームの読み込み」の具体例を、図４のフローチャートを参照して説明する。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス100で表されるブロック（ブロック100）の読み込みを要求する。仮想ボリュームインターフェイス１２は、乱数シードマップ１５（S-map）を参照して、物理アドレス100にアクセスして（ステップＳ１１）、当該物理アドレスに対応する乱数シード12345を求め（ステップＳ１２）、この乱数シード12345を用いて擬似乱数アルゴリズムを初期化する。そして、この擬似乱数アルゴリズムを用いて4KB分の乱数データを計算し（ステップＳ１３）、それを当該ブロックのデータとしてクライアントに返却する（ステップＳ１４）。
A specific example of “volume reading” described above will be described with reference to the flowchart of FIG. The
次に、「ボリュームへの書き込み」について説明する。ボリュームへデータを書き込む場合、クライアント２０が書き込んだデータと、そのブロックに上述の読み出し操作を行った場合に得られるデータとを比較する。データが異なる場合は書き込みエラーとする。
Next, “write to volume” will be described. When writing data to the volume, the data written by the
上述した「ボリュームへの書き込み」の具体例を説明する。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス150で表されるブロックへ、4KBのデータの書き込みを要求する。仮想ボリュームインターフェイス１２は乱数シードマップ１５（S-map）を参照して、物理アドレス150に対応する乱数シード46802を求め、この乱数シード46802を用いて擬似乱数アルゴリズムを初期化する。そして、擬似乱数アルゴリズムから4KB分の当該ブロックのデータを計算し、そのデータと、クライアント２０がから受け取った4KBのデータとを比較する。データが等しい場合は書き込み成功とし、異なっている場合は書き込みエラーをクライアントに返却する。
A specific example of the above-described “write to volume” will be described. The
以上のようにして、実際にブロックの実データを記憶することなく、少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。上述した例では、ブロックサイズを4KB、物理アドレスを32bit（ボリューム容量16TB）、ブロックの乱数シードを64bitとすると、実際に記憶する乱数シードマップ記憶部１５（S-map）のサイズは、64bit*2^32=32GBとなる。
As described above, the virtual file system and the virtual volume can be realized with a small capacity without actually storing the actual data of the block. In the above example, if the block size is 4 KB, the physical address is 32 bits (
また、物理アドレスからブロック単位でボリューム操作も行うことができる。従って、ボリュームをバックアップやリストアの評価用に使用する場合であっても、かかるボリュームの作成や変更を容易に行うことができ、かかる時間の削減を図ることができる。 Also, volume operations can be performed in block units from physical addresses. Therefore, even when a volume is used for backup or restoration evaluation, such volume can be easily created or changed, and the time required can be reduced.
＜実施形態２＞
次に、本発明の第２の実施形態を説明する。本実施形態におけるストレージシステムは、上述した第１の実施形態とほぼ同様の構成を有しているが、以下の点で異なる。
<Embodiment 2>
Next, a second embodiment of the present invention will be described. The storage system according to the present embodiment has substantially the same configuration as that of the first embodiment described above, but differs in the following points.
ここで、上述した実施形態１では、乱数シードの範囲（最大値）がS-map５０のブロック数以上であれば、ボリューム内の全てのブロックをユニークなデータにできる。但し、評価対象ストレージシステム３０が重複排除機能をもつ場合、バックアップ等を評価するボリュームごとに、別の乱数シードを使う必要があり、より大きな範囲の乱数シードを使わなければデータが重複してしまう。ところが、ブロック毎の乱数シードの範囲を大きくすると、乱数シードマップ記憶部１５に記憶されるS-map全体のサイズが大きくなる。そこで乱数シードを効率的に扱う手法として、本実施形態のようにストレージシステムを構成する。
Here, in Embodiment 1 described above, if the range (maximum value) of the random number seed is equal to or greater than the number of blocks of the S-
本実施形態におけるストレージシステム１０は、ボリューム毎に、当該ボリューム全体に対して割り当てられた乱数シードを有する。つまり、ストレージシステム１０は、乱数シードマップ記憶部１５（S-map）に記憶されたブロック毎の乱数シードとは別に、ボリューム全体で１つの乱数シードを記憶している。なお、ボリュームの乱数シードの変更は、例えば、ボリュームのルートディレクトリ上に特殊な名前を持つファイルを作成して記憶し、乱数シード値を書き込むと、それがボリュームの乱数シードとして利用されるようにすることで実現する。
The
そして、「ボリュームの読み込み」時にブロックの乱数データを読み込む際には、S-map５０に格納されているこのブロックに対応する乱数シードと、ボリュームの乱数シードと、を組み合わせて、実際のブロックの乱数シードとする。つまり、S-mapに格納されている乱数シードは、ブロックの乱数シードを特定する情報であり、実際のブロックの乱数シードの一部を形成する情報である。また、ボリュームの乱数シードも、実際のブロックの乱数シードの他の一部を形成する情報である。このため、S-mapに格納された乱数シードとボリュームの乱数シードとを組み合わせることで、実際のブロックの乱数シードを生成する。そして、上記２種類の乱数シードを組み合わせた乱数シードで擬似乱数アルゴリズムを初期化して、ブロックのデータを生成する。
When reading the random number data of the block at the time of “reading the volume”, the random number seed of the actual block is combined by combining the random number seed corresponding to this block stored in the S-
上記構成のストレージシステム１０による「ボリュームの読み込み」の具体例について説明する。なお、ボリューム全体で１つの乱数シードは14825であるとする。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス100で表されるブロック（ブロック100）の読み込みを要求する。このとき、まず、実施形態１と同様に乱数シードマップ記憶部１５内のS-map５０を参照して、格納されている乱数シード12345を求める。そして、ボリューム全体の乱数シード14825と、求めた乱数シード12345と、を組み合わせた新たな値で、擬似乱数アルゴリズムを初期化する。この擬似乱数アルゴリズムを用いて4KB分の乱数データを計算し、それを当該ブロックのデータとしてクライアントに返却する。
A specific example of “volume reading” by the
次に、ボリューム全体の乱数シードの変更の具体例について説明する。クライアント２０が特殊なファイル名「/volume_seed」を持つファイルを作成し、データとして34567を書き込むと、ボリューム全体の乱数シードが34567に変更される。
Next, a specific example of changing the random number seed of the entire volume will be described. When the
ここで、ブロックの乱数シードをボリューム内でユニークにするための最低サイズ（＝物理アドレスのサイズ）を32bitとし、ボリュームの乱数シードを32bitとする。すると、ブロック毎の実質的な乱数シードは、32（ブロック毎の乱数シード）＋32（ボリュームの乱数シード）=64ビットとなる。このため、実施形態１と同等の範囲を維持しているにもかかわらず、S-mapのサイズは32bit*2^32=16GBとなり、実施形態１の半分で済むこととなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。 Here, the minimum size (= physical address size) for making the random number seed of the block unique within the volume is 32 bits, and the random number seed of the volume is 32 bits. Then, the substantial random number seed for each block is 32 (random number seed for each block) +32 (random number seed for volume) = 64 bits. For this reason, despite maintaining the same range as in the first embodiment, the size of the S-map is 32 bits * 2 ^ 32 = 16 GB, which is half that of the first embodiment. In other words, a virtual file system and a virtual volume can be realized with a smaller capacity without storing actual block data.
また、本実施形態におけるストレージシステム１０では、ボリューム全体のデータを以前のデータと異なるデータに変更する場合には、単純にボリューム全体の乱数シードを変更すれば良い。その結果、ボリュームの生成、変更を容易に行うことができ、それにかかる時間を短縮することができる。例えば、評価対象のストレージに対して、まったく異なるデータで構成される複数のボリュームバックアップを繰り返したい時などに有益である。
Further, in the
＜実施形態３＞
次に、本発明の第３の実施形態を、図５乃至図８を参照して説明する。図５は、システム全体の構成を示すブロック図である。図６は、ストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。図７は、ストレージシステムにおけるファイル作成時の動作を示すフローチャートであり、図８は、ブロック読み込み時の動作を示すフローチャートである。本実施形態におけるストレージシステムは、上述した第１の実施形態とほぼ同様の構成を有しているが、以下の点で異なる。
<Embodiment 3>
Next, a third embodiment of the present invention will be described with reference to FIGS. FIG. 5 is a block diagram showing the configuration of the entire system. FIG. 6 is a diagram showing a configuration of a virtual file system and a virtual volume in the storage system. FIG. 7 is a flowchart showing an operation when creating a file in the storage system, and FIG. 8 is a flowchart showing an operation when reading a block. The storage system according to the present embodiment has substantially the same configuration as that of the first embodiment described above, but differs in the following points.
本実施形態におけるストレージシステム１０は、実施形態１で説明した乱数シードマップ記憶部１５の代わりに、メタデータ逆引きマップ６０（R-map）を記憶したメタデータ逆引きマップ記憶部１６（ブロックマップ記憶手段）を備えている。メタデータ逆引き表６０（R-map）は、ブロックの参照先となる物理アドレスに対応する記憶領域を有しており、ブロックのデータがどのファイルとして保存されているデータであるか、を表すための表である。このため、ブロックの物理アドレスが示すメタデータ逆引き表６０（R-map）上の記憶領域には、当該ブロックが含まれるファイルに関連付けられたメタデータ４０を識別するメタデータ識別子が格納されている。このメタデータ識別子は、ブロックシードを特定する情報として機能し、後述するように、ブロックオフセットと組み合わせられることによりブロックの乱数シード（ブロックシード）となる。
The
また、本実施形態におけるメタデータ４０には、対応するファイル毎に固有の乱数シード４２（ファイルシード）と、メタデータ逆引き表６０（R-map）からのメタデータの参照数を表す参照カウント４３と、が記憶されている。なお、メタデータ４０には、実施形態１で説明したファイルの属性や、ファイルを構成する各ブロックの参照先となる物理アドレスのリスト４１が記憶している。物理アドレスリスト４１は、各ブロックのファイル内における位置に対応して形成されているため、ブロックのファイル内における位置を表すオフセット情報（ブロック識別情報）として用いられる。なお、メタデータ４０には、オフセット情報とは異なり、ファイルを構成する各ブロックを当該ファイル内において区別できるブロック識別情報を記憶していてもよい。
Further, the
上記構成のストレージシステム１０において「ファイルの作成」の具体例を、図７のフローチャートを参照して説明する。ここでは、メタデータ逆引きマップ記憶部１６（R-map）のブロック100および150、151には、メタデータ識別子は未登録であるとする（識別子0を未登録であることを表す特別な識別子とする）。一方、ブロック101と102には、メタデータ識別子499が登録されているとし、当該メタデータ識別子499で表されるファイルのメタデータの参照カウントは、2とする。
A specific example of “file creation” in the
まず、クライアント２０は仮想ファイルシステム１２に対して、「/dir1/file_16KB_12345」という名前のファイルの作成を要求する。仮想ファイルシステム１１は、新しくメタデータ（メタデータ識別子500とする）を作成する（ステップＳ２１）。日付、アクセス許可情報や属性等は、一般的なファイルシステムと同様に作成する。そして本実施形態では、メタデータに、さらにファイルの乱数シード12345も保存する（ステップＳ２２）。
First, the
ファイルサイズに関しては、ファイル名から16KBであると判定し、それをファイルサイズとして保存する。また、16KB分のブロックをR-map上の空きブロックに割り当て、それらのブロック群の物理アドレスを、物理アドレスリスト４１に保存する（ステップＳ２３）。ここでは、ブロックサイズを4KBとし、R-map上のブロック100〜102、150の4ブロックが割り当てられたとする。すると、このファイルのメタデータ４０には、物理アドレスリスト４１として、R-map上の100,101,102,150の4つのアドレスが保存される。このとき、物理アドレスリスト４１は、ファイルを構成するブロックの順序で、各ブロックに対応する物理アドレスを並べて形成される。
As for the file size, it is determined that the file name is 16 KB, and it is stored as the file size. Also, blocks of 16 KB are allocated to empty blocks on the R-map, and the physical addresses of those block groups are stored in the physical address list 41 (step S23). Here, it is assumed that the block size is 4 KB and four
続いて、メタデータ逆引きマップ記憶部１６（R-map）を参照し、ブロック100のメタデータ識別子を参照する。ここでは、メタデータ識別子は未登録であり、ブロック100に対応するメタデータは存在しないため、単純に新しいメタデータ識別子500でR-mapのブロック100を上書きする（ステップＳ２４）。
Subsequently, the metadata reverse lookup map storage unit 16 (R-map) is referred to, and the metadata identifier of the
続いて、ブロック101のメタデータ識別子499を参照し、メタデータ識別子499に対応するメタデータ内の参照カウントを、2から1減らし、新しいメタデータ識別子500でR-mapのブロック101を上書きする。続いて、ブロック102のメタデータ識別子499を参照し、当該メタデータ識別子499に対応するメタデータ内の参照カウントを1から1減らし、新しいメタデータ識別子500でR-mapのブロック102を上書きする。すると、メタデータ識別子499のメタデータ内の参照カウントが0となったため、メタデータ識別子499のメタデータを削除する。続いて、ブロック150の識別子（未登録）を参照し、新しい識別子500で上書きする。 Subsequently, the metadata identifier 499 of the block 101 is referred to, the reference count in the metadata corresponding to the metadata identifier 499 is reduced by 1, and the block 101 of the R-map is overwritten with the new metadata identifier 500. Subsequently, the metadata identifier 499 of the block 102 is referred to, the reference count in the metadata corresponding to the metadata identifier 499 is reduced by 1, and the block 102 of the R-map is overwritten with the new metadata identifier 500. Then, since the reference count in the metadata of the metadata identifier 499 becomes 0, the metadata of the metadata identifier 499 is deleted. Subsequently, the identifier (unregistered) in block 150 is referred to and overwritten with a new identifier 500.
後は、実施形態１と同様に、当該ファイルが作成されるディレクトリ「/dir1」に当該ファイル名「file_16KB_12345」と、当該ファイルに対応するメタデータのメタデータ識別子50とをペアで登録して、ファイル名とメタデータと関連付ける（ステップＳ２５）。これでファイルの作成が完了したとして、仮想ファイルシステムはクライアントにファイル作成成功を返却する。
After that, as in the first embodiment, the file name “file_16KB_12345” and the
次に、「ファイルの削除」の具体例を説明する。実施形態１と同様に、ファイルの削除の場合には、ディレクトリ構造からファイル名とメタデータ識別子のペアを削除する。但し、本実施形態では、メタデータ４０自体は削除しない。メタデータ４０は、全てのR-map６０からの参照がなくなり、参照カウントが0になった時初めて削除される。
Next, a specific example of “file deletion” will be described. As in the first embodiment, when deleting a file, the file name and metadata identifier pair is deleted from the directory structure. However, in the present embodiment, the
次に、「ブロックの読み込み」の具体例を、図８のフローチャートを参照して説明する。クライアント２０が仮想ボリュームインターフェイス１２に、物理アドレス101で表されるブロック（ブロック101）の読み込みを要求する。R-map６０上のブロック101の物理アドレスにアクセスして、当該物理アドレスに格納されているメタデータ識別子500を取得し（ステップＳ３２）、当該メタデータ識別子500に対応するメタデータを検索する。
Next, a specific example of “block reading” will be described with reference to the flowchart of FIG. The
そして、検索したメタデータ４０に記憶されているファイルの乱数シード４２を取得する。また、検索したメタデータ４０の物理アドレスリスト４１から、アドレス100が何番目のブロックであるかを検索し、2番目のブロック（ブロックオフセット2）と確認する（ステップＳ３３）。続いて、取得したファイルの乱数シード12345とブロックオフセット2とを組み合わせた新たな乱数シード（ブロックシード）を生成する。そして、新たな乱数シードを用いて擬似乱数アルゴリズムを初期化して、擬似乱数アルゴリズムから4KB分の当該ブロックのデータを計算し（ステップＳ３４）、それをクライアントに返却する（ステップＳ３５）。
Then, the
また、クライアント２０が仮想ボリュームインターフェイス１２に、物理アドレス151で表されるブロック（ブロック151）の読み込みを要求したときの動作を説明する。R-mapのブロック151に対応する記憶領域にはメタデータ識別子が登録されておらず、対応するメタデータが無い。この場合、当該ブロックは一度もファイルに割り当てられたことがないことを示すため、全てのビットが0で構成された4KBのデータをクライアントに返却する。
The operation when the
ここで、ファイルの乱数シードを32bit、メタデータ識別子を24bit（ファイルを2^24-1=16777215個作成できると想定）とする。すると、ブロック毎の乱数シードは32（ファイルの乱数シード）＋32（ブロックオフセット）=64bitとなる。このため、実施形態１と同等の範囲を維持しているが、R-mapのサイズは24bit*2^32=12GBとなり、実施形態１及び２のS-mapよりも小さくなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。 Here, the random number seed of the file is 32 bits, and the metadata identifier is 24 bits (assuming that 2 ^ 24-1 = 16777215 files can be created). Then, the random number seed for each block is 32 (random number seed of the file) +32 (block offset) = 64 bits. For this reason, the range equivalent to that of the first embodiment is maintained, but the size of the R-map is 24 bits * 2 ^ 32 = 12 GB, which is smaller than the S-map of the first and second embodiments. In other words, a virtual file system and a virtual volume can be realized with a smaller capacity without storing actual block data.
また、上述したように、本実施形態におけるストレージシステム１０では、ブロック毎に当該ブロックのシード自体となる乱数シードを持つのではなく、ファイルのメタデータ４０毎に乱数シード４２を持ち、各々のブロックはメタデータの識別子を持つこととしている。そして、ファイル毎の乱数シード４２とブロックのオフセットとを組み合わせて、ブロックシードとなる新たな乱数シードを生成している。このため、ファイルのデータを変更する場合には、ファイルの乱数シード４２を変更すれば良く、R-map６０の更新は不要である。例えば、R-map６０が補助記憶装置に保存されている場合でもその更新が不要であるため、大量のファイルの更新が効率的に行え、かかる時間の削減を図ることができる。
Further, as described above, the
さらに、ファイルが削除されてもR-map６０から参照されている限りメタデータを削除しないようにし、別のメタデータ識別子で当該ブロックが上書きされ、全てのR-map６０からの参照がなくなった時に初めて当該メタデータを削除する。R-map６０からの参照がなくなったか否かを、参照数をカウントすることで判定するため、メタデータには参照カウント４３を追加する。この場合、R-map６０はS-map５０と同様に巨大になり、補助記憶装置に保存されることが考えられるが、本技術で想定しているボリュームバックアップでは、連続した物理アドレスにシーケンシャルにアクセスするため、空間的な局所性が有り、R-map６０を先読みしやすく、アクセス効率が良い。
Furthermore, even if a file is deleted, the metadata is not deleted as long as it is referenced from the R-
＜実施形態４＞
次に、本発明の第４の実施形態を説明する。本実施形態におけるストレージシステム１０は、実施形態３で説明したものとほぼ同様の構成をとっているが、以下の点で異なる。
<Embodiment 4>
Next, a fourth embodiment of the present invention will be described. The
まず、上述したように、本実施形態におけるメタデータ逆引きマップ記憶部１６のR-map６０は、対応するブロックが含まれるファイルに対応するメタデータ識別子を記憶している。これに加えて、R-map６０は、対応するブロックのファイル内における位置を表すオフセットの一部であるオフセットフラグメント（ブロック識別情報）を記憶している。このとき、オフセットフラグメントとしては、ブロックのオフセットの前後任意数のビットを落とし、残ったビットのみで形成されることとする。なお、オフセットフラグメントは、ファイルを構成する各ブロックを当該ファイル内において区別できる情報であれば、いかなる情報であってもよい。
First, as described above, the R-
そして、上記オフセットフラグメントは、物理アドレスリストから、元となるオフセットの上位ビット、下位ビットの未知の部分が求められ、当該オフセットに復元される。復元されたオフセットは、上述した実施形態４と同様に、ブロックに対応するメタデータ４０に記憶されているファイルの乱数シード４２と組み合わせられて、ブロックの乱数シードとして用いられる。
The offset fragment is obtained from the physical address list by obtaining the unknown bits of the upper and lower bits of the original offset and restoring the offset. The restored offset is combined with the
上記構成のストレージシステム１０において「ファイルの作成」の具体例を説明する。ここでは、ブロックオフセットを32bitとして、前8bit、後ろ8bitを除いたものをオフセットフラグメントとする。
A specific example of “file creation” in the
クライアント２０が仮想ファイルシステム１２にファイル「file_128GB_12345」を作成する場合には、まず、実施形態３と同様に、ディレクトリツリー構造への登録を行い、ファイル識別子500のメタデータを作成する。また、ファイルサイズ128GBに必要な33554432個の空きブロックを割り当て、それらの物理アドレスを当該メタデータ４０の物理アドレスリスト４１に先頭から順に保存する。ここで、ファイル先頭のブロック（ブロックオフセット0）としてブロック100、ファイルの先頭から601番目（ブロックオフセット600）のブロックとしてブロック200、16780001番目（ブロックオフセット16780000）のブロックとしてブロック201、が割り当てられたとする。
When the
続いて、ブロック100に対応するR-map更新では、ファイルのブロックオフセット0から前後8ビットを落としたブロックオフセット0とメタデータ識別子500のペアを、R-map６０に保存する。ブロック200に対するR-map更新では、ファイルのブロックオフセット600（0x00000258）から前後8ビットを落とした2(0x0002)とメタデータ識別子500のペアを、R-map６０に保存する。ブロック201に対するR-map更新では、ファイルのブロックオフセット16780000（0x01000AE0）から前後8ビットを落とした10(0x000A)とメタデータ識別子500のペアを、R-map６０に保存する。
Subsequently, in the R-map update corresponding to the
次に、「ブロックの読み込み」の具体例を説明する。クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス100のブロックを読み込む場合には、まずR-map６０からブロック100に対応するメタデータ識別子500とオフセットフラグメント0を求める。そして、メタデータ識別子500に対応するメタデータ４０を取得して、ファイルの乱数シード12345を取得する。また、メタデータ内の物理アドレスリスト４１を先頭から順次検索し、リストの先頭（ブロックオフセット0）にある当該ブロックの物理アドレス100を見つけ、当該ブロックのブロックオフセットを0と決定する。そして、ファイルの乱数シード12345とブロックオフセット0を組み合わせて、新たな乱数シードとして擬似乱数アルゴリズムを初期化し、4KBの乱数データを計算してクライアントに返却する。
Next, a specific example of “block reading” will be described. When the
クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス200のブロックを読み込む場合には、まず、R-map６０からブロック200に対応するメタデータ識別子500とオフセットフラグメント2を求める。そして、メタデータ識別子500に対応するメタデータを取得し、ファイルの乱数シード12345を取得する。また、オフセットフラグメント2に256（落とした下位ビットのビット数で２をべき乗したもの：2^8=256）を掛けて求めたブロックオフセット512から、物理アドレスリストの256個分を順次検索すると、88番目に物理アドレス200が見つかる。つまり、88+512=600であり、ファイルのブロックオフセットは600であることが計算される。後は、ファイルの乱数シード12345とブロックオフセット600を組み合わせて擬似乱数アルゴリズムを初期化し、4KBの乱数データを計算してクライアントに返却する。
When the
クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス201のブロックを読み込む場合には、まず、R-map６０からブロック200に対応するメタデータ識別子500とオフセットフラグメント10を求める。そして、メタデータ識別子500に対応するメタデータを取得し、ファイルの乱数シード12345を取得する。また、オフセットフラグメント10に256（落とした下位ビットのビット数で２をべき乗したもの：2^8=256）を掛けて求めたブロックオフセット2560から、物理アドレスリストの256個分を順次検索するが、見つからない。続いて、上記ブロックオフセット2560に16777216（ブロックオフセットのビット数から落とした上位ビットのビット数を引いたもので２をべき乗したもの：2^(32-8)=16777216）を足して、その場所（ブロックオフセット16779776）から、もう一度256個分の検索を行うと、224番目に物理アドレス201が見つかる。これにより、ブロックオフセットは、224+16779776=1678000と計算される。その後は、ファイルの乱数シード12345とブロックオフセット1678000を組み合わせて擬似乱数アルゴリズムを初期化し、4KBの乱数データを計算してクライアントに返却する。
When the
なお、上記から分かる通り、ブロックオフセットが16777216以上（64GB以上のファイルで出現）で初めて、上位8ビットが0で無くなるため、このサイズ未満のブロックオフセットでは必ず一回の検索でブロックが見つかる。同様に、128GBまでは高々2回のループで上位の未知ビットが求まる。 As can be seen from the above, for the first time when the block offset is 16777216 or more (appears in a file of 64 GB or more), the upper 8 bits are not 0. Therefore, if the block offset is less than this size, a block is always found by one search. Similarly, up to 128 GB, the upper unknown bits are obtained in two loops at most.
ここで、ファイルの乱数シードを32bit、メタデータ識別子を24bit（ファイルを2^24-1=16777215個作成できると想定）、オフセットフラグメントを16bitとする。すると、ブロック毎の乱数シードは32（ファイルの乱数シード）＋32（ブロックオフセット）=64bitとなる。このため、実施形態１と同等の範囲を維持しているが、R-mapのサイズは40bit*2^32=20GBとなり、実施形態１のS-mapよりも小さくなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。 Here, the random number seed of the file is 32 bits, the metadata identifier is 24 bits (assuming that 2 ^ 24-1 = 16777215 files can be created), and the offset fragment is 16 bits. Then, the random number seed for each block is 32 (random number seed of the file) +32 (block offset) = 64 bits. For this reason, the range equivalent to that of the first embodiment is maintained, but the size of the R-map is 40 bits * 2 ^ 32 = 20 GB, which is smaller than the S-map of the first embodiment. In other words, a virtual file system and a virtual volume can be realized with a smaller capacity without storing actual block data.
また、実施形態３と同様に、ファイルのメタデータ毎に乱数シードを持っているため、ファイルのデータを変更する場合には、ファイルの乱数シードのみを変更すれば良く、R-mapの更新は不要である。つまり、ファイル単位で乱数シードが操作でき、ファイルを少しずつ変更しながらバックアップを重ねる評価ができる。 Further, as in the third embodiment, since each file metadata has a random number seed, when changing the file data, it is only necessary to change the random number seed of the file. It is unnecessary. In other words, random number seeds can be manipulated on a file-by-file basis, and backups can be evaluated while changing files little by little.
ここで、上述した実施形態３では、物理アドレスは単純にブロックの並びの順にリスト化されているため、順次検索が必要で、二分探索やハッシュテーブル等の検索効率化ができない。これに対して、本実施形態では、ブロックのオフセットの前後任意数のビットを落とし、残ったビットをオフセットフラグメントとして、メタデータ識別子とともに、ブロック毎にR-mapに保存している。そして、オフセットフラグメントと物理アドレスリストから上位ビット、下位ビットの未知の部分を求め、オフセットに復元している。このとき、下位の未知のビットを求めるには単純にリストの順次検索を用いるため、空間的な局所性が有り、キャッシュ効率が良い。また、上位の未知のビットを求めるには飛び飛びの検索となるが、ファイルサイズが非常に大きくならないと上位未知ビットは0か小さい値となり、少ない回数のループで見つかる。このように、本実施形態では、オフセット検索のヒントとなるオフセットフラグメントをR-mapに記憶しているため、実施形態３と比較して、ブロックオフセットの計算（検索）効率が良く、性能が良い。 Here, in the above-described third embodiment, since the physical addresses are simply listed in the order of the block arrangement, sequential search is necessary, and search efficiency such as binary search and hash table cannot be achieved. On the other hand, in this embodiment, an arbitrary number of bits are dropped before and after the offset of the block, and the remaining bits are stored as an offset fragment in the R-map together with the metadata identifier for each block. Then, the unknown part of the upper and lower bits is obtained from the offset fragment and the physical address list, and restored to the offset. At this time, since a list sequential search is simply used to obtain lower unknown bits, there is spatial locality and cache efficiency is good. Further, in order to obtain the upper unknown bits, a search is skipped. However, if the file size does not become very large, the upper unknown bits become 0 or a smaller value and are found in a small number of loops. As described above, in this embodiment, offset fragments serving as hints for offset search are stored in the R-map. Therefore, compared to the third embodiment, the block offset calculation (search) efficiency is higher and the performance is better. .
ここで、上述した各実施形態におけるストレージシステムの変形例について説明する。
まず、実施形態１乃至４では、ブロックの乱数シードの計算に使われる、または、メタデータに保存されるファイルの乱数シードは、ファイル名に特定の書式で埋め込まれた値を利用しているが、別の方法でも良い。例えば、ファイル名のハッシュ値を求めて用いても良い。または、ファイルの先頭の特定ビット数分に書き込まれたデータを乱数シードとして用いる方法もある。もしくは、ファイル毎に特定の名前の代替データストリーム（フォークなどとも呼ばれる）でファイルの乱数シードを参照・変更できるようにしても良い。ファイルシステムの機能以外にブロックの乱数を操作するインターフェイスを用意しても良い。
Here, a modified example of the storage system in each embodiment described above will be described.
First, in the first to fourth embodiments, a random number seed of a file used for calculation of a random number seed of a block or stored in metadata uses a value embedded in a file name in a specific format. Another method may be used. For example, a hash value of the file name may be obtained and used. Alternatively, there is a method of using data written for a specific number of bits at the beginning of the file as a random number seed. Alternatively, the random number seed of the file may be referred to and changed with an alternative data stream (also called a fork) having a specific name for each file. In addition to the file system function, an interface for manipulating block random numbers may be prepared.
実施形態１，２では、S-mapに保存するブロックの乱数シードを、ファイルの乱数シードから計算しているが、別の方法でも良い。例えば、ファイルに書き込まれたデータをブロックの乱数シード列としてそのまま扱っても良い。または、ファイルに書き込まれたデータをブロック毎に区切り、ブロック毎に書き込まれたデータのハッシュ値を求めて、それをブロックの乱数シードとする方法もある。もしくは、ファイル毎に特定の名前の代替データストリームでブロック毎の乱数シードを参照・更新できるようにしても良い。ファイルシステムの一般的な機能以外にブロックの乱数を操作するインターフェイスを用意しても良い。 In the first and second embodiments, the random number seed of the block stored in the S-map is calculated from the random number seed of the file, but another method may be used. For example, data written in a file may be handled as it is as a random number seed sequence of blocks. Alternatively, there is a method in which data written to a file is divided into blocks, a hash value of data written for each block is obtained, and this is used as a random number seed for the block. Alternatively, the random number seed for each block may be referred to / updated with an alternative data stream having a specific name for each file. In addition to the general functions of the file system, an interface for manipulating block random numbers may be provided.
実施形態２では、ボリュームの乱数シードを変更するために、ルートディレクトリ上の特定の名前のファイルにシード値を書き込むとしているが、別の方法でも良い。たとえば書き込まれた値をそのまま乱数シード値として用いるのではなく、ハッシュ関数等の変換を行っても良い。もしくは、仮想ボリュームインターフェイスがボリュームラベルをサポートとするようにして、ボリュームラベルに特定の書式で乱数シードを埋め込み、その値をボリュームの乱数シードにする方法がある（「volume_seed_34567」というボリュームラベルを設定すると、ボリュームの乱数シードを34567とするなど）。その他、ボリュームの先頭ブロックなど特定の場所に書き込まれた値を乱数シードとしても良い。もしくは、乱数を操作するためのインターフェイスを仮想ボリュームインターフェイスに用意しても良い。 In the second embodiment, the seed value is written in a file with a specific name on the root directory in order to change the random number seed of the volume. However, another method may be used. For example, instead of using the written value as the random number seed value as it is, conversion such as a hash function may be performed. Alternatively, the virtual volume interface can support volume labels, and a random number seed can be embedded in the volume label in a specific format, and that value can be used as the volume random number seed (if you set the volume label "volume_seed_34567") , And the volume random number seed is 34567). In addition, a value written in a specific location such as the first block of the volume may be used as the random number seed. Alternatively, an interface for manipulating random numbers may be provided in the virtual volume interface.
実施形態２では、ボリューム全体の乱数シードとして１つの値を利用しているが、ボリュームを物理アドレスから容易に識別可能な複数のエリアに分割し、エリア毎に個別の乱数シードを設定しても良い。 In the second embodiment, one value is used as the random number seed for the entire volume. However, even if the volume is divided into a plurality of areas that can be easily identified from the physical address, individual random number seeds are set for each area. good.
実施形態３，４では、ファイルを削除してもブロックのデータが変更されないようにするため、ファイルを削除してもR-mapからの参照が無くなるまではメタデータを削除しないようにしているが、ファイル削除時にブロックのデータが変更されても良い場合には、メタデータを削除し、R-mapからメタデータ識別子を削除しても良い。この場合、削除後のブロックからは全ビットが0のデータが読まれるようにする。 In the third and fourth embodiments, in order to prevent the block data from being changed even if the file is deleted, the metadata is not deleted until the reference from the R-map disappears even if the file is deleted. If the block data may be changed when the file is deleted, the metadata may be deleted and the metadata identifier may be deleted from the R-map. In this case, the data after all bits are read from the deleted block.
ファイルが割り当てられていないブロックからは全ビットが0のデータが読まれることとしているが、再現性のあるデータが読まれるのならば0でなくても良い。例えば、全ブロックで特定のデータを返すようにしても良い。もしくは、物理アドレスを乱数シードとして擬似乱数アルゴリズムで求めたデータを用いても良い。 It is assumed that data with all bits 0 is read from a block to which no file is assigned, but it may not be 0 if reproducible data is read. For example, specific data may be returned in all blocks. Alternatively, data obtained by a pseudorandom algorithm using a physical address as a random number seed may be used.
メタデータに含まれている物理アドレスリストの記憶方法については、単純なリストを想定しているが、次のようにして圧縮することも考えられる。１つのファイルは一般的になるべく連続したブロックに割り当てられるため、物理アドレスリストは連続した数値になっている部分が多い。よってランレングス符号化のように、連続した部分の先頭アドレス、連続しているアドレスの数のペアをリストにすると、物理アドレスリストを単純な方法で効率的に圧縮できる。また、更に一定の単位でアドレスリストを分割しておく（例えば2^12=4096個単位）と、物理アドレスリストをランダムアクセスする場合でもある程度効率的に圧縮データを伸張できる。例えば、10000番目の物理アドレスを参照する場合は、8192番目のブロック（2個めの分割単位）から検索を始める、などである。 As a method for storing the physical address list included in the metadata, a simple list is assumed. However, compression may be performed as follows. Since one file is generally assigned to consecutive blocks as much as possible, the physical address list has a lot of continuous numerical values. Therefore, as in the case of run-length encoding, if the pair of the head address of the continuous part and the number of the continuous addresses are listed, the physical address list can be efficiently compressed by a simple method. Further, if the address list is further divided in a certain unit (for example, 2 ^ 12 = 4096 units), even when the physical address list is randomly accessed, the compressed data can be decompressed to some extent efficiently. For example, when referring to the 10000th physical address, the search is started from the 8192th block (second division unit).
ボリュームへデータを書き込む場合、当該ブロックから読み込まれるはずのデータと比較し、異なる場合にはエラーとしているが、他の方法も考えられる。例えば、何もせずに破棄しても良い。この場合、比較処理のために乱数データを計算する必要がなく、より高い性能が求められる場合に有効である。もしくは、エラーとはしないが、異なった場所の物理アドレスのリストをとっておき、後で参照できるようにしても良い。 When writing data to the volume, it is compared with the data that should be read from the block, and if it is different, it is considered as an error. For example, you may discard without doing anything. In this case, it is not necessary to calculate random number data for the comparison process, which is effective when higher performance is required. Alternatively, although it is not an error, a list of physical addresses at different locations may be kept so that they can be referred to later.
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム（図９参照）、プログラム、情報処理方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。
<Appendix>
Part or all of the above-described embodiment can be described as in the following supplementary notes. The outline of the configuration of the storage system (see FIG. 9), program, and information processing method in the present invention will be described below. However, the present invention is not limited to the following configuration.
（付記１）
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
ストレージシステム。
(Appendix 1)
Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
With
Storage system.
上記発明によると、ファイルの実データを記憶することなく、仮想ファイルシステムを構築できると共に、物理アドレスからブロック単位でボリューム操作も行うことができる。具体的には、まず、ファイルのメタデータから当該ファイルを構成するブロックの参照先となる物理アドレスを参照して、ブロックシードを特定する情報からブロックシードを特定する。そして、ブロックシードから疑似乱数生成アルゴリズムなどを用いてブロックのデータを生成して、ブロックのデータからファイルを生成する。これにより、仮想ファイルシステムを構築することができる。また、物理アドレスを参照して上述同様にブロックシードを特定し、ブロックのデータを生成することで、仮想ボリュームも構築することができる。 According to the above invention, a virtual file system can be constructed without storing actual file data, and volume operations can be performed in units of blocks from physical addresses. Specifically, first, the block seed is specified from the information for specifying the block seed by referring to the physical address that is the reference destination of the block constituting the file from the metadata of the file. Then, block data is generated from the block seed using a pseudo random number generation algorithm or the like, and a file is generated from the block data. Thereby, a virtual file system can be constructed. A virtual volume can also be constructed by specifying a block seed with reference to a physical address and generating block data in the same manner as described above.
これにより、上記ボリュームをバックアップやリストアの評価用に使用する場合であっても、当該ボリュームを構成するブロックの実データを記憶することがないため、ストレージシステムの容量を低減させることができる。また、ボリュームの作成や変更の際には、ブロックシードを特定する情報を操作すればよいため、かかる時間の低減を図ることができる。 As a result, even when the volume is used for backup or restore evaluation, the actual data of the blocks constituting the volume is not stored, so that the capacity of the storage system can be reduced. In addition, when creating or changing a volume, information for specifying a block seed may be manipulated, so that the time required can be reduced.
（付記２）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
ストレージシステム。
(Appendix 2)
The storage system according to attachment 1, wherein
The block map storage means stores the block seed itself as information for specifying the block seed.
Storage system.
（付記３）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックデータ生成手段は、前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
(Appendix 3)
The storage system according to attachment 1, wherein
The block map storage means stores information forming a part of the block seed as information specifying the block seed,
The block data generation unit forms information forming another part of the block seed set for the volume formed by the block and a part of the block seed which is information for specifying the block seed. Block seed is identified from the information, and block data is generated from the block seed.
Storage system.
上記発明によると、ブロックシードは、ボリューム毎に定められた情報と物理アドレスに格納された情報とから特定される。このため、ボリューム毎に定められた情報を変更することで、全体的に新たなブロックのデータを生成でき、容易にボリュームの生成、変更を行うことができる。 According to the above invention, the block seed is specified from information determined for each volume and information stored in the physical address. For this reason, by changing the information determined for each volume, data of a new block can be generated as a whole, and the volume can be easily generated and changed.
（付記４）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータ記憶手段は、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
(Appendix 4)
The storage system according to attachment 1, wherein
The block map storage means stores, as information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to a file including a block;
The metadata storage means stores, in the metadata, at least block identification information that is information different for each block in the file, and a file seed that is information different for each file,
The block data generation means refers to the metadata corresponding to the file containing the block from the metadata identifier that is information for specifying the block seed, and the block identification information stored in the metadata Identifying the block seed from the file seed and generating block data from the block seed;
Storage system.
（付記５）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータ記憶手段は、前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
(Appendix 5)
The storage system according to attachment 1, wherein
The block map storage means includes, as information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to a file including a block, and block identification information that is at least different information for each block in the file. Remember,
The metadata storage means stores, in the metadata, a file seed that is different information for each file,
The block data generation means refers to the metadata corresponding to a file including a block from the metadata identifier that is information for specifying the block seed, and the file seed stored in the metadata; Identifying the block seed from the block identification information, which is information identifying the block seed, and generating block data from the block seed,
Storage system.
（付記６）
付記４又は５に記載のストレージシステムであって、
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
ストレージシステム。
(Appendix 6)
The storage system according to appendix 4 or 5, wherein
The block identification information is information formed by at least part of offset information indicating the position of the block in the file.
Storage system.
上記発明によると、ブロックシードは、ファイル毎に定められたファイルシードと、ファイル内におけるブロックを識別する情報（例えば、ファイル内におけるブロックの位置を表すオフセット情報）と、から特定される。このため、ファイルシードを変更することで、ファイル毎にデータの変更等の操作を容易に行うことができる。 According to the above invention, the block seed is specified from the file seed determined for each file and the information for identifying the block in the file (for example, offset information indicating the position of the block in the file). For this reason, by changing the file seed, it is possible to easily perform operations such as changing data for each file.
（付記７）
付記１乃至５のいずれかに記載のストレージシステムであって、
前記メタデータ記憶手段に記憶された前記メタデータを参照して、ファイルを構成するブロックに対応する前記物理アドレスを特定し、当該物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからファイルを生成することにより仮想的なファイルシステムを構築する仮想ファイルシステム構築部と、
前記物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからボリュームを生成することにより仮想的なボリュームを構築する仮想ボリューム構築部と、
を備えたストレージシステム。
(Appendix 7)
The storage system according to any one of appendices 1 to 5,
With reference to the metadata stored in the metadata storage means, the physical address corresponding to the block constituting the file is specified, and the block data generated by the block data generation means is identified using the physical address. A virtual file system construction unit that constructs a virtual file system by generating a file from data;
A virtual volume construction unit that constructs a virtual volume by creating a volume from block data generated by the block data generation means using the physical address;
Storage system with
（付記８）
情報処理装置に、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させるためのプログラム。
(Appendix 8)
In the information processing device,
Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
A program to realize
（付記９）
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶すると共に、前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶し、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
(Appendix 9)
For each file, metadata including physical address information that specifies a storage area that is a reference destination of a block that constitutes the file is stored, and data of the block is stored in the storage area that is specified by the physical address. Stores information that identifies the block seed from which to generate,
Identifying the block seed based on information identifying the block seed stored in the storage area identified by the physical address, and generating block data from the block seed,
Information processing method.
（付記１０）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
情報処理方法。
(Appendix 10)
An information processing method according to attachment 9, wherein
As the information specifying the block seed, the block seed itself is stored.
Information processing method.
（付記１１）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
(Appendix 11)
An information processing method according to attachment 9, wherein
As information for specifying the block seed, storing information forming a part of the block seed,
A block seed is determined from information forming another part of the block seed set for the volume formed by the block and information forming a part of the block seed, which is information for specifying the block seed. Identify and generate block data from the block seed,
Information processing method.
（付記１２）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
(Appendix 12)
An information processing method according to attachment 9, wherein
As the information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to the file including the block is stored,
In the metadata, at least block identification information that is information different for each block in the file, and file seed that is information different for each file are stored,
By referring to the metadata corresponding to the file including the block from the metadata identifier that is information for specifying the block seed, the block is determined from the block identification information stored in the metadata and the file seed. Identify the seed and generate block data from the block seed.
Information processing method.
（付記１３）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
(Appendix 13)
An information processing method according to attachment 9, wherein
As the information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to the file including the block, and at least block identification information that is different for each block in the file are stored,
In the metadata, a file seed that is different information for each file is stored,
Information for specifying the block seed and the file seed stored in the metadata with reference to the metadata corresponding to the file including the block from the metadata identifier which is information for specifying the block seed Identifying the block seed from the block identification information, and generating block data from the block seed,
Information processing method.
（付記１４）
付記１２又は１３に記載のストレージシステムであって、
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
情報処理方法。
(Appendix 14)
The storage system according to
The block identification information is information formed by at least part of offset information indicating the position of the block in the file.
Information processing method.
なお、上述したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。 Note that the above-described program is stored in a storage device or recorded on a computer-readable recording medium. For example, the recording medium is a portable medium such as a flexible disk, an optical disk, a magneto-optical disk, and a semiconductor memory.
以上、上記実施形態等を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。 Although the present invention has been described with reference to the above-described embodiment and the like, the present invention is not limited to the above-described embodiment. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.
１０ ストレージシステム
１１ 仮想ファイルシステム
１２ 仮想ボリュームインタフェース
１３ ディレクトリツリー構造記憶部
１４ ファイルメタデータ記憶部
１５ 乱数シードマップ記憶部
１６ メタデータ逆引きマップ記憶部
２０ クライアント
３０ 評価対象ストレージシステム
３１ 評価対象ストレージ
４０ メタデータ
４１ 物理アドレスリスト
４２ ファイル乱数シード
４３ 参照カウント
５０ 乱数シードマップ
６０ メタデータ逆引きマップ
１００ ストレージシステム
１１０ ブロックデータ生成手段
１２０ メタデータ記憶手段
１３０ ブロックマップ記憶手段
10 Storage System 11
Claims (10)
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
ストレージシステム。 Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
With
Storage system.
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
ストレージシステム。 The storage system according to claim 1,
The block map storage means stores the block seed itself as information for specifying the block seed.
Storage system.
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックデータ生成手段は、前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。 The storage system according to claim 1,
The block map storage means stores information forming a part of the block seed as information specifying the block seed,
The block data generation unit forms information forming another part of the block seed set for the volume formed by the block and a part of the block seed which is information for specifying the block seed. Block seed is identified from the information, and block data is generated from the block seed.
Storage system.
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータ記憶手段は、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。 The storage system according to claim 1,
The block map storage means stores, as information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to a file including a block;
The metadata storage means stores, in the metadata, at least block identification information that is information different for each block in the file, and a file seed that is information different for each file,
The block data generation means refers to the metadata corresponding to the file containing the block from the metadata identifier that is information for specifying the block seed, and the block identification information stored in the metadata Identifying the block seed from the file seed and generating block data from the block seed;
Storage system.
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータ記憶手段は、前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。 The storage system according to claim 1,
The block map storage means includes, as information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to a file including a block, and block identification information that is at least different information for each block in the file. Remember,
The metadata storage means stores, in the metadata, a file seed that is different information for each file,
The block data generation means refers to the metadata corresponding to a file including a block from the metadata identifier that is information for specifying the block seed, and the file seed stored in the metadata; Identifying the block seed from the block identification information, which is information identifying the block seed, and generating block data from the block seed,
Storage system.
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
ストレージシステム。 The storage system according to claim 4 or 5,
The block identification information is information formed by at least part of offset information indicating the position of the block in the file.
Storage system.
前記メタデータ記憶手段に記憶された前記メタデータを参照して、ファイルを構成するブロックに対応する前記物理アドレスを特定し、当該物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからファイルを生成することにより仮想的なファイルシステムを構築する仮想ファイルシステム構築部と、
前記物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからボリュームを生成することにより仮想的なボリュームを構築する仮想ボリューム構築部と、
を備えたストレージシステム。 The storage system according to any one of claims 1 to 5,
With reference to the metadata stored in the metadata storage means, the physical address corresponding to the block constituting the file is specified, and the block data generated by the block data generation means is identified using the physical address. A virtual file system construction unit that constructs a virtual file system by generating a file from data;
A virtual volume construction unit that constructs a virtual volume by creating a volume from block data generated by the block data generation means using the physical address;
Storage system with
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させるためのプログラム。 In the information processing device,
Metadata storage means for storing, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file;
Block map storage means for storing information for specifying a block seed that is a source for generating data of the block in the storage area specified by the physical address;
Block data generating means for specifying the block seed based on information for specifying the block seed stored in the storage area specified by the physical address, and generating block data from the block seed;
A program to realize
前記情報処理装置が、前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。 The information processing apparatus stores, for each file, metadata including information on a physical address that specifies a storage area that is a reference destination of a block constituting the file, and a storage area specified by the physical address, Storing information identifying a block seed that is a source for generating the block data;
The information processing device identifies the block seed based on information identifying the block seed stored in the storage area identified by the physical address, and generates block data from the block seed.
Information processing method.
前記情報処理装置が、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶すると共に、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記情報処理装置が、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
An information processing method according to claim 9,
The information processing apparatus stores, as information for specifying the block seed, a metadata identifier for specifying the metadata corresponding to the file including the block, and the metadata is different for each block at least in the file. Storing block identification information, which is information, and file seed, which is different information for each file,
The information processing apparatus refers to the metadata corresponding to a file including a block from the metadata identifier that is information for specifying the block seed, and the block identification information stored in the metadata and the metadata The block seed is identified from the file seed, and block data is generated from the block seed.
Information processing method.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014050104A JP6295742B2 (en) | 2014-03-13 | 2014-03-13 | Storage system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014050104A JP6295742B2 (en) | 2014-03-13 | 2014-03-13 | Storage system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015176205A JP2015176205A (en) | 2015-10-05 |
| JP6295742B2 true JP6295742B2 (en) | 2018-03-20 |
Family
ID=54255396
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014050104A Active JP6295742B2 (en) | 2014-03-13 | 2014-03-13 | Storage system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6295742B2 (en) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4252102B2 (en) * | 1993-06-21 | 2009-04-08 | 株式会社日立製作所 | Computer system and secondary storage device |
| US7181641B2 (en) * | 2003-09-24 | 2007-02-20 | Hitachi Global Storage Technologies Netherlands, B.V. | Data storage verification techniques for disk drivers |
| JP5664318B2 (en) * | 2011-02-17 | 2015-02-04 | 日本電気株式会社 | Virtual file system |
| JP5953808B2 (en) * | 2012-02-23 | 2016-07-20 | 日本電気株式会社 | Random number processing apparatus, random number processing method, and program |
-
2014
- 2014-03-13 JP JP2014050104A patent/JP6295742B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2015176205A (en) | 2015-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10402339B2 (en) | Metadata management in a scale out storage system | |
| CN103098035B (en) | Storage system | |
| JP6200886B2 (en) | Logical sector mapping in flash storage arrays | |
| JP6304406B2 (en) | Storage apparatus, program, and information processing method | |
| JP6240071B2 (en) | Computer system and method for effectively managing mapping table in storage system | |
| US9430164B1 (en) | Memory efficient sanitization of a deduplicated storage system | |
| JP5445682B2 (en) | Storage system | |
| JP6124902B2 (en) | Variable length coding in storage systems | |
| US7194579B2 (en) | Sparse multi-component files | |
| JP5695040B2 (en) | File system | |
| US20140297603A1 (en) | Method and apparatus for deduplication of replicated file | |
| CN106105161A (en) | To cloud data storage device Backup Data while maintaining storage efficiency | |
| US8825653B1 (en) | Characterizing and modeling virtual synthetic backup workloads | |
| CN109313538A (en) | Inline duplicate removal | |
| US10649682B1 (en) | Focused sanitization process for deduplicated storage systems | |
| JP6807395B2 (en) | Distributed data deduplication in the processor grid | |
| CN112612576B (en) | Virtual machine backup method and device, electronic equipment and storage medium | |
| CN105493080B (en) | The method and apparatus of data de-duplication based on context-aware | |
| CN104751076A (en) | Method for recovering disk data | |
| CN107798063B (en) | Snapshot processing method and snapshot processing device | |
| CN110187834B (en) | Data processing method and device for duplicate copies and electronic equipment | |
| CN104484402B (en) | A kind of method and device of deleting duplicated data | |
| US9594635B2 (en) | Systems and methods for sequential resilvering | |
| JP5664318B2 (en) | Virtual file system | |
| JP6295742B2 (en) | Storage system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170206 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20171129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20171205 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180104 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180123 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180205 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6295742 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |