(57)【要約】【課題】ボリュームの容量増加や、ボリュームの作成や変更に多大な時間を要すること。【解決手段】本発明のストレージシステム１００は、ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段１２０と、物理アドレスにて特定される記憶領域に、ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段１３０と、物理アドレスにて特定される記憶領域に記憶されているブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段１１０と、を備えた。【選択図】図９
2015176205.tif 000002
【特許請求の範囲】
【請求項１】
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
ストレージシステム。
【請求項２】
請求項１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
ストレージシステム。
【請求項３】
請求項１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックデータ生成手段は、前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【請求項４】
請求項１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータ記憶手段は、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【請求項５】
請求項１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータ記憶手段は、前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【請求項６】
請求項４又は５に記載のストレージシステムであって、
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
ストレージシステム。
【請求項７】
請求項１乃至５のいずれかに記載のストレージシステムであって、
前記メタデータ記憶手段に記憶された前記メタデータを参照して、ファイルを構成するブロックに対応する前記物理アドレスを特定し、当該物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからファイルを生成することにより仮想的なファイルシステムを構築する仮想ファイルシステム構築部と、
前記物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからボリュームを生成することにより仮想的なボリュームを構築する仮想ボリューム構築部と、
を備えたストレージシステム。
【請求項８】
情報処理装置に、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させるためのプログラム。
【請求項９】
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶すると共に、前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶し、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【請求項１０】
請求項９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶すると共に、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージシステムにかかり、特に、仮想的なボリュームを有するストレージシステムに関する。
【背景技術】
【０００２】
バックアップソフトウェアを用いて、ストレージシステムのボリュームを評価対象のストレージシステムでバックアップする、あるいは、リストアする場合に、バックアップの評価やリストアの評価を行うことがある。バックアップの評価では、ストレージシステム上に作成したテスト用のボリュームを、評価対象のストレージシステムにバックアップする。リストアの評価では、評価対象のストレージシステムにバックアップしたボリュームを元のストレージシステム上にリストアし、バックアップ前のボリュームと比較する。この場合、テスト用のボリュームを作成したり、比較するためのストレージシステム、および、比較ソフトウェアが必要となる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−１６８９０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところが、近年、ストレージシステムの高性能化、高機能化により、テストボリュームについて以下の変化が出てきている。第１に、ストレージシステムの高性能化により、高速かつ大容量となったため、ボリュームのサイズが肥大化している。第２に、ストレージシステムが圧縮や重複排除などの機能を持つようになったため、重複排除されないデータの評価を行う際にテストボリュームを毎回作り直さなければならない。これらの変化により、テストボリュームを作成するための高性能、大容量なストレージシステムを用意するコストがかかる。また、巨大なテストボリュームを毎回作成しなおすために膨大な時間がかかる、という問題が出てきている。
【０００５】
また、特に重複排除機能を持つストレージシステムに対してボリュームのフルバックアップを日次や週次で行うシステムの場合、フルバックアップ毎に前回のバックアップと同じ部分は重複排除されることとなる。このようなシステムにおけるバックアップを何度も繰り返して、ストレージシステムへの影響を調べる評価を行う場合、テストボリューム内のシステムの運用状況に合わせてファイルの更新（作成・削除など含む）をシミュレーションする必要がある。しかし、実際のストレージ上に用意したテストボリュームに対してこのファイル更新のシミュレーションを行うと、ボリュームへの多くの書き込み操作が必要なため、シミュレーションに時間がかかる。このため、多くの回数のバックアップの評価を行う場合に、多大な時間を要するという問題が有る。
【０００６】
ここで、特許文献１における仮想ファイルシステムでは、ファイルシステム単位のバックアップを行う場合に関して、ファイルの作成、削除等が行え、データ保存用のストレージを必要としない評価用のファイルシステムを提供している。ところが、この技術では、ファイルシステムとしてのみデータ読み込みが可能であるが、ボリュームバックアップ等、物理アドレスによるボリューム操作を行うことができない。以上より、依然として、テストボリューム用のストレージシステムの容量増加や、テストボリュームの作成や変更に多大な時間を要する、という問題が生じる。
【０００７】
このため、本発明の目的は、上述した課題である、ボリューム用のストレージシステムの容量増加や、ボリュームの作成や変更に多大な時間を要する、ということを解決することにある。
【課題を解決するための手段】
【０００８】
本発明の一形態であるストレージシステムは、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
という構成をとる。
【０００９】
また、本発明の一形態であるプログラムは、
情報処理装置に、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させる、
という構成をとる。
【００１０】
また、本発明の一形態である情報処理方法は、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶すると共に、前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶し、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
という構成をとる。
【発明の効果】
【００１１】
本発明は、以上のように構成されることにより、ボリューム用のストレージシステムの容量を低減し、ボリュームの作成や変更にかかる時間を短縮することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態１におけるストレージシステムを含むシステム全体の構成を示すブロック図である。
【図２】図１に開示したストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。
【図３】図１に開示したストレージシステムにおけるファイル作成時の動作を示すフローチャートである。
【図４】図１に開示したストレージシステムにおけるブロック読み込み時の動作を示すフローチャートである。
【図５】本発明の実施形態２におけるストレージシステムを含むシステム全体の構成を示すブロック図である。
【図６】図５に開示したストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。
【図７】図５に開示したストレージシステムにおけるファイル作成時の動作を示すフローチャートである。
【図８】図５に開示したストレージシステムにおけるブロック読み込み時の動作を示すフローチャートである。
【図９】本発明の付記１におけるストレージシステムの構成を示すブロック図である。
【発明を実施するための形態】
【００１３】
＜実施形態１＞
本発明の第１の実施形態を、図１乃至図４を参照して説明する。図１は、システム全体の構成を示すブロック図である。図２は、ストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。図３は、ストレージシステムにおけるファイル作成時の動作を示すフローチャートであり、図４は、ブロック読み込み時の動作を示すフローチャートである。
【００１４】
図１に示す情報処理システムは、ランダムデータファイルを持つ仮想ボリュームを構築するストレージシステム１０を備えている。そして、このストレージシステム１０により、後述するように、ボリュームの実データをストレージ上に格納することなく、仮想的なファイルシステムからファイルの作成、削除といった一般的なファイル操作を行え、かつ、物理アドレスでボリュームに対して読み書き操作ができる仮想的なボリュームを提供する。
【００１５】
そして、情報処理システムは、ストレージシステム１０のボリュームのバックアップ先及びリストア元となり、当該バックアップの評価やリストアの評価対象となる評価対象ストレージ３１を有する評価対象ストレージシステム３０を備えている。また、情報処理システムは、ボリュームのバックアップやリストアの操作を行うクライアント３０を備えている。
【００１６】
上記ストレージシステム１０は、図１に示すように、装備された演算装置にプログラムが組み込まれることで構築された、仮想ファイルシステム１１と仮想ボリュームインタフェース１２とを備えている。また、ストレージシステム１０は、装備された記憶装置に形成された、ディレクトリツリー構造記憶部１３、ファイルメタデータ記憶部１４、乱数シードマップ記憶部１５、を備えている。以下、各構成について詳述する。
【００１７】
ディレクトリツリー構造記憶部１３は、ファイルシステムにおけるディレクトリのツリー構造を保存するための記憶領域である。ディレクトリには、ファイル名と、ファイルに対応するメタデータを識別するための識別子と、がペアで保存されることで、図２に示すように、ファイルとメタデータとが関連付けられる。また、ディレクトリには、サブディレクトリ名と、そのサブディレクトリのデータ（再帰的にサブディレクトリ内の、ファイル名と識別子のペアや、サブディレクトリ名とデータ情報のペアなど）が関連付けられる。
【００１８】
ファイルメタデータ記憶部１４（メタデータ記憶手段）は、個々のファイルのメタデータを保存する記憶領域で、識別子から対応するメタデータを検索することができる。具体的にメタデータ４０は、図２に示すように、ファイルのサイズ、作成日付、属性、アクセス許可設定など、ファイルシステムが一般的に持つファイルの実データ以外の付随情報を含む。そして、本発明におけるメタデータ４０は、さらに、ファイルがボリュームのどのブロックを利用しているかを示す、ブロックの物理アドレスリスト４１を含む。つまり、物理アドレスリスト４１に記憶される各物理アドレスは、ファイルを構成する各ブロックのそれぞれの参照先となる乱数シードマップ５０内の記憶領域を特定するアドレスである。
【００１９】
乱数シードマップ記憶部１５は、乱数シードマップ５０（S-map）を記憶している。乱数シードマップ５０は、ボリュームのブロック毎の乱数シード（ブロックシード）を保存する表であり、ブロックの物理アドレスから乱数シードを求めるのに使用される表である。なお、本実施形態では、ブロックの乱数シードは、当該ブロックの実データを生成するための元となる情報であり、かかる乱数シードから、後述するように疑似乱数アルゴリズムを用いて、ブロックの実データを生成する。つまり、本実施形態では、ブロックの実データは記憶していない。
【００２０】
仮想ファイルシステム１１（ブロックデータ生成手段、仮想ファイルシステム構築部）は、上述したディレクトリツリー構造記憶部１３、ファイルメタデータ記憶部１４及び乱数シードマップ記憶部１５内の情報を参照、更新することで、クライアント２０に対してファイルシステムを表現する。そして、仮想ファイルシステム１１は、クライアント２０がファイル単位の操作を可能としている。
【００２１】
仮想ボリュームインターフェイス１２（ブロックデータ生成手段、仮想ボリューム構築部）は、上述した乱数シードマップ記憶部１５内の情報を参照することで、ボリュームを表現し、ブロック単位の操作を可能としている。
【００２２】
クライアント２０は、ボリュームを準備するために、仮想ファイルシステム１１を用いてファイル、ディレクトリの作成や削除等のファイルシステムを操作するコンピュータである。また、クライアント２０は、ボリュームを準備するために、バックアップソフトウェアを用いて、仮想ボリュームインターフェイス１２に対してブロック単位の読み込み、書き込みを行ったり、それらのブロック単位のデータを評価対象ストレージシステム３０にバックアップ、リストアする操作を行うコンピュータである。
【００２３】
評価対象ストレージシステム３０は、上述したストレージシステム１に記憶されている仮想ボリュームがバックアップされたり、リストアされることにより、バックアップやリストアの評価の対象となるストレージシステムである。
【００２４】
次に、上述したストレージシステム１０に構築される仮想ボリュームへの操作、具体的に、ファイルの作成、ファイルの更新／削除、ボリュームの読み込み、ボリュームの書き込み、について、詳しく説明する。なお、ここで説明しないファイルシステム操作（ディレクトリ作成・削除、名前の変更、属性変更など）は、全て通常のファイルシステムと同様に、ディレクトリツリー構造／メタデータを参照、または更新することで可能である。
【００２５】
まず、「ファイルの作成」について説明する。ファイルは、格納するデータの乱数シード列を与えて作成する。仮想ファイルシステムは、通常のファイルシステムと同様に、仮想ボリューム上のどの部分にファイルのデータを置くかを決定し（ブロックの割り当て）、各々のブロックのデータの元となるブロックシードを更新する。そして、ファイルのメタデータとして、ファイルが使用するブロックの参照先のリスト（物理アドレスのリスト）を保存する。ここで、ブロックの乱数シードに関しては、ファイル名に特定の書式で埋め込まれた乱数シード値から擬似乱数アルゴリズムによって、ファイルが使うブロックの乱数シードをファイルの先頭から順に決定する。
【００２６】
上述した「ファイルの作成」の具体例を、図３のフローチャートを参照して説明する。まず、クライアント２０は、仮想ファイルシステム１１に対して、「/dir1/file_16KB_12345」という名前のファイルの作成を要求する。仮想ファイルシステム１１は、このファイルに対応するファイルメタデータ（識別子500とする）を作成する（ステップＳ１）。メタデータに含まれる日付、アクセス許可情報や属性等は、一般的なファイルシステムと同様に作成する。ファイルサイズに関しては、ファイル名から16KBであると判定し、それをファイルサイズとして保存する。
【００２７】
そして、16KB分の空きブロックをファイルに割り当て（ステップＳ２）、それらのブロック群への物理アドレスのリスト４１を保存する。なお、一般的には、ファイルシステムは空きブロックをビットマップやリンクリスト等で管理しており、それらを用いて空きブロックを割り当てるが、ここでは本技術に直接関係ないため、詳細な説明は省略する。そして、ブロックサイズを4KBとし、ブロック100,101,102,150の4ブロックが割り当てられたとすると、このファイルのメタデータには、物理アドレスリスト４１として、100,101,102,150の4つのアドレスが保存される（ステップＳ３）。
【００２８】
続いて、ファイル名から乱数シード12345を用いて擬似乱数アルゴリズムを初期化し、4つの乱数を計算し、乱数12345, 67890, 35791, 46802を得たとする。この場合には、ブロック100の乱数シードとして12345、ブロック101の乱数シードとして67890、ブロック102の乱数シードとして35791、ブロック150の乱数シードとして46802を使うこととし、乱数シードマップ５０（S-map）上のこれら4ブロックの値を更新する（ステップＳ４）。
【００２９】
その後、仮想ファイルシステム１１は、当該ファイルが作成されるディレクトリ「/dir1」に当該ファイル名「file_16KB_12345」と、当該ファイルのメタデータの識別子50とをペアで登録して、ファイル名とメタデータと関連付ける（ステップＳ５）。これでファイルの作成が完了したとして、仮想ファイルシステム１１はクライアント２０にファイル作成成功を返却する。
【００３０】
そして、仮想ファイルシステム１１は、以下のようにしてファイルシステムを表現する。例えば、ファイルの読み出しを要求された場合には、まずファイルのメタデータ４０を参照して、ファイルを構成するブロックの物理アドレス４１を特定する。そして、後述する「ボリュームの読み込み」の処理と同様に、物理アドレス４１を用いてブロックの乱数シードを特定し、当該乱数シードからブロックのデータを生成して、ファイルを生成する。これにより、仮想的なファイルシステムを実現する。
【００３１】
次に、「ファイルの更新や削除」について説明する。データを更新する場合、メタデータ４０を参照して、ファイルが使用しているブロックの乱数シードを、新しい乱数シードで更新する。ファイルの追記や削除により、ファイルのサイズが変わる場合は、新しいブロックを追加で割り当てたり、不要となるブロックを物理アドレスリスト４１から削除したりする。物理アドレスリスト４１から削除されたブロックの乱数シードは、特に初期化したりせずにそのままとする。これらの動作は実データをボリューム上に保存しない事以外は、通常のファイルシステムと同等である。
【００３２】
上述した「ファイルの削除」の具体例を説明する。クライアント２０が仮想ファイルシステム１１にファイル削除（上記ファイル作成の説明で作成した「/dir1/file_16KB_12345」の削除）を要求する。仮想ファイルシステム１１は、ディレクトリ「/dir1」からファイル名「file_16KB_12345」を探し、当該ファイル名とメタデータ識別子500のペアを当該ディレクトリから削除する。また、メタデータ識別子500で表される（当該ファイルの）メタデータも削除する。その後、クライアントに削除成功を返却する。このとき、乱数シードマップ５０（S-map）に関しては触れない。これは、ファイル削除ではファイルの管理情報が消えるだけで、ボリューム上の実際のデータを削除するわけではない一般的なファイルシステムと同等の動作となる。
【００３３】
次に、「ボリュームの読み込み」について説明する。ボリュームからデータを読み込む場合は、物理アドレスに対応するブロックの乱数シードを用いて擬似乱数アルゴリズムを初期化する。そして、この擬似乱数アルゴリズムを用いて乱数データを作成し、それをボリュームから読み込まれた当該ブロックのデータとしてクライアントに返却する。
【００３４】
上述した「ボリュームの読み込み」の具体例を、図４のフローチャートを参照して説明する。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス100で表されるブロック（ブロック100）の読み込みを要求する。仮想ボリュームインターフェイス１２は、乱数シードマップ１５（S-map）を参照して、物理アドレス100にアクセスして（ステップＳ１１）、当該物理アドレスに対応する乱数シード12345を求め（ステップＳ１２）、この乱数シード12345を用いて擬似乱数アルゴリズムを初期化する。そして、この擬似乱数アルゴリズムを用いて4KB分の乱数データを計算し（ステップＳ１３）、それを当該ブロックのデータとしてクライアントに返却する（ステップＳ１４）。
【００３５】
次に、「ボリュームへの書き込み」について説明する。ボリュームへデータを書き込む場合、クライアント２０が書き込んだデータと、そのブロックに上述の読み出し操作を行った場合に得られるデータとを比較する。データが異なる場合は書き込みエラーとする。
【００３６】
上述した「ボリュームへの書き込み」の具体例を説明する。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス150で表されるブロックへ、4KBのデータの書き込みを要求する。仮想ボリュームインターフェイス１２は乱数シードマップ１５（S-map）を参照して、物理アドレス150に対応する乱数シード46802を求め、この乱数シード46802を用いて擬似乱数アルゴリズムを初期化する。そして、擬似乱数アルゴリズムから4KB分の当該ブロックのデータを計算し、そのデータと、クライアント２０がから受け取った4KBのデータとを比較する。データが等しい場合は書き込み成功とし、異なっている場合は書き込みエラーをクライアントに返却する。
【００３７】
以上のようにして、実際にブロックの実データを記憶することなく、少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。上述した例では、ブロックサイズを4KB、物理アドレスを32bit（ボリューム容量16TB）、ブロックの乱数シードを64bitとすると、実際に記憶する乱数シードマップ記憶部１５（S-map）のサイズは、64bit*2^32=32GBとなる。
【００３８】
また、物理アドレスからブロック単位でボリューム操作も行うことができる。従って、ボリュームをバックアップやリストアの評価用に使用する場合であっても、かかるボリュームの作成や変更を容易に行うことができ、かかる時間の削減を図ることができる。
【００３９】
＜実施形態２＞
次に、本発明の第２の実施形態を説明する。本実施形態におけるストレージシステムは、上述した第１の実施形態とほぼ同様の構成を有しているが、以下の点で異なる。
【００４０】
ここで、上述した実施形態１では、乱数シードの範囲（最大値）がS-map５０のブロック数以上であれば、ボリューム内の全てのブロックをユニークなデータにできる。但し、評価対象ストレージシステム３０が重複排除機能をもつ場合、バックアップ等を評価するボリュームごとに、別の乱数シードを使う必要があり、より大きな範囲の乱数シードを使わなければデータが重複してしまう。ところが、ブロック毎の乱数シードの範囲を大きくすると、乱数シードマップ記憶部１５に記憶されるS-map全体のサイズが大きくなる。そこで乱数シードを効率的に扱う手法として、本実施形態のようにストレージシステムを構成する。
【００４１】
本実施形態におけるストレージシステム１０は、ボリューム毎に、当該ボリューム全体に対して割り当てられた乱数シードを有する。つまり、ストレージシステム１０は、乱数シードマップ記憶部１５（S-map）に記憶されたブロック毎の乱数シードとは別に、ボリューム全体で１つの乱数シードを記憶している。なお、ボリュームの乱数シードの変更は、例えば、ボリュームのルートディレクトリ上に特殊な名前を持つファイルを作成して記憶し、乱数シード値を書き込むと、それがボリュームの乱数シードとして利用されるようにすることで実現する。
【００４２】
そして、「ボリュームの読み込み」時にブロックの乱数データを読み込む際には、S-map５０に格納されているこのブロックに対応する乱数シードと、ボリュームの乱数シードと、を組み合わせて、実際のブロックの乱数シードとする。つまり、S-mapに格納されている乱数シードは、ブロックの乱数シードを特定する情報であり、実際のブロックの乱数シードの一部を形成する情報である。また、ボリュームの乱数シードも、実際のブロックの乱数シードの他の一部を形成する情報である。このため、S-mapに格納された乱数シードとボリュームの乱数シードとを組み合わせることで、実際のブロックの乱数シードを生成する。そして、上記２種類の乱数シードを組み合わせた乱数シードで擬似乱数アルゴリズムを初期化して、ブロックのデータを生成する。
【００４３】
上記構成のストレージシステム１０による「ボリュームの読み込み」の具体例について説明する。なお、ボリューム全体で１つの乱数シードは14825であるとする。クライアント２０は仮想ボリュームインターフェイス１２に、物理アドレス100で表されるブロック（ブロック100）の読み込みを要求する。このとき、まず、実施形態１と同様に乱数シードマップ記憶部１５内のS-map５０を参照して、格納されている乱数シード12345を求める。そして、ボリューム全体の乱数シード14825と、求めた乱数シード12345と、を組み合わせた新たな値で、擬似乱数アルゴリズムを初期化する。この擬似乱数アルゴリズムを用いて4KB分の乱数データを計算し、それを当該ブロックのデータとしてクライアントに返却する。
【００４４】
次に、ボリューム全体の乱数シードの変更の具体例について説明する。クライアント２０が特殊なファイル名「/volume_seed」を持つファイルを作成し、データとして34567を書き込むと、ボリューム全体の乱数シードが34567に変更される。
【００４５】
ここで、ブロックの乱数シードをボリューム内でユニークにするための最低サイズ（＝物理アドレスのサイズ）を32bitとし、ボリュームの乱数シードを32bitとする。すると、ブロック毎の実質的な乱数シードは、32（ブロック毎の乱数シード）＋32（ボリュームの乱数シード）=64ビットとなる。このため、実施形態１と同等の範囲を維持しているにもかかわらず、S-mapのサイズは32bit*2^32=16GBとなり、実施形態１の半分で済むこととなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。
【００４６】
また、本実施形態におけるストレージシステム１０では、ボリューム全体のデータを以前のデータと異なるデータに変更する場合には、単純にボリューム全体の乱数シードを変更すれば良い。その結果、ボリュームの生成、変更を容易に行うことができ、それにかかる時間を短縮することができる。例えば、評価対象のストレージに対して、まったく異なるデータで構成される複数のボリュームバックアップを繰り返したい時などに有益である。
【００４７】
＜実施形態３＞
次に、本発明の第３の実施形態を、図５乃至図８を参照して説明する。図５は、システム全体の構成を示すブロック図である。図６は、ストレージシステムにおける仮想ファイルシステム及び仮想ボリュームの構成を示す図である。図７は、ストレージシステムにおけるファイル作成時の動作を示すフローチャートであり、図８は、ブロック読み込み時の動作を示すフローチャートである。本実施形態におけるストレージシステムは、上述した第１の実施形態とほぼ同様の構成を有しているが、以下の点で異なる。
【００４８】
本実施形態におけるストレージシステム１０は、実施形態１で説明した乱数シードマップ記憶部１５の代わりに、メタデータ逆引きマップ６０（R-map）を記憶したメタデータ逆引きマップ記憶部１６（ブロックマップ記憶手段）を備えている。メタデータ逆引き表６０（R-map）は、ブロックの参照先となる物理アドレスに対応する記憶領域を有しており、ブロックのデータがどのファイルとして保存されているデータであるか、を表すための表である。このため、ブロックの物理アドレスが示すメタデータ逆引き表６０（R-map）上の記憶領域には、当該ブロックが含まれるファイルに関連付けられたメタデータ４０を識別するメタデータ識別子が格納されている。このメタデータ識別子は、ブロックシードを特定する情報として機能し、後述するように、ブロックオフセットと組み合わせられることによりブロックの乱数シード（ブロックシード）となる。
【００４９】
また、本実施形態におけるメタデータ４０には、対応するファイル毎に固有の乱数シード４２（ファイルシード）と、メタデータ逆引き表６０（R-map）からのメタデータの参照数を表す参照カウント４３と、が記憶されている。なお、メタデータ４０には、実施形態１で説明したファイルの属性や、ファイルを構成する各ブロックの参照先となる物理アドレスのリスト４１が記憶している。物理アドレスリスト４１は、各ブロックのファイル内における位置に対応して形成されているため、ブロックのファイル内における位置を表すオフセット情報（ブロック識別情報）として用いられる。なお、メタデータ４０には、オフセット情報とは異なり、ファイルを構成する各ブロックを当該ファイル内において区別できるブロック識別情報を記憶していてもよい。
【００５０】
上記構成のストレージシステム１０において「ファイルの作成」の具体例を、図７のフローチャートを参照して説明する。ここでは、メタデータ逆引きマップ記憶部１６（R-map）のブロック100および150、151には、メタデータ識別子は未登録であるとする（識別子0を未登録であることを表す特別な識別子とする）。一方、ブロック101と102には、メタデータ識別子499が登録されているとし、当該メタデータ識別子499で表されるファイルのメタデータの参照カウントは、2とする。
【００５１】
まず、クライアント２０は仮想ファイルシステム１２に対して、「/dir1/file_16KB_12345」という名前のファイルの作成を要求する。仮想ファイルシステム１１は、新しくメタデータ（メタデータ識別子500とする）を作成する（ステップＳ２１）。日付、アクセス許可情報や属性等は、一般的なファイルシステムと同様に作成する。そして本実施形態では、メタデータに、さらにファイルの乱数シード12345も保存する（ステップＳ２２）。
【００５２】
ファイルサイズに関しては、ファイル名から16KBであると判定し、それをファイルサイズとして保存する。また、16KB分のブロックをR-map上の空きブロックに割り当て、それらのブロック群の物理アドレスを、物理アドレスリスト４１に保存する（ステップＳ２３）。ここでは、ブロックサイズを4KBとし、R-map上のブロック100〜102、150の4ブロックが割り当てられたとする。すると、このファイルのメタデータ４０には、物理アドレスリスト４１として、R-map上の100,101,102,150の4つのアドレスが保存される。このとき、物理アドレスリスト４１は、ファイルを構成するブロックの順序で、各ブロックに対応する物理アドレスを並べて形成される。
【００５３】
続いて、メタデータ逆引きマップ記憶部１６（R-map）を参照し、ブロック100のメタデータ識別子を参照する。ここでは、メタデータ識別子は未登録であり、ブロック100に対応するメタデータは存在しないため、単純に新しいメタデータ識別子500でR-mapのブロック100を上書きする（ステップＳ２４）。
【００５４】
続いて、ブロック101のメタデータ識別子499を参照し、メタデータ識別子499に対応するメタデータ内の参照カウントを、2から1減らし、新しいメタデータ識別子500でR-mapのブロック101を上書きする。続いて、ブロック102のメタデータ識別子499を参照し、当該メタデータ識別子499に対応するメタデータ内の参照カウントを1から1減らし、新しいメタデータ識別子500でR-mapのブロック102を上書きする。すると、メタデータ識別子499のメタデータ内の参照カウントが0となったため、メタデータ識別子499のメタデータを削除する。続いて、ブロック150の識別子（未登録）を参照し、新しい識別子500で上書きする。
【００５５】
後は、実施形態１と同様に、当該ファイルが作成されるディレクトリ「/dir1」に当該ファイル名「file_16KB_12345」と、当該ファイルに対応するメタデータのメタデータ識別子50とをペアで登録して、ファイル名とメタデータと関連付ける（ステップＳ２５）。これでファイルの作成が完了したとして、仮想ファイルシステムはクライアントにファイル作成成功を返却する。
【００５６】
次に、「ファイルの削除」の具体例を説明する。実施形態１と同様に、ファイルの削除の場合には、ディレクトリ構造からファイル名とメタデータ識別子のペアを削除する。但し、本実施形態では、メタデータ４０自体は削除しない。メタデータ４０は、全てのR-map６０からの参照がなくなり、参照カウントが0になった時初めて削除される。
【００５７】
次に、「ブロックの読み込み」の具体例を、図８のフローチャートを参照して説明する。クライアント２０が仮想ボリュームインターフェイス１２に、物理アドレス101で表されるブロック（ブロック101）の読み込みを要求する。R-map６０上のブロック101の物理アドレスにアクセスして、当該物理アドレスに格納されているメタデータ識別子500を取得し（ステップＳ３２）、当該メタデータ識別子500に対応するメタデータを検索する。
【００５８】
そして、検索したメタデータ４０に記憶されているファイルの乱数シード４２を取得する。また、検索したメタデータ４０の物理アドレスリスト４１から、アドレス100が何番目のブロックであるかを検索し、2番目のブロック（ブロックオフセット2）と確認する（ステップＳ３３）。続いて、取得したファイルの乱数シード12345とブロックオフセット2とを組み合わせた新たな乱数シード（ブロックシード）を生成する。そして、新たな乱数シードを用いて擬似乱数アルゴリズムを初期化して、擬似乱数アルゴリズムから4KB分の当該ブロックのデータを計算し（ステップＳ３４）、それをクライアントに返却する（ステップＳ３５）。
【００５９】
また、クライアント２０が仮想ボリュームインターフェイス１２に、物理アドレス151で表されるブロック（ブロック151）の読み込みを要求したときの動作を説明する。R-mapのブロック151に対応する記憶領域にはメタデータ識別子が登録されておらず、対応するメタデータが無い。この場合、当該ブロックは一度もファイルに割り当てられたことがないことを示すため、全てのビットが0で構成された4KBのデータをクライアントに返却する。
【００６０】
ここで、ファイルの乱数シードを32bit、メタデータ識別子を24bit（ファイルを2^24-1=16777215個作成できると想定）とする。すると、ブロック毎の乱数シードは32（ファイルの乱数シード）＋32（ブロックオフセット）=64bitとなる。このため、実施形態１と同等の範囲を維持しているが、R-mapのサイズは24bit*2^32=12GBとなり、実施形態１及び２のS-mapよりも小さくなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。
【００６１】
また、上述したように、本実施形態におけるストレージシステム１０では、ブロック毎に当該ブロックのシード自体となる乱数シードを持つのではなく、ファイルのメタデータ４０毎に乱数シード４２を持ち、各々のブロックはメタデータの識別子を持つこととしている。そして、ファイル毎の乱数シード４２とブロックのオフセットとを組み合わせて、ブロックシードとなる新たな乱数シードを生成している。このため、ファイルのデータを変更する場合には、ファイルの乱数シード４２を変更すれば良く、R-map６０の更新は不要である。例えば、R-map６０が補助記憶装置に保存されている場合でもその更新が不要であるため、大量のファイルの更新が効率的に行え、かかる時間の削減を図ることができる。
【００６２】
さらに、ファイルが削除されてもR-map６０から参照されている限りメタデータを削除しないようにし、別のメタデータ識別子で当該ブロックが上書きされ、全てのR-map６０からの参照がなくなった時に初めて当該メタデータを削除する。R-map６０からの参照がなくなったか否かを、参照数をカウントすることで判定するため、メタデータには参照カウント４３を追加する。この場合、R-map６０はS-map５０と同様に巨大になり、補助記憶装置に保存されることが考えられるが、本技術で想定しているボリュームバックアップでは、連続した物理アドレスにシーケンシャルにアクセスするため、空間的な局所性が有り、R-map６０を先読みしやすく、アクセス効率が良い。
【００６３】
＜実施形態４＞
次に、本発明の第４の実施形態を説明する。本実施形態におけるストレージシステム１０は、実施形態３で説明したものとほぼ同様の構成をとっているが、以下の点で異なる。
【００６４】
まず、上述したように、本実施形態におけるメタデータ逆引きマップ記憶部１６のR-map６０は、対応するブロックが含まれるファイルに対応するメタデータ識別子を記憶している。これに加えて、R-map６０は、対応するブロックのファイル内における位置を表すオフセットの一部であるオフセットフラグメント（ブロック識別情報）を記憶している。このとき、オフセットフラグメントとしては、ブロックのオフセットの前後任意数のビットを落とし、残ったビットのみで形成されることとする。なお、オフセットフラグメントは、ファイルを構成する各ブロックを当該ファイル内において区別できる情報であれば、いかなる情報であってもよい。
【００６５】
そして、上記オフセットフラグメントは、物理アドレスリストから、元となるオフセットの上位ビット、下位ビットの未知の部分が求められ、当該オフセットに復元される。復元されたオフセットは、上述した実施形態４と同様に、ブロックに対応するメタデータ４０に記憶されているファイルの乱数シード４２と組み合わせられて、ブロックの乱数シードとして用いられる。
【００６６】
上記構成のストレージシステム１０において「ファイルの作成」の具体例を説明する。ここでは、ブロックオフセットを32bitとして、前8bit、後ろ8bitを除いたものをオフセットフラグメントとする。
【００６７】
クライアント２０が仮想ファイルシステム１２にファイル「file_128GB_12345」を作成する場合には、まず、実施形態３と同様に、ディレクトリツリー構造への登録を行い、ファイル識別子500のメタデータを作成する。また、ファイルサイズ128GBに必要な33554432個の空きブロックを割り当て、それらの物理アドレスを当該メタデータ４０の物理アドレスリスト４１に先頭から順に保存する。ここで、ファイル先頭のブロック（ブロックオフセット0）としてブロック100、ファイルの先頭から601番目（ブロックオフセット600）のブロックとしてブロック200、16780001番目（ブロックオフセット16780000）のブロックとしてブロック201、が割り当てられたとする。
【００６８】
続いて、ブロック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６０に保存する。
【００６９】
次に、「ブロックの読み込み」の具体例を説明する。クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス100のブロックを読み込む場合には、まずR-map６０からブロック100に対応するメタデータ識別子500とオフセットフラグメント0を求める。そして、メタデータ識別子500に対応するメタデータ４０を取得して、ファイルの乱数シード12345を取得する。また、メタデータ内の物理アドレスリスト４１を先頭から順次検索し、リストの先頭（ブロックオフセット0）にある当該ブロックの物理アドレス100を見つけ、当該ブロックのブロックオフセットを0と決定する。そして、ファイルの乱数シード12345とブロックオフセット0を組み合わせて、新たな乱数シードとして擬似乱数アルゴリズムを初期化し、4KBの乱数データを計算してクライアントに返却する。
【００７０】
クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス200のブロックを読み込む場合には、まず、R-map６０からブロック200に対応するメタデータ識別子500とオフセットフラグメント2を求める。そして、メタデータ識別子500に対応するメタデータを取得し、ファイルの乱数シード12345を取得する。また、オフセットフラグメント2に256（落とした下位ビットのビット数で２をべき乗したもの：2^8=256）を掛けて求めたブロックオフセット512から、物理アドレスリストの256個分を順次検索すると、88番目に物理アドレス200が見つかる。つまり、88+512=600であり、ファイルのブロックオフセットは600であることが計算される。後は、ファイルの乱数シード12345とブロックオフセット600を組み合わせて擬似乱数アルゴリズムを初期化し、4KBの乱数データを計算してクライアントに返却する。
【００７１】
クライアント２０が仮想ボリュームインターフェイス１２を用いて物理アドレス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の乱数データを計算してクライアントに返却する。
【００７２】
なお、上記から分かる通り、ブロックオフセットが16777216以上（64GB以上のファイルで出現）で初めて、上位8ビットが0で無くなるため、このサイズ未満のブロックオフセットでは必ず一回の検索でブロックが見つかる。同様に、128GBまでは高々2回のループで上位の未知ビットが求まる。
【００７３】
ここで、ファイルの乱数シードを32bit、メタデータ識別子を24bit（ファイルを2^24-1=16777215個作成できると想定）、オフセットフラグメントを16bitとする。すると、ブロック毎の乱数シードは32（ファイルの乱数シード）＋32（ブロックオフセット）=64bitとなる。このため、実施形態１と同等の範囲を維持しているが、R-mapのサイズは40bit*2^32=20GBとなり、実施形態１のS-mapよりも小さくなる。つまり、ブロックの実データを記憶することなく、さらに少ない容量で、仮想ファイルシステムと仮想ボリュームとを実現できる。
【００７４】
また、実施形態３と同様に、ファイルのメタデータ毎に乱数シードを持っているため、ファイルのデータを変更する場合には、ファイルの乱数シードのみを変更すれば良く、R-mapの更新は不要である。つまり、ファイル単位で乱数シードが操作でき、ファイルを少しずつ変更しながらバックアップを重ねる評価ができる。
【００７５】
ここで、上述した実施形態３では、物理アドレスは単純にブロックの並びの順にリスト化されているため、順次検索が必要で、二分探索やハッシュテーブル等の検索効率化ができない。これに対して、本実施形態では、ブロックのオフセットの前後任意数のビットを落とし、残ったビットをオフセットフラグメントとして、メタデータ識別子とともに、ブロック毎にR-mapに保存している。そして、オフセットフラグメントと物理アドレスリストから上位ビット、下位ビットの未知の部分を求め、オフセットに復元している。このとき、下位の未知のビットを求めるには単純にリストの順次検索を用いるため、空間的な局所性が有り、キャッシュ効率が良い。また、上位の未知のビットを求めるには飛び飛びの検索となるが、ファイルサイズが非常に大きくならないと上位未知ビットは0か小さい値となり、少ない回数のループで見つかる。このように、本実施形態では、オフセット検索のヒントとなるオフセットフラグメントをR-mapに記憶しているため、実施形態３と比較して、ブロックオフセットの計算（検索）効率が良く、性能が良い。
【００７６】
ここで、上述した各実施形態におけるストレージシステムの変形例について説明する。
まず、実施形態１乃至４では、ブロックの乱数シードの計算に使われる、または、メタデータに保存されるファイルの乱数シードは、ファイル名に特定の書式で埋め込まれた値を利用しているが、別の方法でも良い。例えば、ファイル名のハッシュ値を求めて用いても良い。または、ファイルの先頭の特定ビット数分に書き込まれたデータを乱数シードとして用いる方法もある。もしくは、ファイル毎に特定の名前の代替データストリーム（フォークなどとも呼ばれる）でファイルの乱数シードを参照・変更できるようにしても良い。ファイルシステムの機能以外にブロックの乱数を操作するインターフェイスを用意しても良い。
【００７７】
実施形態１，２では、S-mapに保存するブロックの乱数シードを、ファイルの乱数シードから計算しているが、別の方法でも良い。例えば、ファイルに書き込まれたデータをブロックの乱数シード列としてそのまま扱っても良い。または、ファイルに書き込まれたデータをブロック毎に区切り、ブロック毎に書き込まれたデータのハッシュ値を求めて、それをブロックの乱数シードとする方法もある。もしくは、ファイル毎に特定の名前の代替データストリームでブロック毎の乱数シードを参照・更新できるようにしても良い。ファイルシステムの一般的な機能以外にブロックの乱数を操作するインターフェイスを用意しても良い。
【００７８】
実施形態２では、ボリュームの乱数シードを変更するために、ルートディレクトリ上の特定の名前のファイルにシード値を書き込むとしているが、別の方法でも良い。たとえば書き込まれた値をそのまま乱数シード値として用いるのではなく、ハッシュ関数等の変換を行っても良い。もしくは、仮想ボリュームインターフェイスがボリュームラベルをサポートとするようにして、ボリュームラベルに特定の書式で乱数シードを埋め込み、その値をボリュームの乱数シードにする方法がある（「volume_seed_34567」というボリュームラベルを設定すると、ボリュームの乱数シードを34567とするなど）。その他、ボリュームの先頭ブロックなど特定の場所に書き込まれた値を乱数シードとしても良い。もしくは、乱数を操作するためのインターフェイスを仮想ボリュームインターフェイスに用意しても良い。
【００７９】
実施形態２では、ボリューム全体の乱数シードとして１つの値を利用しているが、ボリュームを物理アドレスから容易に識別可能な複数のエリアに分割し、エリア毎に個別の乱数シードを設定しても良い。
【００８０】
実施形態３，４では、ファイルを削除してもブロックのデータが変更されないようにするため、ファイルを削除してもR-mapからの参照が無くなるまではメタデータを削除しないようにしているが、ファイル削除時にブロックのデータが変更されても良い場合には、メタデータを削除し、R-mapからメタデータ識別子を削除しても良い。この場合、削除後のブロックからは全ビットが0のデータが読まれるようにする。
【００８１】
ファイルが割り当てられていないブロックからは全ビットが0のデータが読まれることとしているが、再現性のあるデータが読まれるのならば0でなくても良い。例えば、全ブロックで特定のデータを返すようにしても良い。もしくは、物理アドレスを乱数シードとして擬似乱数アルゴリズムで求めたデータを用いても良い。
【００８２】
メタデータに含まれている物理アドレスリストの記憶方法については、単純なリストを想定しているが、次のようにして圧縮することも考えられる。１つのファイルは一般的になるべく連続したブロックに割り当てられるため、物理アドレスリストは連続した数値になっている部分が多い。よってランレングス符号化のように、連続した部分の先頭アドレス、連続しているアドレスの数のペアをリストにすると、物理アドレスリストを単純な方法で効率的に圧縮できる。また、更に一定の単位でアドレスリストを分割しておく（例えば2^12=4096個単位）と、物理アドレスリストをランダムアクセスする場合でもある程度効率的に圧縮データを伸張できる。例えば、10000番目の物理アドレスを参照する場合は、8192番目のブロック（2個めの分割単位）から検索を始める、などである。
【００８３】
ボリュームへデータを書き込む場合、当該ブロックから読み込まれるはずのデータと比較し、異なる場合にはエラーとしているが、他の方法も考えられる。例えば、何もせずに破棄しても良い。この場合、比較処理のために乱数データを計算する必要がなく、より高い性能が求められる場合に有効である。もしくは、エラーとはしないが、異なった場所の物理アドレスのリストをとっておき、後で参照できるようにしても良い。
【００８４】
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム（図９参照）、プログラム、情報処理方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。
【００８５】
（付記１）
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を備えた、
ストレージシステム。
【００８６】
上記発明によると、ファイルの実データを記憶することなく、仮想ファイルシステムを構築できると共に、物理アドレスからブロック単位でボリューム操作も行うことができる。具体的には、まず、ファイルのメタデータから当該ファイルを構成するブロックの参照先となる物理アドレスを参照して、ブロックシードを特定する情報からブロックシードを特定する。そして、ブロックシードから疑似乱数生成アルゴリズムなどを用いてブロックのデータを生成して、ブロックのデータからファイルを生成する。これにより、仮想ファイルシステムを構築することができる。また、物理アドレスを参照して上述同様にブロックシードを特定し、ブロックのデータを生成することで、仮想ボリュームも構築することができる。
【００８７】
これにより、上記ボリュームをバックアップやリストアの評価用に使用する場合であっても、当該ボリュームを構成するブロックの実データを記憶することがないため、ストレージシステムの容量を低減させることができる。また、ボリュームの作成や変更の際には、ブロックシードを特定する情報を操作すればよいため、かかる時間の低減を図ることができる。
【００８８】
（付記２）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
ストレージシステム。
【００８９】
（付記３）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックデータ生成手段は、前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【００９０】
上記発明によると、ブロックシードは、ボリューム毎に定められた情報と物理アドレスに格納された情報とから特定される。このため、ボリューム毎に定められた情報を変更することで、全体的に新たなブロックのデータを生成でき、容易にボリュームの生成、変更を行うことができる。
【００９１】
（付記４）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータ記憶手段は、前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【００９２】
（付記５）
付記１に記載のストレージシステムであって、
前記ブロックマップ記憶手段は、前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータ記憶手段は、前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックデータ生成手段は、前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
ストレージシステム。
【００９３】
（付記６）
付記４又は５に記載のストレージシステムであって、
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
ストレージシステム。
【００９４】
上記発明によると、ブロックシードは、ファイル毎に定められたファイルシードと、ファイル内におけるブロックを識別する情報（例えば、ファイル内におけるブロックの位置を表すオフセット情報）と、から特定される。このため、ファイルシードを変更することで、ファイル毎にデータの変更等の操作を容易に行うことができる。
【００９５】
（付記７）
付記１乃至５のいずれかに記載のストレージシステムであって、
前記メタデータ記憶手段に記憶された前記メタデータを参照して、ファイルを構成するブロックに対応する前記物理アドレスを特定し、当該物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからファイルを生成することにより仮想的なファイルシステムを構築する仮想ファイルシステム構築部と、
前記物理アドレスを用いて前記ブロックデータ生成手段にて生成されたブロックのデータからボリュームを生成することにより仮想的なボリュームを構築する仮想ボリューム構築部と、
を備えたストレージシステム。
【００９６】
（付記８）
情報処理装置に、
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶するメタデータ記憶手段と、
前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶するブロックマップ記憶手段と、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成するブロックデータ生成手段と、
を実現させるためのプログラム。
【００９７】
（付記９）
ファイル毎に、当該ファイルを構成するブロックの参照先となる記憶領域を特定する物理アドレスの情報を含むメタデータを記憶すると共に、前記物理アドレスにて特定される記憶領域に、前記ブロックのデータを生成するための元となるブロックシードを特定する情報を記憶し、
前記物理アドレスにて特定される記憶領域に記憶されている前記ブロックシードを特定する情報に基づいて当該ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【００９８】
（付記１０）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、当該ブロックシードそのものを記憶する、
情報処理方法。
【００９９】
（付記１１）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、当該ブロックシードの一部を形成する情報を記憶し、
前記ブロックで形成されるボリュームについて設定された前記ブロックシードの他の一部を形成する情報と、前記ブロックシードを特定する情報である前記ブロックシードの一部を形成する情報と、からブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【０１００】
（付記１２）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子を記憶し、
前記メタデータに、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、ファイル毎に異なる情報であるファイルシードと、を記憶し、
前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ブロック識別情報と前記ファイルシードとから前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【０１０１】
（付記１３）
付記９に記載の情報処理方法であって、
前記ブロックシードを特定する情報として、ブロックが含まれるファイルに対応する前記メタデータを特定するメタデータ識別子と、少なくともファイル内においてブロック毎に異なる情報であるブロック識別情報と、を記憶し、
前記メタデータに、ファイル毎に異なる情報であるファイルシードを記憶し、
前記ブロックシードを特定する情報である前記メタデータ識別子からブロックが含まれるファイルに対応する前記メタデータを参照して、当該メタデータに記憶されている前記ファイルシードと、前記ブロックシードを特定する情報である前記ブロック識別情報と、から前記ブロックシードを特定し、当該ブロックシードからブロックのデータを生成する、
情報処理方法。
【０１０２】
（付記１４）
付記１２又は１３に記載のストレージシステムであって、
前記ブロック識別情報は、ブロックのファイル内における位置を表すオフセット情報の少なくとも一部にて形成された情報である、
情報処理方法。
【０１０３】
なお、上述したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
【０１０４】
以上、上記実施形態等を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【０１０５】
１０  ストレージシステム
１１  仮想ファイルシステム
１２  仮想ボリュームインタフェース
１３  ディレクトリツリー構造記憶部
１４  ファイルメタデータ記憶部
１５  乱数シードマップ記憶部
１６  メタデータ逆引きマップ記憶部
２０  クライアント
３０  評価対象ストレージシステム
３１  評価対象ストレージ
４０  メタデータ
４１  物理アドレスリスト
４２  ファイル乱数シード
４３  参照カウント
５０  乱数シードマップ
６０  メタデータ逆引きマップ
１００  ストレージシステム
１１０  ブロックデータ生成手段
１２０  メタデータ記憶手段
１３０  ブロックマップ記憶手段
【図１】
2015176205.tif 000003
【図２】
2015176205.tif 000004
【図３】
2015176205.tif 000005
【図４】
2015176205.tif 000006
【図５】
2015176205.tif 000007
【図６】
2015176205.tif 000008
【図７】
2015176205.tif 000009
【図８】
2015176205.tif 000010
【図９】
2015176205.tif 000011