(57)【要約】  光ディスクライブラリ装置外にカートリッジを保管するという運用を行っている状況で、カートリッジ内のどの光ディスクにどのファイルが格納されたかという記録位置管理情報を、ＨＤＤ記憶装置および所定の光ディスクカートリッジ内の所定のディスク内に適切なタイミングで書き出し、ユーザからのファイル読み出し要求に応じて光ディスクから記録位置管理情報を読み出すことで、ＨＤＤ記憶装置の容量とコストを削減しＨＤＤ上の管理データのマイグレーションコストを低減しつつ、光ディスクの搬送を少なくしアクセス性能を確保できるストレージシステム。
2016199230.tif 000002
【特許請求の範囲】
【請求項１】
データを格納するリムーバブルな記憶デバイスと、
ホスト計算機からのアクセス要求を基に、前記記憶デバイスの記憶領域へのデータの入出力処理を制御するコントローラと、 
ストレージ装置を有し、
前記コントローラは、 
前記ホスト計算機から入力されたファイルのファイルパスに関連する情報を含む第一のテーブルと、 
前記ファイルのデータ実体の記録位置を含む第二のテーブルからなる構成のテーブルを生成し、 
前記第一のテーブルに、前記第二のテーブルの格納位置を指すポインタ情報を付与し、 
前記第一のテーブルと前記第二のテーブルを前記ストレージ装置に保存したのち、 
前記第二のテーブルを前記ストレージ装置から、前記記憶領域に移動する、 
ことを特徴とするストレージシステム。 
【請求項２】
請求項１に記載のストレージシステムであって、
前記第一のテーブルがハッシュテーブルである
ことを特徴とするストレージシステム。
【請求項３】
請求項２に記載のストレージシステムであって、
前記第二のテーブルにファイルの識別情報としてハッシュが記録されている
ことを特徴とするストレージシステム。
【請求項４】
請求項２に記載のストレージシステムであって、
前記第二のテーブルにファイルの識別情報としてタイムスタンプが記録されている
ことを特徴とするストレージシステム。
【請求項５】
請求項１に記載のストレージシステムであって、
前記記憶領域が、カートリッジに格納されており、
前記コントローラは、 
前記カートリッジが前記リムーバブルな記憶デバイスに装填されると、
前記第一のテーブルと前記第二のテーブルを前記記憶領域から読み出して、前記ストレージ装置に格納する
ことを特徴とするストレージシステム。 
【請求項６】
請求項１に記載のストレージシステムであって、
前記記憶領域が、カートリッジに格納されており、
前記コントローラは、 
前記カートリッジが前記リムーバブルな記憶デバイスから取り外されると、
前記第二のテーブルを前記記憶領域から削除する
ことを特徴とするストレージシステム。 
【請求項７】
請求項１に記載のストレージシステムであって、
前記コントローラは、 
前記第一のテーブルと前記第二のテーブルを前記ストレージ装置に保存したのち、 
前記第一のテーブルを前記ストレージ装置から、前記記憶領域に移動し、
さらに前記第二のテーブルを前記ストレージ装置から、前記記憶領域に移動する
ことを特徴とするストレージシステム。 
【請求項８】
請求項１に記載のストレージシステムであって、
前記コントローラは、 
前記第一のテーブルと前記第二のテーブルを前記記憶領域に保存したのち、 
前記第二のテーブルを前記記憶領域から、前記ストレージ装置に移動し、
さらに前記第一のテーブルを前記記憶領域から、前記ストレージ装置に移動する
ことを特徴とするストレージシステム。 
【請求項９】
請求項１に記載のストレージシステムであって、
前記記憶領域が、カートリッジに格納されており、
前記第二のテーブルに前記カートリッジごとの記録時間範囲が記録されている
ことを特徴とするストレージシステム。 
【請求項１０】
請求項１に記載のストレージシステムであって、
前記記憶領域が、カートリッジに格納されており、
前記第一のテーブルに前記カートリッジごとのタイムスタンプが記録されている
ことを特徴とするストレージシステム。 
【請求項１１】
請求項９に記載のストレージシステムであって、
前記記憶領域が、複数のカートリッジに格納されており、
前記コントローラは、 
前記第一のテーブルと前記第二のテーブルを前記ストレージ装置に保存したのち、 
前記第二のテーブルを前記ストレージ装置から、前記記憶領域に移動し、
さらに前記第一のテーブルを前記ストレージ装置から、前記記憶領域に移動し、
カートリッジを特定するための時間情報を一部とするＩＤ情報を保持する第三のテーブルと、 
前記第三のテーブルの格納位置と前期第三のテーブルに含まれるＩＤ情報の一部である時間情報の最小値と最大値を保持する第四のテーブルからなる構成のテーブルを生成し、 
前記第四のテーブルに、前記第三のテーブルの格納位置を指すポインタ情報を付与し、 
前記第三のテーブルと前記第四のテーブルを前記ストレージ装置に保存したのち、 
前記第四のテーブルを前記ストレージ装置から、前記記憶領域に移動し、
さらに前記第三のテーブルを前記ストレージ装置から、前記記憶領域に移動する
ことを特徴とするストレージシステム。 
【請求項１２】
請求項９に記載のストレージシステムであって、
前記記憶領域が、複数のカートリッジに格納されており、
前記コントローラは、 
前記第一のテーブルと前記第二のテーブルを前記ストレージ装置に保存したのち、 
前記第二のテーブルを前記記憶領域から、前記ストレージ装置に移動し、
さらに前記第一のテーブルを前記記憶領域から、前記ストレージ装置に移動し、
カートリッジを特定するための時間情報を一部とするＩＤ情報を保持する第三のテーブルと、 
前記第三のテーブルの格納位置と前期第三のテーブルに含まれるＩＤ情報の一部である時間情報の最小値と最大値を保持する第四のテーブルからなる構成のテーブルを生成し、 
前記第四のテーブルに、前記第三のテーブルの格納位置を指すポインタ情報を付与し、 
前記第三のテーブルと前記第四のテーブルを前記ストレージ装置に保存したのち、 
前記第四のテーブルを前記記憶領域から、前記ストレージ装置に移動し
さらに前記第三のテーブルを前記記憶領域から、前記ストレージ装置に移動し、
前記最小値と前記最大値の範囲を時間情報で二分木探索する、
ことを特徴とするストレージシステム。 
【請求項１３】
データを格納するリムーバブルな記憶デバイスと、
ホスト計算機からのアクセス要求を基に、前記記憶デバイスの記憶領域へのデータの入出力処理を制御するコントローラと、 
ストレージ装置を有し、
前記コントローラは、 
前記ホスト計算機から入力されたファイルのファイルパスに関連する情報を含む第一のテーブルと、 
前記ファイルのデータ実体の記録位置を含む第二のテーブルからなる構成のテーブルを生成し、 
前記第一のテーブルに、前記第二のテーブルの格納位置を指すポインタ情報を付与し、 
前記第一のテーブルを前記ストレージ装置に保存し、前記第二のテーブルを前記記憶領域に保存したのち、 
前記第二のテーブルを前記記憶領域から前記ストレージ装置に移動する、 
ことを特徴とするストレージシステム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リムーバブルな記憶デバイスを用いたストレージシステムに関する。
【背景技術】
【０００２】
近年、多くの企業が内部統制や法令順守を推進し、日々蓄積される企業情報システムの電子データ（メール、ドキュメント、トランザクションログ)を、遠隔地の保管に適したリムーバブルメディアにアーカイブするのが一般的である。【０００３】
例えば、リムーバブルメディアの一つである光ディスクは、他の電子記録媒体に比べて長期間（例えば、数十年）に渡る記録保存が可能な媒体特性を持ち、アーカイブでの利用に適している。このような光ディスクへの読み書きを行う複数の光ディスクドライブを搭載し、多数の光ディスクカートリッジを格納する機構を備えたものを、光ディスクライブラリ装置と呼ぶ。【０００４】
特許文献１によると、旧ストレージシステム上の指定されたソース論理ユニットから、旧ストレージシステムのソース論理ユニットに関するデータのロケーション情報を含むソース論理ユニットの情報を取得し、ソース論理ユニットの情報をもとに得られた旧ストレージシステムのデータを新ストレージシステムに書込み、また書き込んだ先のロケーション情報を新ストレージシステム内に保存する。この方法により、旧ストレージシステム内のデータの移行が行われる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３３４８７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
光ディスクライブラリ装置は、アーカイブファイルがどの光ディスクに保存されたかを管理情報（以下、ファイル管理情報、又はメタデータと称する）として記録する。ユーザからアーカイブファイルの読み出し要求を受けると、このファイル管理情報に基づき、ファイルが格納されている光ディスクをドライブへ搬送して、データを読み出す。このため、管理情報は、少なくとも光ディスクからアーカイブファイルを読み出せる間は保持する必要がある。【０００７】
しかし、光ディスクの寿命は、光ディスクライブラリ装置を構成するデバイスの寿命（例えば、数年）より長く、光ディスクライブラリ装置の破棄に伴ってファイル管理情報が失われると、光ディスク内のアーカイブファイルが読み出せなくなってしまう。また、保管するデータ容量の増大や保管期間の長期化に伴い、データ容量のみならずデータを管理するメタデータの容量も増大する。メタデータをＨＤＤ記憶装置に保管したままでは、ＨＤＤのコストと長期保管時のマイグレーションコストが増大する。一方、全てのメタデータを光ディスクに保管するとアクセス性能が劣化する課題がある。【０００８】
特許文献１の技術を用いた場合、光ディスクライブラリ装置の指定された光ディスクに格納するファイルの管理情報は、光ディスクライブラリ装置内に装填された記憶媒体に格納されたファイルの管理情報のみである。【０００９】
光ディスクに格納したファイルの管理情報としては、そのファイルの記録位置を光ディスクライブラリ装置外のストレージ装置に格納し、光ディスク上のファイルへのアクセス要求に応じて、当該ファイルが格納された光ディスクを光ディスクライブラリ装置に装填し、搬送機構を用いて光ディスクドライブに光ディスクを挿入する処理を行うために必要な管理情報がある。この管理情報は光ディスクに記録したファイル数が増加すると、ストレージ装置の記憶領域の消費量を増大させ、ストレージ装置のコストを増大させるという課題がある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
【発明の効果】
【００１１】
本発明によれば、カートリッジ内のどの光ディスクにどのファイルが格納されたかという管理情報を、ユーザからのファイル読み出し要求に応じて適切に管理し、光ディスクの容量コスト低減とストレージシステムのマイグレーションコストの低減を実現できる。
【図面の簡単な説明】
【００１２】
【図１】光ディスクライブラリ装置の物理構成を示すブロック図
【図２】バッファリングサーバの物理構成を示すブロック図
【図３】光ディスクライブラリ装置のＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック図
【図４】バッファリングサーバのＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック図
【図５】バッファリングサーバ内の制御用メモリに保存される管理テーブル
【図６】カートリッジ毎の共通情報
【図７】カートリッジ毎のパステーブル
【図８】ファイル毎の記録位置テーブル
【図９】アカウント情報テーブル
【図１０】シェア情報テーブル
【図１１】カートリッジ情報テーブル
【図１２】光ディスクライブラリ装置へのカートリッジの装填時の処理フロー
【図１３】書き込み処理フロー
【図１４】読み出し処理フロー
【図１５】リストア処理フロー
【図１６】取り外し処理フロー
【図１７】削除テーブル
【図１８】ポインタテーブル
【図１９】ストレージ装置から光ディスクへの移動処理フロー
【図２０】光ディスクからストレージ装置への移動処理フロー
【図２１】ハッシュを用いたカートリッジ毎のハッシュテーブル
【図２２】同一ハッシュのパステーブル
【図２３】ファイル識別のためのハッシュが衝突した場合の衝突テーブル
【図２４】パステーブルへのハッシュ登録処理フロー
【図２５】ハッシュを用いたパステーブルの探索処理フロー
【図２６】同一ハッシュのパステーブル
【図２７】ファイル識別のためのタイムスタンプ付与処理フロー
【図２８】ファイル識別のためのタイムスタンプ識別処理フロー
【図２９】カートリッジ毎の記録時間範囲の記録処理フロー
【図３０】カートリッジ毎の記録時間範囲の選択処理フロー
【図３１】所有者ＩＤ情報
【図３２】ボリューム情報テーブル
【図３３】ディスク情報テーブル
【図３４】光ディスクライブラリ装置へのカートリッジの装填時の処理フロー
【図３５】書き込み処理フロー
【図３６】読み出し処理フロー
【図３７】リストア処理フロー
【図３８】取り外し処理フロー
【図３９】ストレージ装置から光ディスクへの移動処理フロー
【図４０】光ディスクからストレージ装置への移動処理フロー
【図４１】パステーブルへのハッシュ登録処理フロー
【図４２】ハッシュを用いたパステーブルの探索処理フロー
【図４３】ファイル識別のためのタイムスタンプ付与処理フロー
【図４４】ファイル識別のためのタイムスタンプ識別処理フロー
【図４５】書き込み処理フロー
【図４６】読み出し処理フロー
【図４７】シェア情報テーブルの更新処理フロー
【図４８】シェア情報テーブルの取得処理フロー
【図４９】書き込み処理フロー
【図５０】読み出し処理フロー
【発明を実施するための形態】
【００１３】
以下、本発明の実施例を説明する。なお、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。
【００１４】
また、以後の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｏｒ  Ｕｎｉｔ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信インタフェース装置（例えば通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
【００１５】
また、各要素例えば、論理ボリュームは、番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。
【００１６】
バッファリングサーバ内の制御用メモリ上に管理テーブルを展開する例にて説明しているが、メモリの容量を補うためにストレージ装置１０４に領域を確保し、メモリと同様に使用しても良い。ストレージ装置１０４に領域を確保するためには、バッファリングサーバのファイルシステムを用いても良いし、ストレージ装置の物理アドレス範囲を確保しても良いし、ストレージ装置の領域をパーティションに分割し、その一部を使用してもよい。
【００１７】
以下、図を用いて、本発明の実施例を説明する。以下の図中、同一の部分には同一の符号を付加する。ただし、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
【００１８】
＜光ディスクライブラリ装置の物理構成＞
図１に、光ディスクライブラリ装置の物理構成を示す。
【００１９】
図１において、光ディスクライブラリ装置は、例えば、光ディスクライブラリ装置１０１と、バッファリングサーバ１０２、管理サーバ１０３、ストレージ装置１０４、ホスト計算機１０５と、を備える計算機システムを構成する一つの装置である。
【００２０】
光ディスクライブラリ装置１０１とバッファリングサーバ１０２は、例えば、通信線を介して接続され、光ディスクライブラリ装置１０１と管理サーバ１０３は、例えば、通信線を介して接続される。
【００２１】
バッファリングサーバ１０２とストレージ装置１０４は、例えば、通信線を介して接続され、バッファリングサーバ１０２と管理サーバ１０３は、例えば、通信線を介して接続される。
【００２２】
管理サーバ１０３とストレージ装置１０４は、例えば、通信線を介して接続される。
【００２３】
バッファリングサーバ１０２は、通信線を介してネットワークに接続される。
【００２４】
管理サーバ１０３は、通信線を介してネットワークに接続される。
【００２５】
各ホスト計算機１０５は、通信線を介してネットワークに接続される。
【００２６】
なお、上述の通信線は、例えば、メタルケーブルや光ファイバケーブル等の有線として構成される。しかし、各ホスト計算機１０５とバッファリングサーバ１０２、管理サーバ１０３間をそれぞれ無線で接続することも可能である。この場合は、通信線は省略される。
【００２７】
また、光ディスクライブラリ装置１０１とバッファリングサーバ１０２間の通信線と、光ディスクライブラリ装置１０１と管理サーバ１０３間の通信線と、管理サーバ１０３とストレージ装置１０４間の通信線と、バッファリングサーバ１０２とネットワーク間の通信線と、管理サーバ１０３とネットワーク間の通信線と、ホスト１０５とネットワーク間の通信線と、は、共通のネットワークであっても良い。ネットワークは、通信ネットワークであり、例えば、ＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）又はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）である。
【００２８】
次に、光ディスクライブラリ装置１０１の内部構成を説明する。
【００２９】
光ディスクライブラリ装置１０１は、例えば、一つまたは複数のＣＰＵ１１１と、一つまたは複数の制御用メモリ１１２と、一つまたは複数の搬送装置１１３と、一つまたは複数の記憶再生装置（以下、ドライブ）１１４と、一つまたは複数のカートリッジ１１５を備える。
【００３０】
各カートリッジ１１５内には、一つまたは複数の光ディスク１１６を内蔵しており、各カートリッジ１１５は光ディスクライブラリ装置１０１から取り外しが可能となっている。
【００３１】
各光ディスクは、データを格納する記憶デバイスとして、少なくとも、Ｂｌｕ−ｒａｙ  Ｄｉｓｃ（ＴＭ）（以下、ＢＤ）、またはＨｏｌｏｇｒａｍ  Ｄｉｓｃが含まれている。なお、光ディスクは、それらのうちの少なくとも１つに代えて、またはそれらに加えて、他の種類の物理的な記憶デバイスであっても良い。
【００３２】
一つまたは複数の光ディスク搬送装置１１３と、一つまたは複数のドライブ１１４は、例えば、カッパーケーブル、光ケーブルあるいはバス等の通信路を介して、光ディスクライブラリ装置に接続される。
【００３３】
なお、複数の光ディスクで、一つまたは複数のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｄｉｓｋｓ）グループを構成することができる。
【００３４】
次に、光ディスクライブラリ装置１０１の役割を説明する。
【００３５】
光ディスクライブラリ装置１０１は、バッファリングサーバ１０２から受信したコマンドに従って、光ディスク搬送装置１１３に対するディスク搬送処理、またはドライブ１１４に対するデータの入出力処理、即ち、光ディスクへのデータのライト（書き込み）やリード（読み出し）を制御する。
【００３６】
バッファリングサーバ１０２から光ディスクライブラリ１０１装置に送信されるコマンドは、本来の光ディスクへのデータのライトやリードのアクセス要求元であるホスト計算機のからのものであるが、バッファリングサーバ１０２の動作については後述する。
【００３７】
光ディスクライブラリ装置１０１は、コマンドの送信元であるバッファリングサーバ１０２に対して、ドライブ１１４に装填した光ディスクを、実記憶領域が既に割り当てられている状態であり、かつアクセス対象としての論理ボリュームとして提供する。
【００３８】
この際、バッファリングサーバ１０２は、ドライブ１１４に装填した光ディスクの実記憶領域を、例えば、Ｌｏｇｉｃａｌ  Ｂｌｏｃｋ  Ａｄｄｒｅｓｓ（以下、ＬＢＡ）によって参照したり、識別したりすることができる。
【００３９】
光ディスクライブラリ装置１０１は、例えば、記憶資源と、通信インタフェース装置（以下、インタフェース装置を「Ｉ／Ｆ」と略記）と、それらに接続された演算装置とを有する。
【００４０】
演算装置は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｏｒ  Ｕｎｉｔ）である。ＣＰＵは、後述するマイクロプログラムを、ＣＰＵ内部の揮発性のあるローカルメモリに保存することができる。ただし、ＣＰＵへの電源供給がなくなった場合に備えて、マイクロプログラムの本体を、同じくＣＰＵ内の不揮発なメモリ領域に保存しておく。
【００４１】
記憶資源は、例えば、制御用メモリである。
【００４２】
制御用メモリは、例えば、電源供給が無ければ保持しているデータを失う（揮発性の）ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。また、制御用メモリは、例えば、電源供給が無くともデータ保持が可能な（不揮発性の）フラッシュメモリチップを内蔵するフラッシュパッケージである。制御用メモリを、揮発性のメモリと不揮発性のメモリを組み合わせた構成としても良い。
【００４３】
通信Ｉ／Ｆとしては、例えば、バッファリングサーバからリードやライトを受信するバッファリングサーバＩ／Ｆと、管理サーバから管理用コマンドを受信する管理サーバＩ／Ｆと、を備える。これらバッファリングサーバＩ／Ｆと、管理サーバＩ／Ｆと、ＣＰＵ、制御用メモリ、光ディスク搬送装置１１３、ドライブ１１４は、バス等の通信線を介して相互に接続される。各ホスト１０５や管理サーバのハードウェア構成は、一般的な計算機と同じである。すなわち、各ホスト１０５と管理サーバ１０３は、通信インタフェース装置と、記憶資源と、それらに接続された演算装置とを有する。通信インタフェース装置としては、例えば、ネットワークを介した通信を行うためのホストバスアダプタ（ＨＢＡ）等である。記憶資源は、例えば、メモリや内蔵ＨＤＤで構成される。
【００４４】
以上が、光ディスクライブラリ装置（１０１）の構成に関する説明である。
【００４５】
＜バッファリングサーバの物理構成＞
図２に、バッファリングサーバの物理構成を示す。
【００４６】
図２において、バッファリングサーバは、例えば、バッファリングサーバ１０２と、光ディスクライブラリ装置１０１、管理サーバ１０３、ストレージ装置１０４、ホスト計算機１０５と、を備える計算機システムを構成する一つの装置である。また、バッフリングサーバ１０２とその他の計算機や装置と、の接続は、前述のとおりである。
【００４７】
バッファリングサーバ１０２の構成を説明する。バッファリングサーバ（１０２）は、例えば、一つまたは複数のＣＰＵと、一つまたは複数の制御用メモリと、を備える。
【００４８】
次に、バッファリングサーバの役割を説明する。
【００４９】
バッファリングサーバ１０２は、ホスト計算機１０５から受信したファイル格納・読み出し指示に従い、ライブラリ装置に対するデータの入出力コマンド、あるいは光ディスク搬送装置１１３に対するディスク搬送処理コマンドを送信し、その応答を受信する。即ち、光ディスクライブラリ装置を介して、光ディスクへのデータのライト（書き込み）やリード（読み出し）を行う。
【００５０】
バッファリングサーバ１０２は、光ディスクライブラリ装置から、ドライブ１１４に装填した光ディスクを、実記憶領域が既に割り当てられた論理デバイスあるいは論理ボリュームとして提供されており、それらの実記憶領域を、例えば、ＬＢＡによって参照したり、識別したりすることができる。
【００５１】
ホスト計算機１０５は、バッファリングサーバ１０２から、前述した論理デバイスあるいは論理ボリュームを、ファイルシステムとして提供されており、それらの実記憶領域を、例えば、ファイルパスとして参照したり、識別したりすることができる。この場合、ホスト計算機１０５がバッファリングサーバ１０２に対して行う入出力の単位は、ファイルである。この例では、ホスト計算機１０５が意味のあるデータの集まりをファイルとして読んでいるに過ぎず、ホスト計算機がこのデータの集まりを識別できるならば、ファイルは、例えば、ブロックやレコード、ファイルパスは、例えば、ＩＤ番号のようなものでもよい。
【００５２】
またホスト計算機１０５は、ユーザによって操作され、後述するバッファリングサーバ１０２に対するファイル格納コマンドあるいはファイル読み出しコマンドは、ユーザがホスト計算機１０５を通じて行う。
【００５３】
バッファリングサーバは、例えば、記憶資源と、通信インタフェース装置と、それらに接続された演算装置とを有する。
【００５４】
演算装置は、例えば、ＣＰＵ２１１である。記憶資源は、例えば、制御用メモリ２１２である。
【００５５】
制御用メモリは、例えば、電源供給が無ければ保持しているデータを失う（揮発性の）ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。また、制御用メモリは、例えば、電源供給が無くともデータ保持が可能な（不揮発性の）フラッシュメモリチップを内蔵するフラッシュパッケージである。制御用メモリを、揮発性のメモリと不揮発性のメモリを組み合わせた構成としても良い。あるいは、制御用メモリを、揮発性のメモリとストレージ装置１０４の記憶領域の一部を組み合わせた構成としても良く、ビットコストが高いメモリの容量を削減できるため、コスト低減の効果がある。あるいは、ストレージ装置１０４の記憶領域の一部を、光ディスクの容量と同じ容量の仮想ドライブ領域として確保しても良く、仮想ドライブに記録位置テーブル５１３や、ポインタテーブル５２１を記録することで、光ディスクへの書き出し処理が、仮想ドライブから光ディスクへのビットバイビットのシーケンシャルな書き出しとなるため、処理が単純で、シークが発生せず転送が高速であるという効果がある。また、仮想ドライブを複数確保することで、例えば、複数アカウントのユーザが同時にアクセスする場合に、アカウントごとに仮想ドライブを割り当てれば、アカウント単位でメタデータの光ディスク書き出しを制御することが容易となるという効果がある。通信Ｉ／Ｆとしては、例えば、ホスト計算機から、ファイル格納・読み出し指示を受け取るホストＩ／Ｆと、光ディスクライブラリ装置にリードやライトを送信するライブラリＩ／Ｆと、管理サーバから管理用コマンドを受信する管理サーバＩ／Ｆと、ストレージ装置に対してリードやライトを行うストレージＩ／Ｆと、を備える。
【００５６】
これらライブラリＩ／Ｆと、管理サーバＩ／Ｆと、ストレージＩ／Ｆと、ＣＰＵ、制御用メモリ、バス等の通信線を介して相互に接続される。
【００５７】
以上が、バッファリングサーバ（１０２）の構成に関する説明である。
【００５８】
ホスト計算機（１０５）は、オペレーティングシステム（ＯＳ）と、ＯＳ上で実行されるアプリケーション（ＡＰＰ）と、から構成される。ＡＰＰは、ＯＳが提供する入出力インタフェースを利用して、ストレージへのデータの入出力を行う。
【００５９】
また、管理サーバ（１０３）は、オペレーティングシステム（ＯＳ）と、ＯＳ上で実行される管理ソフトと、から構成される。管理ソフトは、ＯＳが提供する入出力インタフェースを利用して、バッファリングサーバ１０２や、光ディスクライブラリ装置１０１、ストレージ装置１０４の構成をシステム管理者の指示で変更したり、装置内の状況をシステム管理者に表示したりする。複数の管理ソフトが、それぞれ異なるＯＳの上で動作していてもよい。また、複数の管理ソフトがそれぞれ異なるホスト上で動作していてもよい。
【００６０】
＜ホスト計算機１０５からのファイル格納コマンド受信時のバッファリングサーバ１０２と光ディスクライブラリ装置１０１の基本的動作＞
次に、光ディスクライブラリ装置１０１、バッファリングサーバ装置１０２、ストレージ装置１０４、の基本的動作を簡単に説明する。
【００６１】
バッファリングサーバ１０２は、ホストＩ／Ｆを介して、いずれかのホスト計算機１０５からファイル格納コマンドを受信した場合、ホスト計算機１０５から受信したファイルをストレージ装置１０４に記憶する。
【００６２】
バッファリングサーバ１０２は、ストレージ装置１０４に記憶しているファイルを、ストレージＩ／Ｆを介して読み出し、ライブラリＩ／Ｆを介して光ディスクライブラリ装置１０１内のドライブ１１４を介して光ディスクに書き込む。
【００６３】
バッファリングサーバ１０２が、ホストから受信したファイルを光ディスクライブラリ装置１０１内のドライブ１１４を介して、光ディスクに書き込む手順は以下の通りである。
【００６４】
バッファリングサーバ１０２は、後述するボリューム情報テーブル５１７に基づき、ホストから受信したファイルサイズ以上の空きが存在するボリューム番号（Ａ）とボリュームアドレス（Ｂ）を調べる。空きが無かった場合は、管理サーバ１０３を介して、未使用のカートリッジを挿入するようにシステム管理者に通知してもよい。
【００６５】
空きがあった場合、バッファリングサーバ１０２は、ボリューム番号（Ａ）と、後述するディスク情報テーブル５２４と、に基づき、光ディスク搬送装置１１３に対して、該当するディスク番号に対応した光ディスクをカートリッジから取出し、ドライブ１１４に搬送するように指示する。光ディスクの記録可能領域の先頭アドレス（Ｂ）と、ファイルサイズ（Ｃ）と、ホスト計算機１０５から受信したファイルと、をパラメータとして、光ディスクライブラリ装置１０１に対してライトコマンドを送信する。
【００６６】
光ディスクライブラリ装置１０１は、バッファリングサーバ１０２から、ライトコマンドを受信すると、ドライブ１１４に格納された光ディスクに、ライトコマンドにパラメータとして含まれるアドレス（Ｂ）とファイルサイズ（Ｃ）に基づき、ファイルをライトし、バッファリングサーバ１０２に対してライト完了を通知する。
【００６７】
バッファリングサーバ１０２はライト完了通知を受け取ると、ライトしたファイルサイズに基づき、ボリューム情報テーブル５１７の使用済み容量を更新する。
【００６８】
バッファリングサーバ１０２は、光ディスクへの格納が済んだファイルを、ストレージ装置１０４から削除してもよい。
【００６９】
バッファリングサーバ１０２は、ホスト１０５から受信したファイル格納コマンドに含まれるファイルパス、ファイルサイズと、当該ファイルが格納された論理ボリューム番号、論理アドレスと、を記憶する。光ディスクに格納したファイル毎に存在するこれらの情報を纏めてスタブ情報と呼ぶ。また、当該ファイルを格納した光ディスクに含まれるカートリッジを識別するカートリッジ情報テーブルや、当該ファイルを所有するアカウントや割り当てられた記憶領域であるシェアを識別するアカウント情報テーブルやシェア情報テーブルを記憶する。
【００７０】
スタブ情報は、後述するカートリッジ毎の共通情報やカートリッジ毎のパステーブル、ファイル毎の記録位置テーブル、ハッシュテーブル、衝突テーブルが含まれる。
【００７１】
なお、バッファリングサーバ１０２は、ホスト計算機１０５に対して、ファイル格納コマンドの処理が完了した旨の通知を、ファイルをストレージ装置１０４に記憶した時点で行う構成でもよいし、或いは、光ディスクライブラリ装置１０１からファイルのライト完了通知を受け取り、スタブ情報を作成した時点で行う構成でもよい。一般に利用されるのは前者であって、その理由は、ホスト計算機１０５から受信したファイルをストレージ装置１０４に記憶する処理よりも、ストレージ装置１０４から読み出したファイルを光ディスクライブラリ装置１０１内のドライブ１１４を介して光ディスクに書き込む処理の方がずっと遅いためである。
【００７２】
以上が、ホストからのファイル格納コマンド受信時のバッファリングサーバ１０２と光ディスクライブラリ装置１０１の基本的動作である。
【００７３】
＜ホスト計算機１０５からのファイル読み出しコマンド受信時のバッファリングサーバ１０２と光ディスクライブラリ装置１０１の基本的動作＞
バッファリングサーバ１０２は、ホストＩ／Ｆを介して、いずれかのホスト計算機１０５からファイル読み出しコマンドを受信した場合、バッファリングサーバ１０２は、そのファイル読み出しコマンドにパラメータで指定されるファイルパスが、前述したスタブ情報の一部として記憶されているか否かを調べる。
【００７４】
ファイルパスがスタブ情報の一部として記憶されている場合、バッファリングサーバ１０２は、そのファイルパスによって一意に識別できるスタブ情報との中に含まれるボリューム番号（Ａ）、記録アドレス（Ｂ）、ファイルサイズ（Ｃ）を取得する。ファイルパスがスタブ情報の一部として記憶されていない場合、管理サーバ１０３を介して、システム管理者に対して、ホスト計算機１０５から受信したファイル読み出しコマンドの失敗を通知しても良い。
【００７５】
ファイルパスがスタブ情報の一部として記憶されている場合、バッファリングサーバ１０２は、ボリューム番号（Ａ）と、後述するディスク情報テーブル５２４と、に基づき、読み出し対象となっているファイルが格納されているカートリッジ番号を取得する。バッファリンングサーバ１０２は、ディスク情報テーブル５２４内のオンライン／オフライン属性情報に基づき、カートリッジ番号に対応するカートリッジが、光ディスクライブラリ装置内に存在するかどうかという情報を得る。カートリッジ番号に対応するカートリッジが光ディスクライブラリ装置１０１内に存在する場合、ボリューム番号（Ａ）と、ディスク情報テーブル５２４と、に基づき、読み出し対象となっているファイルが格納されているディスク番号を取得し、光ディスク搬送装置１１３に対して、ディスク番号に対応した光ディスクをカートリッジから取出し、ドライブ１１４に搬送するように指示する。バッファリングサーバ１０２は、光ディスクライブラリ装置に対して、記録アドレス（Ｂ）と、ファイルサイズ（Ｃ）と、をパラメータとして、光ディスクライブラリ装置１０１に対してリードコマンドを送信する。
【００７６】
光ディスクライブラリ装置１０１は、ドライブ１１４に格納された光ディスクから、リードコマンドにパラメータとして含まれるボリュームアドレス（Ｂ）とファイルサイズ（Ｃ）に基づき、ファイルを読み出し、バッファリングサーバ１０２に対して送信する。また、光ディスクライブラリ装置１０１は、バッファリングサーバ１０２へのファイルの送信が終わった時点で、バッファリングサーバ１０２に対して、リード完了を通知する。
【００７７】
バッファリングサーバ１０２はリード完了通知を受け取ると、光ディスクライブラリ装置から読み出したファイルを、ホスト計算機１０５に送信し、送信が終わった時点でファイル読み出しコマンドの完了を通知する。
【００７８】
以上が、ホストからのファイル読み出しコマンド受信時のバッファリングサーバ１０２と光ディスクライブラリ装置１０１の基本的動作である。
【００７９】
＜光ディスクライブラリ装置１０１のＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック＞
図３に、光ディスクライブラリ装置１０１のＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック図を示す。
【００８０】
図３によると、光ディスクライブラリ装置１０１のプログラム内は、サーバコマンド制御部３１１と、資源管理部３１２と、から構成される。
【００８１】
サーバコマンド制御部３１１は、バッファリングサーバ１０２から、バッファリングサーバＩ／Ｆを介して、ライトコマンドあるいはリードコマンドを、受信すると、ライトコマンドあるいはリードコマンドのパラメータで指定される論理ボリューム内の論理アドレスから、指定サイズ分のデータをライトあるいはリードする。
【００８２】
資源管理部３１２は、光ディスクライブラリ装置内のカートリッジ装填状況を監視し、装填されたカートリッジあるいはカートリッジ内部のディスクの管理情報（ディスクの種別、容量、空き容量、属性）を管理サーバに通知し、ディスク情報テーブル５２４に未登録であれば登録する。
【００８３】
＜バッファリングサーバのＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック＞
図４に、バッファリングサーバ１０２のＣＰＵ内のローカルメモリに展開されているプログラムの機能ブロック図を示す。
【００８４】
図４によると、バッファリングサーバ１０２のプログラム内は、ホストコマンド制御部４１１と、記録位置管理部４１２と、マイグレーション制御部４１３と、から構成される。
【００８５】
ホストコマンド制御部４１１は、ホスト計算機１０５から、ホストＩ／Ｆを介して、ファイル格納コマンドを受信すると、ストレージ装置１０４上のパラメータで指定されるファイルパスにファイルを格納する。
【００８６】
また、ホストコマンド制御部４１１は、ホスト計算機１０５から、ホストＩ／Ｆを介して、ファイル読み出しコマンドを受信すると、ストレージ装置１０４あるいはバッファリングサーバ１０２の制御用メモリに存在するファイルのスタブ情報に基づき、ボリューム番号と、ボリュームアドレスと、ファイルサイズを取得し、これらをパラメータとして光ディスクライブラリ装置に対して、リードコマンドを発行する。光ディスクライブラリ装置からファイルを読み出した場合、それをホスト計算機１０５に対して送信する機能を有する。
【００８７】
記録位置管理部４１２は、バッファリングサーバ内の制御用メモリに格納されている管理情報の記録、更新、読み出しなどの処理を行う。これらの管理情報をストレージ装置１０４に書き込み、読み出しする処理を行う。
【００８８】
マイグレーション制御部４１３は、ホスト計算機１０５から受信し、ストレージ装置１０４に格納されたファイルを、光ディスクライブラリ装置１０１に対してライトする機能を有する。
【００８９】
図５は、バッファリングサーバ（１０２）内の制御用メモリに保存される管理テーブルを示す。
【００９０】
図６は、カートリッジ毎の共通情報５１１の構成を示す。
【００９１】
バージョン情報６１１は、管理情報の書式やハッシュ演算方式などを規定した規格のバージョンを示す。
【００９２】
最古記録時刻６１２は、カートリッジに記録されたファイルの記録時刻のうち、もっとも古い時刻を示す。
【００９３】
最新記録時刻６１３は、カートリッジに記録されたファイルの記録時刻のうち、もっとも新しい時刻を示す。
【００９４】
ファイル数６１４は、カートリッジに記録されたファイルの総数を示す。
【００９５】
サイズ６１５は、カートリッジに記録されたファイルの累計サイズを示す。
【００９６】
＜カートリッジ毎のパステーブル＞
図７にカートリッジ毎のパステーブル５１２の構成を示す。
【００９７】
パス数７１１は、カートリッジに含まれるファイルとディレクトリのパスの総数を示す。
【００９８】
リザーブ７１２は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【００９９】
ファイル＃Ｎ記録位置テーブルの格納場所７１３は、パステーブル５１２に含まれるＮ番目のファイルもしくはディレクトリのパスに関する情報であり、後述するパス、ディレクトリ／ファイル識別フラグ、記録位置テーブルポインタ、リザーブから構成される。
【０１００】
パス７１７は、ファイル＃Ｎのパスを格納するフィールドである。最大パス長として１０２４バイトを想定した場合、フィールド長は１０２４バイトである。
【０１０１】
ディレクトリ／ファイル識別フラグ７１６は、ファイル＃Ｎがファイルであれば０、ディレクトリであれば１を格納するフィールドである。
【０１０２】
記録位置テーブルポインタ７１５は、後述するファイル毎の記録位置テーブル内の先頭からのオフセット値を格納するフィールドである。
【０１０３】
記録位置数７１８は、記録位置テーブルポインタ７１５が指すファイル毎の記録位置テーブルの数を示している。
【０１０４】
リザーブ７１４は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【０１０５】
なお、カートリッジ毎のパステーブル５１２は、実施例に応じて構成を変えることができるため、それぞれの構成は後述する実施例の中で説明する。
【０１０６】
＜ファイル毎の記録位置テーブル＞
図８にファイル毎の記録位置テーブル５１３の構成を示す。
【０１０７】
ディレクトリ数８１１は、当該カートリッジに記録されたディレクトリの総数を格納するフィールドである。
【０１０８】
リザーブ８１２は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【０１０９】
ディレクトリ＃１記録位置８１４は、当該カートリッジに記録されたディレクトリのひとつに関する情報を示し、ディレクトリ名、記録時刻、サイズ、属性から構成される。
【０１１０】
ディレクトリ名８１５は、ディレクトリの名称を文字列で格納するフィールドである。
【０１１１】
記録時刻８１６は、ディレクトリ＃１を記録した時刻を格納するフィールドである。
【０１１２】
サイズ８１７は、ディレクトリ＃１のサイズを格納するフィールドである。
【０１１３】
属性８１８は、ディレクトリ＃１の属性を格納するフィールドである。例えば、読み取り専用／書き換え可能、などの属性がビットフィールドで格納される。
【０１１４】
ファイル数８２１は、当該カートリッジに記録されたファイルの総数を格納するフィールドである。
【０１１５】
リザーブ８２２は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【０１１６】
ファイル＃１記録位置８２３は、当該カートリッジに記録されたファイルのひとつに関する情報を示し、ファイル名、記録時刻、サイズ、属性から構成される。
【０１１７】
ファイル名８２４は、ファイルの名称を文字列で格納するフィールドである。
【０１１８】
記録時刻８２５は、ファイル＃１を記録した時刻を格納するフィールドである。
【０１１９】
サイズ８２６は、ファイル＃１のサイズを格納するフィールドである。
【０１２０】
属性８２７は、ファイル＃１の属性を格納するフィールドである。例えば、読み取り専用／書き換え可能、などの属性がビットフィールドで格納される。
【０１２１】
このように、ディレクトリ毎に、もしくはファイル毎に、当該カートリッジ内すべての記録位置を記憶することで、バッファリングサーバ１０２は、図１２に示すような流れでファイルを記録し、図１３に示すような流れでファイルを読み出す。
【０１２２】
＜アカウント情報テーブル＞
図９にバッファリングサーバで管理しているアカウント情報テーブル５１４の構成を示す。
【０１２３】
アカウント名９１１は、ユーザが使用するアカウント名を文字列として格納するフィールドである。
【０１２４】
ユーザＩＤ９１２は、アカウント名９１１に対応したアカウントを管理するためのＩＤを格納するフィールドである。
【０１２５】
グループＩＤ９１３は、アカウントが所属するグループを管理するためのＩＤを格納するフィールドである。
【０１２６】
アカウントはいずれかのグループに所属し、所属するグループ内ではユニークなユーザＩＤを持つ。
【０１２７】
このように光ディスクライブラリ装置にアクセスするアカウントを管理することで、登録されたアカウントごとに記録領域を割り当てて、割り当てられた領域以外の領域へのアクセスを遮断することが可能になる。
【０１２８】
＜シェア情報テーブル＞
図１０にバッファリングサーバで管理しているシェア情報テーブル５１５の構成を示す。
【０１２９】
シェアとは、光ディスクライブラリ装置の全記録領域を、カートリッジ単位で分割した領域である。各シェアの領域サイズはユーザが設定可能である。
【０１３０】
所有者ＩＤ１０１１は、シェアごとに割り当てられた、シェア識別用のＩＤを格納するフィールドである。
【０１３１】
シェア名１０１２は、シェアに付与されたシェア名を文字列で格納するフィールドである。
【０１３２】
アカウント数１０１３は、シェアに対するアクセスを許可された、シェアごとに登録されているアカウントの数を格納するフィールドである。
【０１３３】
アカウントポインタ１０１４は、シェアに対するアクセスを許可されたアカウント名一覧へのリンクを格納するフィールドである。図１０では、アカウントポインタ０ｘ２０００１０００が、シェア登録アカウント名１０１５を指し、アカウントポインタ０ｘ２０００１０４０が、シェア登録アカウント名１０１６を指す。
【０１３４】
シェア登録アカウント名１０１５は、シェアに対するアクセスを許可されたアカウント名一覧である。図１０では、シェア名”Japan”のシェアに対して、"sales_dept_0"、"sales_dept_1"、"randd_dept_0" の３つのアカウントが登録されている。
【０１３５】
シェア登録アカウント名１０１６は、シェアに対するアクセスを許可されたアカウント名一覧である。図１０では、シェア名”US”のシェアに対して、"sales_dept_0"、"sales_dept_1"、"randd_dept_1" の３つのアカウントが登録されている。
【０１３６】
このように、シェアを管理することで、あるサイズの記録領域、すなわちシェアに対して、複数のアカウントのアクセスを許可し、他のアカウントからのアクセスを排除することが可能となる。
【０１３７】
＜カートリッジ情報テーブル＞
図１１にバッファリングサーバで管理しているカートリッジ情報テーブル５１６の構成を示す。
【０１３８】
カートリッジＩＤ１１１１は、光ディスクライブラリ装置でアクセスする各カートリッジに割り当てられたユニークなＩＤを格納するためのフィールドである。
【０１３９】
所有者ＩＤ１１１２は、カートリッジが割り当てられたシェアを識別するための所有者ＩＤを格納するためのフィールドである。所有者ＩＤ１１１２が、図１０の所有者ＩＤ１０１１と一致していれば、同じ所有者ＩＤとみなすことができる。
【０１４０】
オンライン１１１３は、カートリッジがオンライン状態にあるか、オフライン状態にあるかを識別するためのフラグを格納するためのフィールドである。オンラインであれば１、オフラインであれば０を設定することで識別可能である。
【０１４１】
総容量１１１４は、カートリッジの記録領域の総容量を格納するためのフィールドである。
【０１４２】
残容量１１１５は、カートリッジの記録領域の総残量、すなわち未記録の領域の容量を格納するためのフィールドである。
【０１４３】
このように、シェアに割り当てられたカートリッジを管理することで、カートリッジごとにシェアの記録領域の容量や残量を把握することができ、カートリッジの残量がなくなればユーザに交換を促すことが可能になる。また、シェアに割り当てられたカートリッジを識別可能であるので、例えば、記録中に記録エラーが発生した場合、それがどのシェアのどのカートリッジで発生したかを把握でき、シェア情報テーブル５１５と組み合わせることで、エラーが影響するアカウントに対してエラー通知を行うことが可能となる。
【０１４４】
＜ボリューム情報テーブル＞
図３２にボリューム情報テーブル５１７の構成を示す。
【０１４５】
図３２によると、ボリューム情報テーブル５１７は、ボリューム番号フィールド（３２１１）と、ボリューム容量フィールド（３２１２）と、使用済み容量フィールド（３２１３）と、から構成される。
【０１４６】
ボリューム番号は、既に実記憶領域が割り当てられたアクセス対象として、論理ボリュームを一意に識別するための情報であって、ボリューム番号フィールドの各エントリは、ホスト計算機１０５から受信したファイルが格納されている論理ボリュームのボリューム番号が格納される。
【０１４７】
ボリューム容量は、論理ボリュームの容量を示す情報であって、ボリューム容量フィールドの各エントリは、前述した論理ボリューム番号に対応するボリュームの容量（例えば、単位はＢｙｔｅ）が格納される。
【０１４８】
使用済み容量は、論理ボリュームにおいて、ファイル格納コマンドによってデータがライト済みの領域の容量を示す情報であって、ボリューム容量フィールドの各エントリは、前述した論理ボリューム番号に対応するボリュームのライト済み領域の容量（例えば、単位はＢｙｔｅ）が格納される。
【０１４９】
ボリューム情報テーブルは、バッファリングサーバ１０２の制御用メモリに格納されていても良いし、予め定めた光ディスクに格納して、必要に応じて光ディスクライブラリ装置１０１を通じてバッファリングサーバ１０２の制御用メモリやＣＰＵ内部のローカルメモリに読み込んでもよい。
【０１５０】
＜ポインタテーブル＞
図１８はポインタテーブルを示した図である。
【０１５１】
オンライン状態のカートリッジのポインタテーブル５２０は、カートリッジＩＤ１８１１と、ポインタ１８１２からなる。
【０１５２】
カートリッジＩＤ１８１１は、光ディスクライブラリ装置に装填されたオンライン状態のカートリッジのカートリッジＩＤが設定されるフィールドである。
【０１５３】
ポインタ１８１２は、バッファリングサーバ内の制御用メモリ上に展開されている、カートリッジ毎の共通情報５１１、カートリッジ毎のパステーブル５１２、ファイル毎の記録位置テーブル５１３、アカウント情報テーブル５１４、シェア情報テーブル５１５、カートリッジ情報テーブル５１６、ボリューム情報テーブル５１７、削除シェア情報テーブル５１８、削除カートリッジ情報テーブル５１９が格納されたメモリ領域へのポインタを設定するフィールドである。
【０１５４】
オフライン状態のカートリッジのポインタテーブル５２１は、カートリッジＩＤ１８１３と、メタデータカートリッジＩＤ１８１４と、ディスクＩＤ１８１５と、記録位置サイズ１８１６と、ポインタ１８１７からなる。
【０１５５】
カートリッジＩＤ１８１３は、書き込みを行ったカートリッジもしくは登録を行ったカートリッジのカートリッジＩＤを設定するフィールドである。オフラインのカートリッジが対象である。
【０１５６】
メタデータカートリッジＩＤ１８１４は、当該カートリッジＩＤのカートリッジに関するメタデータを記録した光ディスクを含むカートリッジのカートリッジＩＤを設定するフィールドである。
【０１５７】
ディスクＩＤ１８１５は、当該カートリッジＩＤのカートリッジに関するメタデータを記録した光ディスクのディスクＩＤを設定するフィールドである。
【０１５８】
開始位置サイズ１８１６は、当該光ディスク上の、スタブ情報ファイルが記録された位置とサイズを設定するフィールドである。
【０１５９】
ポインタ１８１７は、バッファリングサーバ内の制御用メモリ上に展開されている、カートリッジ毎の共通情報５１１、カートリッジ毎のパステーブル５１２、ファイル毎の記録位置テーブル５１３、アカウント情報テーブル５１４、シェア情報テーブル５１５、カートリッジ情報テーブル５１６、ボリューム情報テーブル５１７、削除シェア情報テーブル５１８、削除カートリッジ情報テーブル５１９が格納されたメモリ領域へのポインタを設定するフィールドである。
【０１６０】
ポインタテーブルもオフライン状態のポインタテーブルリスト５２５は、メタデータカートリッジＩＤ１８１８と、ディスクＩＤ１８１９と、記録位置サイズ１８２０と、最小ＯＩＤ最大ＯＩＤ１８２１からなる。
【０１６１】
メタデータカートリッジＩＤ１８１８は、ポインタテーブル５２１が記録された光ディスクを含むカートリッジのカートリッジＩＤを格納するフィールドである。
【０１６２】
ディスクＩＤ１８１９は、ポインタテーブル５２１が記録された光ディスクの光ディスクＩＤを格納するフィールドである。
【０１６３】
開始位置サイズ１８１６は、当該光ディスク上の、ポインタテーブル５２１が記録された位置とサイズを設定するフィールドである。
【０１６４】
最小ＯＩＤ最大ＯＩＤ１８２１は、当該ポインタテーブル５２１に含まれるシェアのＯＩＤの最大値と最小値を格納するフィールドである。
【０１６５】
＜削除シェア情報テーブル、削除カートリッジ情報テーブル＞
図１７は削除シェア情報テーブルと、削除カートリッジ情報テーブルを示した図である。
【０１６６】
削除シェア情報テーブル５１８は、シェアのシェア名１７１１からなる。
【０１６７】
シェア名１７１１は、登録済みのシェアが削除された場合に、削除されたシェアのシェア名の文字列を格納するフィールドである。
【０１６８】
図１０のシェア情報テーブルと組み合わせて参照することで、削除されたシェアおよび削除されていないシェアを特定することが可能となる。特に、シェア情報テーブルを光ディスクに書き込んだ場合、書き換え不可能な光ディスクに対してシェア情報を書き換えて削除とすることはできないため、削除シェア情報テーブル５１８に登録することで、削除されたシェアの情報を保持することが可能となる。
【０１６９】
削除カートリッジ情報テーブル５１９は、カートリッジのカートリッジＩＤ１７１２からなる。
【０１７０】
カートリッジＩＤ１７１２は、登録済みのカートリッジが削除された場合に、削除されたカートリッジのカートリッジＩＤを格納するフィールドである。
【０１７１】
図１１のカートリッジ情報テーブルと組み合わせて参照することで、削除されたカートリッジおよび削除されていないカートリッジを特定することが可能となる。特に、カートリッジ情報テーブルを光ディスクに書き込んだ場合、書き換え不可能な光ディスクに対してカートリッジ情報を書き換えて削除とすることはできないため、削除カートリッジ情報テーブル５１９に登録することで、削除されたシェアの情報を保持することが可能となる。
【０１７２】
＜ディスク情報テーブル＞
図３３はディスク情報テーブルを示した図である。
【０１７３】
ディスク情報テーブル５２４は、ボリューム番号３３１１と、ディスク番号３３１２と、カートリッジＩＤ３３１３からなる。
【０１７４】
ボリューム番号３３１１は、既に実記憶領域が割り当てられたアクセス対象として、論理ボリュームを一意に識別するための情報であって、ボリューム番号フィールドの各エントリは、ホスト計算機１０５から受信したファイルが格納されている論理ボリュームのボリューム番号が格納される。
【０１７５】
ディスク番号３３１２は、ディスク製品出荷時にディスク毎に一意に付けられる固有の製品番号である。
【０１７６】
カートリッジＩＤ３３１３は、カートリッジ製品出荷時にカートリッジごとに一意につけられる固有の製品番号である。カートリッジにはフラッシュメモリなどの記憶領域があり、カートリッジＩＤや格納ディスク枚数や格納したディスクの情報（容量、残量、種別）を保持可能である。光ディスクライブラリ装置にカートリッジを装填すると、光ディスクライブラリ装置はこの記憶領域にアクセスし、情報の読み出しと書き換えが可能である。アクセスには、無線通信を使用しても良いし、コネクタを介して接続し通信しても良い。
【０１７７】
なお、ハッシュテーブル５２２と、衝突テーブル５２３については、後述する。
【０１７８】
＜光ディスクライブラリ装置へのカートリッジの装填およびディレクトリ情報の格納場所の設定＞
図１２に、光ディスクライブラリ装置へのカートリッジの装填時の処理フローを示す。
【０１７９】
図１２によると、システム管理者は、光ディスクライブラリ装置の空きスロットへ、一つまたは複数の光ディスクを含んだカートリッジを装填する。（Ｓ１２０１）
次に、光ディスクライブラリ装置のプログラム内の資源管理部３１２は、管理サーバ１０３に対して、カートリッジからカートリッジＩＤや総容量、総残量、光ディスクごとの容量、残量などの情報を読み出し、バッファリングサーバの記録位置管理部４１２に通知する。（Ｓ１２０２）
次に、バッファリングサーバ１０２の記録位置管理部４１２は、光ディスクライブラリ装置に過去に装填され、前述のカートリッジ情報テーブル５１６に登録されているかどうかを調べる。これらのテーブルに当該カートリッジが過去に登録されたかどうかを判断するために、例えば、前述のカートリッジ情報テーブル５１６内のカートリッジＩＤに、カートリッジ製品出荷時にカートリッジ毎に付けられる固有の製品番号を登録するように決めておく。その他に、ディスク製品出荷時にディスク毎に付けられる固有の製品番号をディスク番号として登録するように決めておく方法を用いてもよい。（Ｓ１２０３）
カートリッジが前述したカートリッジ情報テーブル５１６に未登録の場合、記録位置管理部４１２は、装填したカートリッジのカートリッジ番号と総容量と総残量と、をテーブルに登録する。また、記録位置管理部４１２は、前述したボリューム情報テーブル５１７に、装填したカートリッジ内の未登録ディスクのディスク番号を登録し、テーブル内で使用されていない論理ボリューム番号を取得し、ディスク番号に割り当て、テーブルに登録する。（Ｓ１２０４）
最後に、記録位置管理部４１２は、装填したカートリッジ番号に基づき、前述したカートリッジ情報テーブル５１６上の、装填したカートリッジ番号に対応するカートリッジのオンライン／オフライン属性に、オンラインに対応する情報を設定する。（Ｓ１２０４）
管理サーバ１０３は、カートリッジ装填後の最新のテーブル情報を管理画面上に表示し、システム管理者に通知する。（Ｓ１２０５）
図３４に、光ディスクライブラリ装置へのカートリッジの装填時の処理フローにおける異常処理フローを示す。
【０１８０】
図３４によると、システム管理者が、光ディスクライブラリ装置の空きスロットへ、一つまたは複数の光ディスクを含んだカートリッジを装填した後、光ディスクライブラリ装置のプログラム内の資源管理部３１２は、管理サーバ１０３に対して、カートリッジからカートリッジＩＤや総容量、総残量、光ディスクごとの容量、残量などの情報をカートリッジから取得する処理を行うが、情報取得処理が失敗した場合は、異常処理を行う。情報取得処理が成功した場合は、バッファリングサーバの記録位置管理部４１２に通知する。登録に失敗する原因としては、カートリッジに記録されているはずの情報が消去されていた場合、もしくは読み出そうとしたがエラーになった場合、読み出しは成功したが情報の内容が不正であった場合（例えば、容量よりも残量が大きい）、が考えられる。（Ｓ３４０３）
次に、バッファリングサーバ１０２の記録位置管理部４１２は、当該カートリッジが、前述のカートリッジ情報テーブル５１６に登録されているかどうかを調べ、未登録の場合、当該カートリッジのカートリッジ番号と総容量と総残量と、をテーブルに登録するが、登録に失敗した場合は、異常処理を行う。登録に成功した場合は、カートリッジ情報テーブル５１６上の、当該カートリッジのカートリッジ番号に対応するカートリッジのオンライン／オフライン属性に、オンラインに対応する情報を設定する。（Ｓ１２０４）
管理サーバ１０３は、カートリッジ装填後の最新のテーブル情報を管理画面上に表示し、システム管理者に通知する。（Ｓ１２０５）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３４０５）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０１８１】
以上が、光ディスクライブラリ装置へのカートリッジの装填処理フローの説明である。
【０１８２】
＜光ディスクへのデータの書き込み＞
光ディスクへのデータの書き込みおよび各種情報テーブルの設定処理は、ストレージ装置１０４に格納されたホスト計算機１０５から書き込まれたファイルの総容量が、一定値（例えば、光ディスクの容量分）を超えることを契機に行う。また、ファイルの総容量が一定値を超えない場合でも、ファイルが書き込まれた時点から一定期間（例えば、１日）を超えた場合に、行ってもよい。また、カートリッジをオフラインにするタイミングを契機としてもよい。
【０１８３】
図１３に、光ディスクへのデータの書き込みおよび各種情報テーブルの設定フローを示す。
【０１８４】
図１３によると、バッファリングサーバ１０２のプログラム内のマイグレーション制御部４１３は、ボリューム情報テーブル５１７を参照し、十分な空き容量を持つボリュームを選択する。（Ｓ１３０１）
空き容量とは、例えば、ボリューム容量から使用済み容量を引いた容量のことであって、十分な空き容量を持つボリュームとは、例えば、光ディスクへの書き込む一つまたは複数のファイルのサイズの総和以上の空き容量を持つボリュームを意味する。
【０１８５】
十分な空き容量を持つボリュームが存在しない場合、マイグレーション制御部４１３は、管理サーバ１０３にその旨を通知し、システム管理者に表示してもよい。
【０１８６】
十分な空き容量を持つボリュームが存在する場合、マイグレーション制御部４１３は、ストレージ装置１０４に記憶している一つまたは複数のファイルを、ストレージＩ／Ｆを介して読み出す。（Ｓ１３０２）
次に、マイグレーション制御部４１３は、ボリューム情報テーブル５１７に基づき、十分な空き容量を持つボリュームのボリューム番号（Ａ）と使用済み容量（ボリュームアドレス（Ｂ））を取得する。
【０１８７】
マイグレーション制御部４１３は、ボリューム番号（Ａ）と、ボリュームアドレス（Ｂ）と、ストレージ装置１０４から読み出した一つまたは複数のファイルのサイズの総和（ファイルサイズ（Ｃ））と、ストレージ装置１０４から読み出した一つまたは複数のファイルと、をパラメータとして、光ディスクライブラリ装置１０１に対してライトコマンドを送信する。
【０１８８】
光ディスクライブラリ装置１０１のプログラム内のサーバコマンド制御部３１１は、バッファリングサーバ１０２から、ライトコマンドを受信すると、ライトコマンドにパラメータとして含まれるボリューム番号（Ａ）と、ボリューム情報テーブル５１７と、ディスク情報テーブル５２４と、に基づき、光ディスク搬送装置１１３に対して、該当するディスク番号に対応した光ディスクをカートリッジから取出し、ドライブ１１４に搬送するように指示する。サーバコマンド制御部３１１は、ドライブ１１４に格納された光ディスク（ディスクＩＤはＺ）に、ボリュームアドレス（Ｂ）とファイルサイズ（Ｃ）に基づき、ファイルをライトし、バッファリングサーバ１０２に対してライト完了を通知する。（Ｓ１３０３）
バッファリングサーバ１０２のプログラム内のマイグレーション制御部４１３は、ライト完了通知を受け取ると、ライトしたファイルサイズ（Ｃ）に基づき、ボリューム情報テーブル５１７の使用済み容量を更新する。更新後の使用済み容量は、更新前の使用済み容量に、ファイルサイズ（Ｃ）を足したものである。即ち、使用済み容量とは、次にファイルを書くことができる開始アドレスを意味する。
【０１８９】
マイグレーション制御部４１３は、光ディスクへのライトされた一つまたは複数のファイルを、ストレージ装置１０４から削除してもよい。
【０１９０】
マイグレーション制御部４１３は、光ディスクへのライトされた一つまたは複数のファイルについて、以下の処理を適用する。バッファリングサーバ１０２は、ボリューム番号（Ａ）と、ファイルサイズ（Ｃ）と、当該ファイルが格納されたボリュームアドレス（Ｂ）と、バッファリングサーバ１０２がホスト計算機１０５に対して提供しているファイルシステム上のファイルの格納場所（ファイルパス（Ｄ））と、を、ファイル毎の記録位置テーブル５１３として記憶する。
【０１９１】
マイグレーション制御部４１３は、カートリッジ毎のパステーブル５１２を探索し、記録済みのファイル＃Ｎ記録位置テーブルの格納場所のパス７１７を、ファイルパス（Ｄ）と比較して、パスの重複がないことを確認し、新規に記録位置テーブルの格納場所を追加し、ファイルパス（Ｄ）をパス７１７に格納し、ディレクトリであるかファイルであるかに応じて、ディレクトリ ／ファイル識別フラグ７１６に１または０を設定する。
【０１９２】
マイグレーション制御部４１３は、ファイル毎の記録位置テーブル５１３に新規に記録位置フィールドを追加し、追加した記録位置フィールドへのポインタを、記録位置テーブルポインタ７１５に設定する。
【０１９３】
マイグレーション制御部４１３は、追加した記録位置フィールドの、ディスクＩＤ８２４と開始位置８２５とサイズ８２６と属性８２７に、それぞれディスクＩＤのＺ、更新前の使用済み容量、ファイルサイズ（Ｃ）、およびＲｅａｄ  Ｏｎｌｙの属性を設定する。属性は、Ｒｅａｄ  Ｏｎｌｙ以外にも、ビットフィールドを割り当てることで設定可能である。
【０１９４】
マイグレーション制御部４１３は、ボリューム（Ａ）に記録されるファイルの、カートリッジ毎のパステーブル５１２と、ファイル毎の記録位置テーブル５１３を、ボリューム（Ａ）のスタブ情報ファイルとして、ボリューム番号（Ａ）に対応するボリューム（即ち、光ディスク）に、前述したファイルのライト処理と同様の方法で格納してもよい。このとき、前述した（Ｓ１３０１）の処理は、ボリューム（Ａ）にライトした一つまたは複数のファイルのサイズとスタブ情報ファイルのサイズと、の総和が、光ディスク容量を超えないように行う。（Ｓ１３０４）
マイグレーション制御部４１３は、カートリッジ毎の共通情報５１１の最新記録時刻６１３を更新し、必要であれば最古記録時刻６１２を更新し、記録したファイルをファイル数６１４に加算して更新し、記録したファイルの総ファイルサイズをサイズ６１５に関して更新し、カートリッジ情報テーブル５１６の残容量１１１５から記録したファイルの総ファイルサイズを減算して更新する。また、ボリューム情報テーブル５１７の使用済み容量３２１３から記録したファイルの総ファイルサイズを減算して更新する。（Ｓ１３０５）
図３５に、光ディスクへのデータの書き込みおよび各種情報テーブルの設定フローにおける異常処理フローを示す。
図３５によると、マイグレーション制御部４１３は、ボリューム情報テーブル５１７を参照し、十分な空き容量を持つボリュームを選択しようとするが、もし十分な空き容量を持つボリュームが存在しない場合、異常処理を行う。また、もし管理情報に空きが無い場合（例えば、記録位置テーブルの登録上限数に達した場合、パステーブルの登録上限数に達した場合）、異常処理を行う。（Ｓ３５０１）
十分な空き容量を持つボリュームが存在する場合、マイグレーション制御部４１３は、ストレージ装置１０４に記憶している一つまたは複数のファイルを、ストレージＩ／Ｆを介して読み出すが、ファイル読み出しのエラーが発生した場合、異常処理を行う。（Ｓ３５０２）
マイグレーション制御部４１３は、光ディスクライブラリ装置１０１に対してライトコマンドを送信するが、ファイル書き込みのエラーが発生した場合は、リトライ処理を行い、リトライ処理の回数があらかじめ設定された上限に達すると異常処理を行う。リトライ処理は、書き込みエラーが発生した光ディスクを記録再生不可ボリュームとして登録して破棄し、新規に未記録のボリュームを選択し、破棄したボリュームに記録済みのファイルを再度記録し直す、という処理が考えられる。もしくは、書き込みエラーが発生したファイルは記録失敗として破棄するが、それ以前に記録済みのファイルは正常に読み出せることと記録した値と読み出した値が一致することを確認した上で、記録成功として有効なファイルとみなし、当該ボリュームへの書き込みを終了し、新規に未記録のボリュームを選択し、書き込みエラーが発生したファイルを新規ボリュームに記録し直す、という処理が考えられる。リトライ処理が発生した場合は、管理サーバ１０３が、エラー情報とリトライ処理に関する情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３５０３）
マイグレーション制御部４１３は、（Ｓ１３０４）と（Ｓ１３０５）を実行し、書き込み後のカートリッジ情報テーブルを管理画面に表示し、システム管理者に通知する。（Ｓ３５０４）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３５０５）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０１９５】
以上が、光ディスクへのデータの書き込みおよび各種情報テーブルの設定処理である。
【０１９６】
＜ホスト計算機の光ディスクに格納されたファイルの読み出し＞
図１４に、ホスト計算機１０５の光ディスクに格納されたファイルの読み出し処理のフローを示す。
【０１９７】
図１４によると、ホスト計算機１０５から、読み出す対象ファイルのファイルパスが入力され、入力されたファイルパスを解析することで、ファイルパスに含まれるシェア名を抽出する。シェア情報テーブル５１５を参照し、シェア名を元に、シェア名に割り当てられた所有者ＩＤを取得することができる。次に、カートリッジ情報テーブル５１６を参照し、所有者ＩＤを元に、所有者ＩＤに割り当てられたカートリッジＩＤを取得することができる。（Ｓ１４０１）
ポインタテーブル５２０を参照し、当該カートリッジＩＤ１８１１が登録されているか確認し、登録されていれば、オンラインであると分かり、未登録であれば、オンラインで無いか、もしくは新規登録が必要なカートリッジであると分かる。ポインタ１８１２にＮＵＬＬが設定されていれば、カートリッジ毎のパステーブル５１２はオンラインではないと判断でき、ＮＵＬＬではない値が設定されていれば、その値はカートリッジ毎のパステーブル５１２へのポインタが設定されており、オンラインであると判別可能である。（Ｓ１４０２）
オンラインで無い場合は、ポインタテーブル５２１を参照し、カートリッジＩＤが一致するメタデータカートリッジおよびディスクＩＤと記録位置を取得し、当該光ディスクをドライブに装填し、パステーブルおよび記録位置テーブルを光ディスクから読み出す。（Ｓ１４０３）パステーブルを探索し、パス７１７の文字列が一致する格納位置７１３を取得し、記録位置テーブルポインタ７１５から、ファイルの記録位置を取得し、ディスクＩＤ、開始位置、サイズを取得し、光ディスクと記録位置を特定する。（Ｓ１４０４）
オンラインである場合は、ポインタをたどってカートリッジ毎のパステーブル５１２を取得する。ファイルパスを元に、カートリッジ毎のパステーブルを探索し、パス７１７の文字列が一致すれば、その記録位置テーブルの格納場所７１３を参照する。記録位置テーブルポインタ７１５から、ファイルの記録位置８２３を取得し、ディスクＩＤ８２４、開始位置８２５、サイズ８２６を取得し、光ディスクと記録位置を特定する。また、必要に応じて属性８２７を参照する。（Ｓ１４０４）
光ディスクをドライブに装填し、記録位置にアクセスしてファイルを光ディスクから読み出す。（Ｓ１４０５）
図３６に、ホスト計算機１０５の光ディスクに格納されたファイルの読み出し処理フローにおける異常処理フローを示す。
【０１９８】
図３６によると、ファイルパス、シェア名、所有者ＩＤ、カートリッジＩＤの順に取得する処理において、取得エラーが発生した場合、異常処理を行う。取得エラーが発生した原因としては、参照する管理情報が失われて存在しない、などが考えられる。（Ｓ３６０１）
カートリッジ毎のパステーブル５１２がオンラインで無い場合は、パステーブルおよび記録位置テーブルを光ディスクから読み出すために当該光ディスクを搬送するが、搬送が失敗した場合、異常処理を行う。（Ｓ３６０３）
搬送が成功した場合、パステーブルを探索し、光ディスクと記録位置を特定しようとするが、該当する管理情報が見つからない場合は、異常処理を行う。取得エラーが発生した原因としては、参照する管理情報が失われて存在しない、などが考えられる。（Ｓ３６０４）
記録位置を特定したら、光ディスクをドライブに搬送し、記録位置にアクセスしてファイルを光ディスクから読み出すが、読み出しエラーが発生した場合、異常処理を行う。（Ｓ３６０５）
読み出しが成功した場合、読み出したファイルに関する管理情報を管理画面に表示し、システム管理者に通知する。（Ｓ３６０６）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３６０７）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０１９９】
以上が、ホスト計算機１０５の光ディスクに格納されたファイルの読み出し処理の説明である。
【０２００】
＜光ディスクからの記録位置テーブル５１３のリストア処理＞
図１５に、光ディスクからの記録位置テーブル５１３のリストア処理のフローを示す。
【０２０１】
図１５によると、カートリッジ毎のパステーブルがオンラインである場合、すでにオンライン状態にあるため特に処理は発生しない。（Ｓ１５０１）
カートリッジ毎のパステーブルがオンラインで無い場合（Ｓ１５０１）、ポインタテーブル５２１を参照し、カートリッジＩＤが一致するメタデータカートリッジおよびディスクＩＤと記録位置を取得し、当該光ディスクをドライブに装填し、パステーブルおよび記録位置テーブルを光ディスクから読み出す。（Ｓ１５０２）
図３７に、光ディスクからの記録位置テーブル５１３のリストア処理フローにおける異常処理フローを示す。
【０２０２】
図３７によると、カートリッジ毎のパステーブルがオンラインで無い場合（Ｓ３７０１）、記録位置テーブルを記録した光ディスクをドライブに装填するために、光ディスク搬送を行うが、搬送エラーが発生した場合、異常処理を行う。（Ｓ１５０２）
搬送エラーが発生しなかった場合、該当する管理情報
リストアが成功した場合、リストアした管理情報を管理画面に表示し、システム管理者に通知する。（Ｓ３７０５）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３７０６）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２０３】
光ディスクからのディレクトリ毎の記録位置テーブル５１３のリストア処理は、例えば、当該計算機システムにおいて、バッファリングサーバや、バッファリングサーバ１０２など、光ディスク以外のデバイスをリプレースする契機等に行うことが考えられる。こうすることで、装置リプレースに伴うシステム移行が必要な場合でも、移行元計算機システムから移行先計算機システムへ、記録位置テーブル５１３を引き継ぐことができ、ビジネス継続性が維持されるからである。
【０２０４】
＜光ディスクライブラリ装置からのカートリッジ取り外し処理＞
図１６に、光ディスクライブラリ装置からカートリッジを取り外す際に行う処理フローを示す。
【０２０５】
図１６によると、ポインタテーブル５２０を参照し、取り外すカートリッジのカートリッジＩＤが指すポインタから、カートリッジ毎のパステーブル５１２を参照し、パス数７１１が０か正の数かどうかにより、取り外すカートリッジが記録済みディスクを含むかどうか判断する。（Ｓ１６０１）
記録済みディスクを含む場合は、取り外すカートリッジのカートリッジＩＤが指すポインタから、カートリッジ毎のパステーブル５１２を特定し、スタブ情報ファイルとして光ディスクに書き出し、カートリッジ毎のパステーブル５１２の指す、ファイル毎の記録位置テーブル５１３をスタブ情報ファイルとして光ディスクに書き出し、ポインタテーブル５２０を更新して、取り外すカートリッジＩＤのポインタをＮＵＬＬに設定し、オフラインであることを示すようにし、ポインタテーブル５２１を更新して、カートリッジＩＤ１８１３に取り外すカートリッジのカートリッジＩＤを追記し、カートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３を書き出した光ディスクが含まれるカートリッジのカートリッジＩＤと、その光ディスクのディスクＩＤを、それぞれメタデータカートリッジＩＤ１８１４と、ディスクＩＤ１８１５に記録し、光ディスク上に書き込んだ開始位置とサイズを、開始位置サイズ１８１６に記録し、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録する。（Ｓ１６０２）
格納していない場合は、特に更新処理は発生しない。
【０２０６】
図３８に、光ディスクライブラリ装置からカートリッジを取り外す際に行う処理フローにおける異常処理フローを示す。
【０２０７】
図３８によると、取り外すカートリッジが記録済みディスクを含むかどうか判断し（Ｓ３８０１）、記録済みディスクを含む場合は、スタブ情報ファイルを光ディスクに書き込むが、書き込みエラーが発生した場合、異常処理を行う。（Ｓ３８０２）
記録済みディスクを含まない場合は、未記録のカートリッジをとりはずことであるため、特に更新処理は発生せず、取り外した後のカートリッジ情報を表示し、システム管理者に通知する。（Ｓ３８０３）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３８０４）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２０８】
以上が、光ディスクライブラリ装置からカートリッジを取り外す際に行う処理フローの説明である。
【０２０９】
光ディスクライブラリ装置からカートリッジを取り外す際に行う処理フローは、例えば、前述の（Ｓ１３０３）で説明したような、管理サーバを介して、システム管理者に促して、該当するカートリッジを光ディスクライブラリ装置に装填しようとした場合に、光ディスクライブラリ装置の空きを作るため、既に装填済みの他のカートリッジを取り外すときに実施される。また、他のケースとして、例えば、装置リプレースに伴うシステム移行が必要な場合に、移行元計算機システムから光ディスクを含むカートリッジを取り外すときに実施される。
【０２１０】
ポインタテーブル５２１のポインタ１８１７に、カートリッジ毎のパステーブル５１２へのポインタを設定することで、取り外してオフラインにしたカートリッジに含まれるファイルの情報も、当該メタデータカートリッジを装填することなく取得できるという効果がある。もしバッファリングサーバ内の制御用メモリ 
の空き容量が不足する場合は、光ディスクに記録済みのカートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３を、アクセス頻度の低いカートリッジから優先して削除することで、容量を確保でき、さらにアクセス頻度の高いカートリッジのファイルは、当該メタデータカートリッジを装填することなく取得できるという効果がある。
【０２１１】
ここまで、カートリッジ１１５について、複数のカートリッジが存在する場合も、それらを特に区別なく扱う前提で説明したが、カートリッジ１１５が複数ある場合は、そのうちのひとつのカートリッジをメタデータ専用のカートリッジとし、他をユーザデータ専用のカートリッジとする実施例も考えられる。これにより、メタデータ専用のカートリッジを優先的にオンラインにする処理が可能となる。 
メタデータ専用カートリッジを光ディスクライブラリ装置１０１に常時装填しておき、取り外してオフライン状態にすることを制限することで、メタデータにアクセスするために、カートリッジが倉庫や棚に保管されたオフライン状態から、カートリッジを運搬して、ライブラリ装置１０１に装填するまでの運搬時間を削減でき、アクセス性を確保できるという効果がある。 
また別の実施例としては、カートリッジ１１５内の光ディスク１１６のうち、1枚もしくは少ない枚数の光ディスクをメタデータ専用の光ディスクとし、他をユーザデータ専用の光ディスクとし、カートリッジ内のユーザデータのメタデータをすべて同じカートリッジ内のメタデータ専用光ディスクに記録する方法が考えられる。例えば、カートリッジ１１５内に、250枚の光ディスクが格納される場合は、そのうち1枚の光ディスクをメタデータ専用光ディスクとし、残りの249枚はユーザデータ専用光ディスクとする。249枚分のユーザデータの記録位置や属性情報を、1枚のメタデータ専用光ディスクに記録することで、ユーザデータ専用光ディスクと、それらに格納されたユーザデータのメタデータを記録したメタデータ専用光ディスクを、1つのカートリッジで運搬することや保管することが可能となる。ある１つのファイルをアクセスするために、ユーザデータ専用光ディスクとメタデータ専用光ディスクが別のカートリッジに格納されている場合、メタデータ専用光ディスクが格納されたカートリッジの運搬と、ユーザデータ専用光ディスクを格納したカートリッジの運搬の、2回の運搬を行う必要があるのに比べて、運搬回数が1回で済むため、アクセス時間が短縮可能であるという効果が得られる。特に、どのカートリッジに所望のユーザデータが含まれているかを知るために、まずメタデータ専用光ディスクにアクセスし、ユーザデータが含まれるカートリッジを特定したうえで、ユーザデータ専用光ディスクが含まれるカートリッジを運搬し、ユーザデータ専用光ディスクにアクセスする、という手順となるため、直列的に2回の運搬を行う必要があり、運搬回数1回を削減できる効果は大きい。特に、大規模なデータセンタにおいて、多数のカートリッジを保管している場合や、災害対策（ディザスタリカバリ、ＤＲ）のために、カートリッジが遠隔地に保管されている場合は、1回の運搬にかかる時間が長くなるため、さらに効果が大きい。 
複数のドライブ１１４のうち、1台のドライブを、メタデータ専用光ディスクを優先的にロードするドライブとして管理することで、ドライブ１１４がすべてユーザデータ専用光ディスクをロードし、メタデータ専用光ディスクをドライブ１１４にロードできず、ドライブが空くまでメタデータにアクセス不可となる状況を回避することができるという効果がある。 
また、図１には図示していないが、メタデータ用のドライブを、カートリッジ１１５内の光ディスク１１６用のドライブとは別に、光ディスクライブラリ装置１０１に接続し、カートリッジ１１５内の光ディスク１１６とは別のメタデータ専用の光ディスクをメタデータ用のドライブにロードして記録する、という構成も考えられる。この構成により、データアクセス用のドライブ１１４やカートリッジ１１５内の光ディスク１１６に影響なく、データ用光ディスクの容量を消費することなく、メタデータを記録することができるという効果がある。
また、メタデータ用のドライブは、管理サーバ１０３もしくはバッファリングサーバ１０２に接続する構成でも、同様の効果が得られる。さらに、光ディスク搬送装置１１３を使用する必要が無いため、どのような状態であっても常にメタデータ用光ディスクがロードされた状態であり、メタデータ用光ディスクの搬送にかかる時間を削減できるという効果がある。
なお、メタデータ専用光ディスクは、250枚中1枚である必要は無く、例えば、ファイル数が多くメタデータ総量の比率がユーザデータ総量に比べて高く、1枚の光ディスクに249枚分のメタデータを格納できない場合は、250枚中2枚をメタデータ専用光ディスクとし、残りの248枚をユーザデータ専用光ディスクとすることでも、同じ効果を得ることができる。複数のドライブ１１４のうち、2台のドライブをメタデータ専用光ディスクを優先的にロードするためのドライブとして管理することで、ドライブ１１４がすべてユーザデータ専用光ディスクをロードし、メタデータ専用光ディスクをドライブ１１４にロードできず、ドライブが空くまでメタデータにアクセス不可となる状況を回避することができるという効果がある。 
また、ユーザデータを記録するための光ディスク１１６は、アーカイブ用途では書き換え不可の光ディスクである、ＢＤ−Ｒ（ＴＭ）（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ  Ｒｅｃｏｒｄａｂｌｅ）を採用する場合が多いが、その場合でも、メタデータを記録する光ディスクを、書き換え可能な光ディスク、例えば、ＢＤ−ＲＥ（ＴＭ）（Ｂｌｕ−ｒａｙ  Ｄｉｓｃ  Ｒｅｗｒｉｔａｂｌｅ）とすることで、削除シェア情報テーブル５１８や削除カートリッジ情報テーブル５１９を使用しなくても、ＢＤ−ＲＥ上のテーブルを更新することが可能となり、管理が簡素化するという効果がる。また、光ディスクを使用するため、ＢＤ−Ｒなどの書き換え不可の光ディスクと同様に、長寿命性、耐災害性、低ビットコストといった利点を兼ね備えることができるという効果がある。また、ユーザデータを光ディスクに記録後、所定の保管期間を経過したユーザデータを削除する必要が生じた場合、メタデータ用書き換え可能光ディスクを書き換えることにより、光ディスクから削除することが可能となるという効果がある。
【０２１２】
＜管理情報の段階的な格納先移動処理＞
図１９に、バッファリングサーバ内の制御用メモリ上の管理テーブルのみで管理する状態から、バッファリングサーバ内の制御用メモリ上の管理テーブルと光ディスク上の管理テーブルで管理する状態へ遷移する処理フローを示す。
【０２１３】
図１９によると、カートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３をスタブ情報ファイルとして光ディスクに書き出す条件に合致するか判断する。（Ｓ１９０１）
条件としては、実施例５に示したように、光ディスクライブラリ装置からのカートリッジ取り外しが発生すること、が考えられる。また、カートリッジの残容量が閾値以下となった場合が考えられる。また、カートリッジへの記録が開始されてから一定時間が経過することが考えられる。
【０２１４】
書き出し条件に合致した場合は、光ディスクにカートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３を、スタブ情報ファイルとして書き出す。（Ｓ１９０２）
書き出し条件に合致しない場合は、書き出し処理は発生しない。
【０２１５】
以下、実施例５に示した例は除外して説明する。
【０２１６】
ポインタテーブル５２１を更新して、カートリッジＩＤ１８１３に、カートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３を光ディスクに書き出すカートリッジのカートリッジＩＤを追記し、管理テーブルを書き出した光ディスクが含まれるカートリッジのカートリッジＩＤと、その光ディスクのディスクＩＤを、それぞれメタデータカートリッジＩＤ１８１４と、ディスクＩＤ１８１５に記録し、光ディスク上に書き込んだ開始位置とサイズを、開始位置サイズ１８１６に記録し、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録する。（Ｓ１９０３）
ポインタテーブル５２１を光ディスクに書き出す条件に合致するか判断する。（Ｓ１９０４）
条件としては、記録済みカートリッジの数が閾値以上となった場合が考えられる。また、ポインタテーブル５２１に記録した行数が閾値以上となった場合が考えられる。また、カートリッジへの記録が開始されてから一定時間が経過することが考えられる。
【０２１７】
書き出し条件に合致した場合は、光ディスクにポインタテーブル５２１を、書き出す。（Ｓ１９０５）
書き出し条件に合致しない場合は、書き出し処理は発生しない。
【０２１８】
さらに、ＨＤＤ上のポインタテーブルを管理する管理テーブル（ポインタテーブルリスト５２５）を更新する。つまり、書き出した光ディスクを含むカートリッジのカートリッジＩＤやディスクＩＤ、書き出した位置とサイズを、それぞれ、ポインタテーブルリスト５２５のメタデータカートリッジＩＤ１８１８、ディスクＩＤ１８１９、開始位置サイズ１８２０に記録する。（Ｓ１９０６）
Ｓ１９０２で書き出しが発生した場合でも、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録しているため、書き出した光ディスクにアクセスすることなく管理テーブルの読み出しが可能であるという効果がある。
【０２１９】
バッファリングサーバ内の制御用メモリの空き容量を確保するためには、ポインタ１８１７が指すカートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３を削除し、ポインタ１８１７をＮＵＬＬに設定することで、実現可能である。この場合は、書き出した光ディスクにアクセスすることで管理テーブルを読み出しが可能である。メモリの空き容量が増えたため、より多数のカートリッジをポインタテーブル５２１に登録可能となるという効果がある。
【０２２０】
図３９に、バッファリングサーバ内の制御用メモリ上の管理テーブルのみで管理する状態から、バッファリングサーバ内の制御用メモリ上の管理テーブルと光ディスク上の管理テーブルで管理する状態へ遷移する処理フローにおける異常処理フローを示す。
【０２２１】
図３９によると、カートリッジ毎のパステーブル５１２とファイル毎の記録位置テーブル５１３をスタブ情報ファイルとして光ディスクに書き出す条件に合致するか判断し、書き出し条件に合致した場合は、光ディスクに、スタブ情報ファイルを書き出すが、書き出し失敗が発生した場合は（Ｓ３９０２）、リトライ処理を行い（Ｓ３９０３）、リトライ処理の回数があらかじめ設定された上限に達すると異常処理を行う（Ｓ３９０６）。
【０２２２】
リトライ処理は、書き出しエラーが発生した論理アドレスを含むスタブ情報ファイルを記録再生不可ファイルとして登録して破棄し、記録アドレスをずらして、未記録の領域に、スタブ情報ファイルを再度記録し直す、という処理が考えられる。この場合、記録アドレスをずらしたことを、スタブ情報ファイルを指すポインタテーブル上にも反映させる。もしくは、光ディスクの擬似上書き機能（Ｌｏｇｉｃａｌ  Ｏｖｅｒ  Ｗｒｉｔｅ）を用いて、エラーが発生したアドレスに再度スタブ情報ファイルを上書き要求することで、光ディスク上の交替領域（スペアエリア）に必要な領域を確保し、その領域へのリンク情報を光ディスクのＤＭＡ（Ｄｅｆｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｅａ）に記録する処理をドライブ内で実行し、リトライで記録成功させる処理が考えられる。
【０２２３】
リトライ処理が発生した場合は、管理サーバ１０３が、エラー情報とリトライ処理に関する情報を管理画面に表示し、システム管理者に通知することが考えられる。
【０２２４】
ポインタテーブル５２１を更新し、ポインタテーブル５２１を光ディスクに書き出す条件に合致する場合は、光ディスクにポインタテーブル５２１を、書き出すが、書き出し失敗が発生した場合は、リトライ処理を行い（Ｓ３９０４）、リトライ処理の回数があらかじめ設定された上限に達すると異常処理を行う。（Ｓ３９０６）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ３９０６）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２２５】
リトライ処理を行うことで、光ディスクに正常に記録したスタブ情報ファイルを無駄にすることが無いため、スタブ情報ファイルを再度記録する処理と、ポインタテーブルを更新する処理のコストが不要になるという効果がある。また、光ディスクの容量効率も悪化させずに済むという効果がある。
【０２２６】
図２０に、光ディスク上の管理テーブルのみで管理する状態から、バッファリングサーバ内の制御用メモリ上の管理テーブルと光ディスク上の管理テーブルで管理する状態へ遷移する処理フローを示す。
【０２２７】
図２０によると、カートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３がオンラインかどうかを判断する。（Ｓ２００１）
判断方法は、ポインタテーブル５２０を参照し、当該ファイルが含まれるカートリッジのカートリッジＩＤの指すポインタが存在し、かつ、ＮＵＬＬとなっていないことを条件として、オンラインであると判断する。
【０２２８】
オンラインである場合は、処理を終了する。
【０２２９】
オンラインで無い場合は、ポインタテーブル５２１を参照し、当該ファイルが含まれるカートリッジのカートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３を光ディスクからバッファリングサーバ内の制御用メモリに読み出す。（Ｓ２００２）
読み出すファイルのファイル毎の記録位置テーブルが、メモリ上に読み出したポインタテーブル５２１の参照先に存在しなかった場合は、ファイル毎の記録位置テーブルをオンラインにできない。一方、ファイル毎の記録位置テーブルが、ポインタテーブル５２１の参照先に存在する場合は、オンラインにできる。（Ｓ２００３）
オンラインにできた場合は、ポインタテーブル５２１のポインタ１８１７に、読み出したカートリッジ毎のパステーブル５１２へのポインタを設定する。（Ｓ２００６）
オンラインにできなかった場合は、光ディスク上のポインタテーブルを指す管理テーブル（ポインタテーブルリスト５２５）を参照し、メタデータカートリッジＩＤ１８１８、ディスクＩＤ１８１９、開始位置サイズ１８２０から、ポインタテーブルを読み出す。（Ｓ２００４）
読み出したポインタテーブル５２１を参照して、当該ファイルが含まれるカートリッジのカートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３を光ディスクからバッファリングサーバ内の制御用メモリに読み出す。（Ｓ２００５）
読み出したポインタテーブル５２１のポインタ１８１７に、読み出したカートリッジ毎のパステーブル５１２へのポインタを設定する。（Ｓ２００６）
Ｓ２００６で、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録しているため、以後、書き出した光ディスクにアクセスすることなく管理テーブルの読み出しが可能となるという効果がある。
【０２３０】
バッファリングサーバ内の制御用メモリの空き容量を確保するためには、Ｓ２００２に先立って、ポインタ１８１７が指すカートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３のうちアクセス頻度が低いものを優先して削除し、ポインタ１８１７をＮＵＬＬに設定することで、実現可能である。
【０２３１】
図４０に、光ディスク上の管理テーブルのみで管理する状態から、バッファリングサーバ内の制御用メモリ上の管理テーブルと光ディスク上の管理テーブルで管理する状態へ遷移する処理フローにおける異常処理フローを示す。
【０２３２】
図４０によると、ファイル毎の記録位置テーブル５１３がオンラインで無い場合（Ｓ２００１）、光ディスクからバッファリングサーバ内の制御用メモリに読み出すために、光ディスクをドライブに搬送するが、搬送エラーが発生した場合（Ｓ４００２）、異常処理を行う。（Ｓ４００８）
搬送が成功した場合、光ディスクから読み出すが、読み出しエラーが発生した場合（Ｓ４００３）、異常処理を行う。（Ｓ４００８）
読み出し処理が成功した場合（Ｓ４００３）、以下の処理となる。
【０２３３】
ファイル毎の記録位置テーブルが、オンラインで無い場合（Ｓ２００３）、光ディスクを搬送するが、搬送エラーが発生した場合（Ｓ４００５）、異常処理を行う。（Ｓ４００８）
搬送が成功した場合、光ディスクからポインタテーブル５２１を読み出すが、読み出しエラーが発生した場合（Ｓ４００６）、異常処理を行う。（Ｓ４００８）
読み出し処理が成功した場合、読み出したポインタテーブル５２１を参照して、カートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３を光ディスクからバッファリングサーバ内の制御用メモリに読み出すが、読み出しエラーが発生した場合（Ｓ４００６）、異常処理を行う。（Ｓ４００８）
ファイル毎の記録位置テーブルが、ポインタテーブル５２１の参照先に存在する場合は、読み出し処理成功であり（Ｓ４００６）、読み出し後の管理情報を管理画面に表示しシステム管理者に通知する。（Ｓ４００７）
ファイル毎の記録位置テーブルが、ポインタテーブル５２１の参照先に存在しない場合は、読み出し処理失敗であり、ポインタテーブル５２１を参照して、次のパステーブルと記録位置テーブルを読み出すことを、読み出したいファイルの記録位置テーブルが読み出せるまで繰り返す。（Ｓ４００６）
以上のように、カートリッジのカートリッジ毎のパステーブル５１２およびファイル毎の記録位置テーブル５１３のみならず、ポインタテーブル５２１も光ディスクに書き出すことで、ストレージ装置に格納する管理情報のサイズを減らすことが可能となり、ストレージ装置の容量増によるコスト増を抑えることが可能であるという効果がある。これにより、例えば光ディスクライブラリ装置外にカートリッジを保管するという運用を行っている中で、複数の光ディスクに格納したカートリッジ内のどの光ディスクにどのファイルが格納されたかという管理情報を、記憶装置もしくは所定の光ディスクカートリッジ内の所定のディスク内に書き出し、ユーザからのファイル読み出し要求に応じて管理情報を読み出すことで、低コストかつ長寿命な光ディスクによる容量コストの低減とマイグレーションコストの低減を実現できる。さらに、アクセス頻度の高いファイルに対しては、ストレージ装置上に管理情報を残すことで、カートリッジ搬送やディスク搬送に伴う待ち時間発生を抑制し、アクセス性や検索性を確保できるという効果がある。さらに、光ディスクに格納した記録位置テーブルの格納位置を取得するために、最大でも、ストレージ装置上のポインタテーブルリスト５２５と、光ディスクに書き出したポインタテーブル５２１を搬送して参照すればよいため、光ディスク搬送の回数を最大１回に抑制でき、本実施例の管理を行わない場合に想定される多数回の光ディスク搬送による待ち時間が発生せず、多数ファイルを対象にした場合でもアクセス性や検索性を確保できるという効果がある。
【０２３４】
光ディスクにメタデータを格納することで、水害時などにバッファリングサーバ１０２やストレージ装置１０４が故障しアクセス不可になった場合のディザスタリカバリ（ＤＲ）における復旧処理で、記録位置テーブル５１３や、ポインタテーブル５２１を、光ディスクから復旧することが可能となり、ユーザデータへのアクセス手段が失われてしまう状況を回避できるという効果がある。
【０２３５】
また、従来の技術を用いて、ユーザデータの記録位置を、ストレージ装置１０４上ではＸＦＳ形式のファイルシステムで管理し、光ディスク上ではＵＤＦ形式のファイルシステムで管理する場合、ＤＲ時にＵＤＦ形式からＸＦＳ形式に変換する必要が生じ、その処理に時間がかかるという課題があるが、本発明により、光ディスク上の記録位置テーブル５１３や、ポインタテーブル５２１のデータ構造が、ストレージ装置１０４上の記録位置テーブル５１３や、ポインタテーブル５２１のデータ構造と同じにできるため、データ構造の変換処理が発生せず、高速なＤＲが可能であるという効果がある。
【０２３６】
記録位置テーブル５１３や、ポインタテーブル５２１を光ディスクに記録する場合を例に説明したが、記録位置テーブル５１３や、ポインタテーブル５２１を光ディスクに記録するタイミングと同じタイミングで、他の管理情報のスナップショットを同じ光ディスクに記録しておくことで、ＤＲ時にすべての管理情報を光ディスクから復旧可能となり、データ用光ディスクに分散して記録された管理情報をすべて読み出して管理情報の再構築を行う処理が不要となり、ＤＲが高速になるという効果がある。ここで、管理テーブルとは、図５に記載の管理情報である。
【０２３７】
＜ファイルの識別のためにハッシュを付与する処理＞
図７に示すカートリッジ毎のパステーブル５１２の代わりに、図２１に示すハッシュテーブル５２２と、図２２に示す同一ハッシュのパステーブル５１２と、図２３に示す衝突テーブル５２３を用いて、ファイルの記録位置を管理する方法を説明する。
【０２３８】
図２１は、ハッシュテーブル５２２であり、同一ハッシュのパステーブルへのポインタ２１１２からなる。なお、パスハッシュ２１１１は、説明のために示したインデックスであり、ハッシュテーブル５２２実体には含まれない。
【０２３９】
パスからハッシュ演算を行い、４バイトのハッシュ値を生成し、生成されたハッシュ値をハッシュテーブル５２２のインデックスとして、パスハッシュ２１１１とハッシュ値が一致する行の同一ハッシュのパステーブルへのポインタ２１１２に、同一ハッシュのパステーブル５１２へのポインタを登録する。
【０２４０】
図２１では、２１２１の行が０ｘ００００００００のハッシュ値が生成された場合に使用するフィールドであり、２１２２の行が０ｘ０００００００１のハッシュ値が生成された場合に使用するフィールドである。２１２１の行から２１２３の行までは、ＮＵＬＬであるため、未登録の状態である。２１２４の行には、ポインタが登録されており、パスからハッシュ値として０ｘ８７３１ｂ４９１が生成され、登録されたことを意味する。同様に、２１２７の行にも登録済みであり、２１２５の行から２１２６の行は未登録、２１２８の行以降も未登録、の状態である。
【０２４１】
パスから演算したハッシュ値が０ｘ８７３１ｂ４９１であれば、２１２４の行であることが分かり、ポインタ０ｘ００９００２３０が指す領域を参照すればパステーブルが取得できる。このように、ハッシュテーブルを用いることで、Ｓ１３０４で説明したようにパステーブルに登録されたすべてのパスを比較してパスの重複を確認することなく、所望のテーブルへのポインタを取得でき、処理が高速であるという効果がある。
【０２４２】
図２１では、４バイトのハッシュをインデックスに用いる例を示したが、ハッシュのサイズはこれに限るものではなく、ファイルの総数と図２２に示す同一ハッシュのパステーブルを探索する処理の性能により、増減することが可能である。
例えば、１バイトのハッシュをインデックスに用いた場合は、ハッシュテーブルのサイズを、（２の３２乗行）×（ポインタ２１１２のサイズ４バイト）、すなわち１７，１７９，８６９，１８４バイトから、（２の８乗行）×（ポインタ２１１２のサイズ４バイト）、すなわち２，０４８バイトに削減することが可能である。逆に、例えば、８バイトのハッシュをインデックスに用いた場合は、１８，４４６，７４４，０７３，７０９,５５１，６１６行のハッシュテーブルになるため、ハッシュの衝突が発生する確率を低減でき、同一ハッシュのパステーブル５１２を探索する処理を削減できる。
【０２４３】
図２２に同一ハッシュのパステーブル５１２の構成を示す。
【０２４４】
同一ハッシュのパステーブルは、パスから演算されたハッシュ値が同じであるものを登録するテーブルであり、ハッシュ値ごとにひとつのテーブルを作成する。よって、４バイトのハッシュ値であれば、最大で２の３２乗個のテーブルが作成される。
【０２４５】
パス数２２１１は、パスから生成されたハッシュ値が同じ値であるファイルとディレクトリのパスの総数を示す。
【０２４６】
リザーブ２２１２は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【０２４７】
ファイル＃Ｎ記録位置テーブルの格納場所２２１３は、パステーブル５１２に含まれるＮ番目のファイルもしくはディレクトリのパスに関する情報であり、後述するパス識別ハッシュ、ディレクトリ／ファイル識別フラグ、記録位置テーブルポインタ、衝突インデックス、リザーブから構成される。
【０２４８】
パス識別ハッシュ２２１８は、ファイル＃Ｎのパスから生成した第２のハッシュ値を格納するフィールドである。第２のハッシュ値は、ハッシュテーブル５２２のインデックスを識別するために生成したハッシュ値とは異なり、例えば、別のハッシュ関数で生成したハッシュ値である。
【０２４９】
ディレクトリ／ファイル識別フラグ２２１７は、ファイル＃Ｎがファイルであれば０、ディレクトリであれば１を格納するフィールドである。
【０２５０】
記録位置テーブルポインタ２２１６は、ファイル毎の記録位置テーブル５１３内の先頭からのオフセット値を格納するフィールドである。
【０２５１】
衝突インデックス２２１５は、同一ハッシュのパステーブル５１２に登録済みのパス識別ハッシュの値と、パス識別ハッシュ２２１８が、同じ値であった場合に、０以外かつ１以外の値を、後述する衝突テーブル５２３のインデックスとして登録するためのフィールドである。衝突が発生していない場合は、０が設定される。衝突が発生しているが、後述する衝突テーブルにフルパスが登録されていない場合は、１が設定される。
【０２５２】
記録位置数２２１９は、記録位置テーブルポインタ２２１６が指すファイル毎の記録位置テーブルの数を示している。
【０２５３】
リザーブ２２１４は、固定値を格納してあり、現在のバージョンでは機能しないが、将来のバージョンでの機能拡張時に使用するための予約フィールドである。
【０２５４】
図２３は、衝突テーブル５２３であり、フルパス２３１２からなる。なお、衝突インデックス２３１１は、説明のために示したインデックスであり、衝突テーブル５２３実体には含まれない。
【０２５５】
衝突インデックス２３１１は、０から６５５３５までのインデックスであり、パス識別ハッシュ２２１８に衝突が発生したら２、３、・・・の順番に割り当てて使用する。なお、衝突インデックス０、すなわち２３２１の行は、衝突が発生していない場合のインデックス値０と同じであるため、未使用である。また、衝突インデックス１、すなわち２３２２の行は、衝突が発生しているが、衝突テーブルにフルパスが登録されていない場合のインデックス値１と同じであるため、未使用である。つまり、衝突インデックス０と１は、特殊な意味を持つため、それ以外の用途には使用禁止である。
【０２５６】
なお、衝突インデックスの最大値を６５５３５とした例で説明しているが、衝突の発生確率に応じて、最大値を変更してよい。
【０２５７】
フルパス２３１２は、衝突したパスをフルパスの文字列として記録するためのフィールドである。最大１０２４バイトを想定する。
【０２５８】
最初に衝突が発生した場合は、２３２３の行の衝突インデックス２を使用し、フルパス２３１２に衝突が発生したパスをフルパスで記録する。
【０２５９】
図２３では、フルパス"/archive/140101"をハッシュ演算したところ、既に登録済みの別のパスのハッシュ値と同じハッシュ値が生成されたため、衝突が発生したことを示している。
【０２６０】
衝突テーブルに登録されたフルパスは衝突が発生したことが確認された時点で演算したパスのみを登録するため、衝突したもう一方のハッシュ値を生成するための元になったフルパスは、登録しない。
【０２６１】
同一ハッシュのパステーブル５１２に登録するために、パス識別ハッシュを演算したら、当該パステーブル５１２に登録済みのすべてのファイルのパス識別ハッシュと比較し、衝突発生していないかを確認する。もし衝突が発生していれば、衝突テーブル５２３を参照して、未使用のインデックスのうち最小値のインデックスを、衝突インデックス２２１５に記録する。同時に、衝突テーブル５２３のインデックスにも、衝突が発生したパスのフルパスを記録する。衝突した相手方のファイルの衝突インデックス２２１５が０であれば、１を記録する。このとき、衝突テーブル５２３のインデックスにはフルパスを登録しない。
【０２６２】
探索したいファイルのフルパスから演算したパス識別ハッシュを用いて、同一ハッシュのパステーブル５１２を、パス識別ハッシュ２２１８と比較しながら探索する場合、パス識別ハッシュが一致し、かつ、衝突インデックス２２１５が０の場合は、その時点で一意に決まるため、探索終了である。パス識別ハッシュが一致し、かつ、衝突インデックス２２１５が０でない場合は、衝突テーブル５２３の衝突インデックス２３１１の、該当するインデックス値のフルパスを参照し、探索したいファイルのフルパスと一致するかどうか確認する。一致すれば、それが探索したいファイルであり、探索終了である。一致しない場合は、同一ハッシュのパステーブル５１２をパス識別ハッシュを用いて引き続き探索し、パス識別ハッシュが一致し、かつ、衝突インデックス２２１５が０でない場合を見つけ、衝突テーブルでフルパスが一致するか確認する。これを同一ハッシュのパステーブル５１２まで繰り返し、一致するエントリがなければ、探索したいファイルは未登録であると分かるため、書き込み時の探索であれば、同一ハッシュのパステーブル５１２に新規に格納場所を追加して登録して記録すればよく、読み出し時の探索であれば、探索したいファイルは存在しないという結果になる。
【０２６３】
図２４は、ハッシュテーブルを用いたファイル書き込み時の処理フローである。
【０２６４】
図２４によると、あるパスで指定されるファイルを書き込む場合、指定されたパスから、ハッシュ演算を２種類行う。ひとつはハッシュテーブル５２２のパスハッシュ２１１１のインデックスとして使用するハッシュ値であり、もうひとつは同一ハッシュのパステーブル５１２のパス識別ハッシュ２２１８として使用するハッシュ値である。それぞれハッシュ関数ａ、ハッシュ関数ｂを用いて生成したとする。（Ｓ２４０１）
ハッシュ関数ａで生成したハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、新規に同一ハッシュのパステーブル５１２を生成し、そのパステーブル５１２へのポインタをポインタ２１１２に登録する。ＮＵＬＬでなければ、ポインタが指す同一ハッシュのパステーブル５１２を参照する。（Ｓ２４０２）
新規に同一ハッシュのパステーブル５１２を生成した場合は、衝突が発生しているかどうかは考慮しなくて良い。既に生成済みの同一ハッシュのパステーブル５１２を参照する場合は、当該パステーブルに登録済みの全ファイル（ディレクトリ含む）のパス識別ハッシュ２２１８と、ハッシュ関数ｂで生成したハッシュ値を比較し、衝突が発生していないか確認する。（Ｓ２４０３）
衝突が発生していれば、衝突テーブル５２３を参照し、未使用の最小インデックスを使用して、フルパスを登録する。（Ｓ２４０４）
ファイル毎の記録位置テーブル５１３に新規に記録位置を確保し、ファイル名（もしくはディレクトリ名）、記録時刻、サイズ、属性を設定する。さらに、ファイル数８２１（もしくはディレクトリ数８１１）をインクリメントする。ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを取得しておく。（Ｓ２４０５）
同一ハッシュのパステーブル５１２に新規に格納場所を確保し、同じインデックス値を衝突インデックス２２１５に記録する。また、パス識別ハッシュにハッシュ関数ｂで生成したハッシュ値を記録する。ディレクトリであればディレクトリ／ファイル識別フラグ２２１７を１に、ファイルであれば０に設定する。記録位置テーブルポインタ２２１６に、ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを設定する。（Ｓ２４０６）
図４１は、ハッシュテーブルを用いたファイル書き込み時の処理フローにおける異常処理フローである。
【０２６５】
図４１によると、パス識別ハッシュ２２１８と、生成したハッシュ値を比較し、衝突が発生していないか確認する。（Ｓ４１０１）
衝突が発生していれば、衝突テーブル５２３を参照し、未使用の最小インデックスを使用できるか確認する。（Ｓ４１０２）
登録数が上限に達し、未使用のインデックスがなければ、異常処理を行う。（Ｓ４１０６）
Ｓ４１０１で衝突が発生していない場合と、Ｓ４１０２で登録が成功した場合は、ファイル毎の記録位置テーブル５１３に登録できるか確認する。（Ｓ４１０３）
登録数が上限に達し、登録に失敗すれば、異常処理を行う。（Ｓ４１０６）
さらに、ファイル数８２１（もしくはディレクトリ数８１１）をインクリメントする際に上限を越えラップアラウンドする場合は、異常処理を行う。（Ｓ４１０６）
Ｓ４１０３で登録に成功した場合は、同一ハッシュのパステーブル５１２に登録できるか確認する。（Ｓ４１０４）
登録が失敗すれば、異常処理を行う。（Ｓ４１０６）
以上が、ハッシュテーブルを用いたファイル書き込み時の処理フローの説明である。
【０２６６】
図２５は、ハッシュテーブルを用いたファイル読み出し時の処理フローである。
【０２６７】
図２５によると、あるパスで指定されるファイルを読み出す場合、指定されたパスから、ハッシュ演算を２種類行う。ひとつはハッシュテーブル５２２のパスハッシュ２１１１のインデックスとして使用するハッシュ値であり、もうひとつは同一ハッシュのパステーブル５１２のパス識別ハッシュ２２１８を探索するために使用するハッシュ値である。図２４で説明した場合に合わせて、それぞれハッシュ関数ａ、ハッシュ関数ｂを用いて生成する必要がある。（Ｓ２５０１）
ハッシュ関数ａで生成したハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、指定されたファイルは存在しない。ＮＵＬＬでなければ、ポインタが指す同一ハッシュのパステーブル５１２を参照する。（Ｓ２５０２）
当該パステーブル５１２に登録済みの全ファイル（ディレクトリ含む）のパス識別ハッシュ２２１８と、ハッシュ関数ｂで生成したハッシュ値を比較し、衝突が発生していないか確認する。（Ｓ２５０３）
衝突が発生していれば、衝突インデックス２２１５のインデックス値を取得し、１であればスキップして次の衝突を探す。それ以外の値であれば、衝突テーブル５２３の当該インデックスの行を参照し、フルパス２３１２を取得する。当該フルパスと指定されたファイルのフルパスを比較し、一致するか確認する。一致すれば、同一ハッシュのパステーブル５１２の当該インデックスを持つ格納場所の記録位置テーブルポインタ２２１６を取得する。一致しなければ、同一パスのハッシュテーブル５１２に戻って探索を継続し、パス識別ハッシュ２２１８と、ハッシュ関数ｂで生成したハッシュ値を比較し、次に衝突が発生している箇所を特定し、衝突テーブル５２３でフルパスを比較することを繰り返す。もし一致するものがなければ、衝突インデックスが１である記録位置テーブルへのポインタを取得する。（Ｓ２５０５）
取得したポインタをたどって記録位置を取得し、ファイルを読み出す。（Ｓ２５０６）
ハッシュ関数ａ、ハッシュ関数ｂを用いて、同じパスから、それぞれ別のハッシュ値を生成する例を説明したが、これに限定されるものではなく、例えば、１つのハッシュ関数から生成したハッシュ値を上位ビットと下位ビットに分割し、それぞれをハッシュ値として用いることも可能である。例えば、パスからハッシュ関数ａを用いて、64バイトのハッシュ値を生成した場合、ハッシュ値の32バイト目から63バイト目のビット列を32バイトの値とみなし、第1のハッシュ値とし、0バイト目から31バイト目のビット列を32バイトの値とみなし、第2のハッシュ値とすることも考えられる。これにより、複数のハッシュ関数を用意する必要がなく、処理がシンプルとなり、また長期保管時に保存すべきハッシュ関数も少なくて済む。
【０２６８】
以上が、ハッシュテーブルを用いたファイル読み出し時の処理フローの説明である。
【０２６９】
図４２は、ハッシュテーブルを用いたファイル読み出し時の処理フローにおける異常処理フローである。
【０２７０】
図４２によると、ハッシュ関数ａで生成したハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、指定されたファイルは存在せず、パステーブルへのポインタは取得できない（Ｓ４２０１）ため、異常処理を行う。（Ｓ４２０６）
ＮＵＬＬでなければ、当該パステーブル５１２に登録済みの全ファイル（ディレクトリ含む）のパス識別ハッシュ２２１８と、ハッシュ関数ｂで生成したハッシュ値を比較し、衝突が発生していないか確認する。（Ｓ４２０２）
衝突が発生していれば、衝突テーブル５２３の当該インデックスの行を参照し、フルパス２３１２を取得する。当該フルパスと指定されたファイルのフルパスを比較し、一致するか確認する。（Ｓ４２０３）
一致しなければ、異常処理を行う。（Ｓ４２０６）
一致すれば、同一ハッシュのパステーブル５１２の当該インデックスを持つ格納場所の記録位置テーブルポインタ２２１６を取得し（Ｓ４２０４）、取得したポインタをたどって記録位置を取得し、ファイルを読み出し、結果をシステム管理者に通知する。（Ｓ４２０５）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ４２０６）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２７１】
このように、ハッシュテーブルとパステーブルと衝突テーブルを組み合わせて、ファイルパスの識別が可能となり、ハッシュテーブルによる高速な処理を活かした記録位置の管理が可能となるという効果がある。
【０２７２】
一般的に、フルパスは、最大１０２４バイトのデータ量になるため、衝突テーブル５２３のフルパス２３１２には、１０２４バイトのフルパスを格納できるようなサイズのフィールドを用意しておく必要があり、パス識別ハッシュのビット数が少ない場合は、衝突確率も上がるため、たくさんのデータ量を消費する課題がある。
【０２７３】
これに対して、フルパスに対して、第３のハッシュ関数によるハッシュ演算を行い、フルパスの代わりに格納することが考えられる。これにより、フルパス２３１２のサイズを１０２４バイトよりも削減することができるという効果がある。例えば、ＵＵＩＤと同じ程度のサイズである４０バイトの長さのハッシュ値を生成しておけば、衝突が発生しないとみなせるほどの低い衝突確率におさえることができるため、十分である。
【０２７４】
＜ファイルの識別のためにタイムスタンプを付与する処理＞
図２２に示す同一ハッシュのパステーブル５１２の代わりに、図２６に示す同一ハッシュのパステーブル５１２を用いて、ファイル識別のためにタイムスタンプを活用する方法を説明する。
【０２７５】
図２６に同一ハッシュのパステーブル５１２の構成を示す。図２２に示す同一ハッシュのパステーブル５１２と同じ部分は説明を割愛し、相違点に絞って説明する。
【０２７６】
ドライブＩＤ＋タイムスタンプ２６１７は、光ディスクライブラリ装置１０１に搭載されるドライブ１１４の識別のために付与されているユニークなシリアルナンバーと、ファイルを光ディスクに記録したタイムスタンプを組み合わせたＩＤである。例えば、上位８バイトをドライブ１１４のシリアルナンバー、下位８バイトをタイムスタンプとし、計１６バイトのＩＤとすることが考えられる。
【０２７７】
図２７は、ＩＤにタイムスタンプを用いたファイル書き込み時の処理フローである。
【０２７８】
図２７によると、あるパスで指定されるファイルを書き込む場合、指定されたパスから、ハッシュ演算を行う。これはハッシュテーブル５２２のパスハッシュ２１１１のインデックスとして使用するハッシュ値である。（Ｓ２７０１）
生成したハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、新規に同一ハッシュのパステーブル５１２を生成し、そのパステーブル５１２へのポインタをポインタ２１１２に登録する。ＮＵＬＬでなければ、ポインタが指す同一ハッシュのパステーブル５１２を参照する。（Ｓ２７０２）
ファイルを記録し、記録したときのタイムスタンプを取得する。また、記録したドライブのシリアルナンバーを取得する。これらを組み合わせてＩＤとし、同一ハッシュのパステーブル５１２に新規に記録位置を確保し、ドライブＩＤ＋タイムスタンプ２６１７に設定する。（Ｓ２７０３）
ファイル毎の記録位置テーブル５１３に新規に記録位置を確保し、ファイル名（もしくはディレクトリ名）、記録時刻、サイズ、属性を設定する。さらに、ファイル数８２１（もしくはディレクトリ数８１１）をインクリメントする。ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを取得しておく。（Ｓ２７０４）
同一ハッシュのパステーブル５１２に新規に格納場所を確保し、ディレクトリであればディレクトリ／ファイル識別フラグ２６１６を１に、ファイルであれば０に設定する。記録位置テーブルポインタ２６１５に、ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを設定する。正常に完了した場合は、ユーザにＩＤを返す。このＩＤはドライブＩＤ＋タイムスタンプ２６１７に設定した値であり、読み出し時に必要となる。（Ｓ２７０５）
図４３は、ＩＤにタイムスタンプを用いたファイル書き込み時の処理フローにおける、異常処理フローである。
【０２７９】
図４３によると、あるパスで指定されるファイルを書き込む場合、指定されたパスから、ハッシュ演算を行い、生成したハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、新規に同一ハッシュのパステーブル５１２を生成し、そのパステーブル５１２へのポインタをポインタ２１１２に登録するが（Ｓ４３０１）、登録に失敗した場合は、異常処理を行う。（Ｓ４３０５）
ＮＵＬＬでなければ、ポインタが指す同一ハッシュのパステーブル５１２を参照し、そのパステーブル５１２へのポインタをポインタ２１１２に登録するが（Ｓ４３０１）、登録に失敗した場合は、異常処理を行う。（Ｓ４３０５）
登録が成功した場合、ファイルを記録したときのタイムスタンプと、記録したドライブのシリアルナンバーを組み合わせてＩＤとし、ドライブＩＤ＋タイムスタンプ２６１７に設定し、ファイル毎の記録位置テーブル５１３に新規に記録位置を確保し、ファイル名（もしくはディレクトリ名）、記録時刻、サイズ、属性を設定するが、失敗した場合は（Ｓ４３０２）、異常処理を行う。（Ｓ４３０５）
さらに、ファイル数８２１（もしくはディレクトリ数８１１）をインクリメントするが、ラップアラウンドした場合は、異常処理を行う。（Ｓ４３０５）
ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを取得し、同一ハッシュのパステーブル５１２に新規に格納場所を確保し、ディレクトリ／ファイル識別フラグ２６１６を設定し、記録位置テーブルポインタ２６１５に、ファイル毎の記録位置テーブル５１３に新規に確保した記録位置へのポインタを設定するが、失敗した場合は、異常処理を行う。（Ｓ４３０５）
正常に完了した場合は、システム管理者に通知する（Ｓ４３０４）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ４３０５）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２８０】
以上が、ＩＤにタイムスタンプを用いたファイル書き込み時の処理フローの説明である。
【０２８１】
図２８は、ＩＤにタイムスタンプを用いたファイル読み出し時の処理フローである。
【０２８２】
図２８によると、あるパスで指定されるファイルを読み出す場合、指定されたパスから、ハッシュ演算を行う。これはハッシュテーブル５２２のパスハッシュ２１１１のインデックスとして使用するハッシュ値である。（Ｓ２８０１）
このハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、そのポインタ２１１２がＮＵＬＬであれば、指定されたファイルは存在しない。ＮＵＬＬでなければ、ポインタが指す同一ハッシュのパステーブル５１２を参照する。（Ｓ２８０２）
パスとともに指定されたＩＤと、同一ハッシュのパステーブル５１２のドライブＩＤ＋タイムスタンプ２６１７を比較し、一致するものを特定する。（Ｓ２８０３）
一致しなければ、指定されたファイルは存在しない。一致すれば、記録位置テーブルポインタ２６１５を取得する。（Ｓ２８０４）
取得したポインタをたどって記録位置を取得し、ファイルを読み出す。（Ｓ２８０５）
図４４は、ＩＤにタイムスタンプを用いたファイル読み出し時の処理フローにおける、異常処理フローである。
【０２８３】
図４４によると、あるパスで指定されるファイルを読み出す場合、指定されたパスから、ハッシュ演算を行い、そのポインタ２１１２がＮＵＬＬであれば（Ｓ４４００）、指定されたファイルは存在しないので、異常処理を行う。（Ｓ４４０４）
ＮＵＬＬでない場合、このハッシュ値を用いて、パスハッシュ２１１１のインデックスを特定し、ポインタが指す同一ハッシュのパステーブル５１２を参照し、パスとともに指定されたＩＤと、同一ハッシュのパステーブル５１２のドライブＩＤ＋タイムスタンプ２６１７を比較し、一致するものを特定するが、一致しなければ（Ｓ４４０１）、指定されたファイルは存在せず、異常処理を行う。（Ｓ４４０４）
一致すれば（Ｓ４４０１）、記録位置テーブルポインタ２６１５を取得し、取得したポインタをたどって記録位置を取得する（Ｓ４４０２）が、失敗すれば、異常処理を行う。（Ｓ４４０４）
正常に完了した場合は、システム管理者に通知する（Ｓ４４０３）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ４４０４）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２８４】
以上が、ＩＤにタイムスタンプを用いたファイル読み出し時の処理フローの説明である。
【０２８５】
このように、ＩＤにタイムスタンプを用いることで、多数のファイル数に対するハッシュ演算を多数回にわたって実行する処理を用いることなく、ファイルの識別が可能になるという効果がある。
【０２８６】
＜所有者ＩＤにタイムスタンプを組み合わせ、カートリッジ単位で記録時刻範囲を絞って探索する処理＞
図３１に示す構造の所有者ＩＤを用いて、カートリッジ識別のためにタイムスタンプを活用する方法を説明する。
【０２８７】
図３１はシェア情報テーブル５１５の所有者ＩＤ１０１１や、カートリッジ情報テーブル５１６の所有者ＩＤ１１１２に用いられる、所有者ＩＤの構造を示した図である。
【０２８８】
２４〜３１バイト（３１１１）は、３２バイトの長さを持つ所有者ＩＤの上位４バイトに相当する部分であり、バッファリングサーバ１０２のシリアルナンバーなどのユニークなＩＤである。
【０２８９】
１６〜２３バイト（３１１２）は、所有者ＩＤの１６〜２３バイトに相当する部分であり、ＩＤが生成されたときの年月日をＢＣＤで示したものである。
【０２９０】
８〜１５バイト（３１１３）は、所有者ＩＤの８〜１５バイトに相当する部分であり、ＩＤが生成されたときの時刻（時分秒）をＢＣＤで示したものである。なお、時分秒までの分解能で説明したが、さらにミリ秒やマイクロ秒などの小さい分解能まで保持させることも、ビットアサインを変更することで可能である。
【０２９１】
０〜７バイト（３１１４）は、所有者ＩＤの下位４バイトに相当する部分であり、乱数計算により生成された値である。
【０２９２】
図２９は、図３１に示す所有者ＩＤを用いて、ファイル書き込みを行う処理フローである。
【０２９３】
図２９によると、バッファリングサーバ１０２のシリアルナンバーと、タイムスタンプを取得し、所有者ＩＤを生成する。（Ｓ２９０１）
生成した所有者ＩＤをパスの一部に用いて、ファイルを記録する。（Ｓ２９０２）
実施例７で示したような書き込み処理を行う。（Ｓ２９０３）
ファイルを記録したカートリッジの、カートリッジ毎の共通情報５１１の最新記録時刻６１３を更新する。（Ｓ２９０４）
図４５は、図３１に示す所有者ＩＤを用いて、ファイル書き込みを行う処理フローにおける、異常処理フローである。
【０２９４】
図４５によると、バッファリングサーバ１０２のシリアルナンバーを取得する（Ｓ４５０１）が、失敗すれば異常処理を行う。（Ｓ４５０５）
タイムスタンプを取得する（Ｓ４５０２）が、失敗すれば異常処理を行う。（Ｓ４５０６）
シリアルナンバーとタイムスタンプから所有者ＩＤを生成するが、生成した所有者ＩＤが重複していれば（Ｓ４５０３）、異常処理を行う。（Ｓ４５０５）
生成した所有者ＩＤをパスの一部に用いて、ファイルを記録する（Ｓ４５０４）が、失敗すれば異常処理を行う。（Ｓ４５０６）
実施例７で示したような書き込み処理を行う。（Ｓ２９０３）
正常に完了した場合は、システム管理者に通知する（Ｓ４５０５）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ４５０６）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０２９５】
以上が、タイムスタンプから生成した所有者ＩＤを用いてファイル書き込みを行う処理フローの説明である。
【０２９６】
図３０は、図３１に示す所有者ＩＤを用いて、ファイル読み出しを行う処理フローである。
【０２９７】
図３０によると、パスから所有者ＩＤを抽出する。（Ｓ３００１）
所有者ＩＤから、タイムスタンプ（年月日、時分秒）を抽出する。（Ｓ３００２）
ポインタテーブル５２１より、カートリッジ毎の共通情報５１１を参照し、共通情報５１１に記録された最古記録時刻６１２と最新記録時刻６１３より、カートリッジ毎の記録時間範囲を取得でき、記録時間範囲にＳ３００２で得られたタイムスタンプが含まれるカートリッジのカートリッジＩＤを取得できる。（Ｓ３００３）
取得したカートリッジＩＤのカートリッジの管理情報を保持したメタデータカートリッジと光ディスクは、ポインタテーブル５２１から分かるので、当該メタデータカートリッジから当該光ディスクを装填し、スタブ情報ファイルを読み出すことで、実施例７で示したような読み出し処理を行う。（Ｓ３００４）
以上が、タイムスタンプから生成した所有者ＩＤを用いて、ファイル読み出しを行う処理フローの説明である。
【０２９８】
図４６は、図３１に示す所有者ＩＤを用いて、ファイル読み出しを行う処理フローにおける、異常処理フローである。
【０２９９】
図４６によると、パスから所有者ＩＤを抽出する（Ｓ４６０１）が、失敗すれば異常処理を行う。（Ｓ４６０５）
所有者ＩＤから、タイムスタンプ（年月日、時分秒）を抽出する（Ｓ４６０２）が、失敗すれば異常処理を行う。（Ｓ４６０５）
ポインタテーブル５２１より、カートリッジ毎の共通情報５１１を参照し、共通情報５１１に記録された最古記録時刻６１２と最新記録時刻６１３より、カートリッジ毎の記録時間範囲を取得する（Ｓ４６０３）が、失敗すれば異常処理を行う。（Ｓ４６０５）
記録時間範囲にＳ３００２で得られたタイムスタンプが含まれるカートリッジのカートリッジＩＤを取得できれば（Ｓ４６０３）、取得したカートリッジＩＤのカートリッジの管理情報を保持したメタデータカートリッジと光ディスクは、ポインタテーブル５２１から分かるので、当該メタデータカートリッジから当該光ディスクを装填し、スタブ情報ファイルを読み出すことで、実施例７で示したような読み出し処理を行う。（Ｓ３００４）
正常に完了した場合は、システム管理者に通知する（Ｓ４６０４）
異常処理としては、管理サーバ１０３が、エラー情報を管理画面に表示し、システム管理者に通知することが考えられる。（Ｓ４６０５）
異常処理を行うことで、システム管理者は速やかに異常を認識できるため、その後の保守業務を依頼するまでの時間を短くすることができ、中断によるビジネス継続性への影響を最小化できるという効果がある。
【０３００】
以上が、タイムスタンプから生成した所有者ＩＤを用いて、ファイル読み出しを行う処理フローの説明である。
【０３０１】
実施例８のようにパスごとの記録時刻情報（タイムスタンプが含まれるＩＤ）をユーザ側で管理する必要がなく、パスのみで記録位置を識別可能であるという効果がある。
【０３０２】
＜シェア情報テーブル更新処理と取得処理＞
タイムスタンプ情報を埋め込んだ所有者ＩＤを用いて、カートリッジ識別のためにタイムスタンプを活用する方法を説明する。
【０３０３】
図４９は、図３１に示す所有者ＩＤと、図４８に示すシェア情報テーブルの更新処理を用いて、ファイル書き込みを行う処理フローである。
【０３０４】
図４９によると、バッファリングサーバ１０２のシリアルナンバーと、タイムスタンプを取得し、図３１に示す所有者ＩＤを生成する。（Ｓ４９０１）
生成した所有者ＩＤをパスの一部に用いて、ファイルを記録する。パスは、例えば、／ＯｗｎｅｒＩＤ／ＤｉｒｅｃｔｏｒｙＮａｍｅ／ＦｉｌｅＮａｍｅという構成である。ここで、「ＯｗｎｅｒＩＤ」はシェア名の文字列であり、シェア情報テーブル５１５から、シェア１０１２から所有者ＩＤ１０１１を取得できる。「ＤｉｒｅｃｔｏｒｙＮａｍｅ」は、Ｆｉｌｅを格納するディレクトリの名前の文字列、「ＦｉｌｅＮａｍｅ」は記録するファイルの名前の文字列、を示す。また、「／」は区切り文字を示す文字である。「ＤｉｒｅｃｔｏｒｙＮａｍｅ」はこの例では１つのみを記載したが、階層構造をとっても良い。（Ｓ４９０２）
次に、実施例７で示したような書き込み処理を行う。（Ｓ４９０３）
次に、ファイルを記録したカートリッジの、カートリッジ毎の共通情報５１１の最新記録時刻６１３を更新する。（Ｓ４９０４）
そして、図４７に示すような、シェア情報テーブルの更新処理を行う。（Ｓ４９０５）
図４７は、シェア情報テーブルの更新処理を示した処理フローである。
【０３０５】
図４７によると、シェア情報テーブル５１５をシェア情報ファイルとして光ディスクに書き出す条件に合致するか判断する。（Ｓ４７０１）
条件としては、シェア情報テーブルの最終更新時刻から指定期間だけ時間がたった場合や、シェア情報テーブルのサイズがＢＤ記録単位サイズ(６４ｋＢ)の倍数に達した場合や、ストレージ装置のＨＤＤのリプレースを実施する場合が考えられる。
【０３０６】
書き出し条件に合致した場合は、光ディスクにシェア情報テーブル５１５を、シェア情報ファイルとして書き出す。（Ｓ４７０２）
書き出し条件に合致しない場合は、書き出し処理は発生しない。
【０３０７】
ポインタテーブル５２１を更新して、カートリッジＩＤ１８１３に、シェア情報テーブル５１５を光ディスクに書き出すカートリッジのカートリッジＩＤを追記し、管理テーブルを書き出した光ディスクが含まれるカートリッジのカートリッジＩＤと、その光ディスクのディスクＩＤを、それぞれメタデータカートリッジＩＤ１８１４と、ディスクＩＤ１８１５に記録し、光ディスク上に書き込んだ開始位置とサイズを、開始位置サイズ１８１６に記録し、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録する。また、当該ポインタテーブル５２１のカートリッジのシェアの所有者ＩＤのうち、最小の所有者ＩＤと最大の所有者ＩＤを保持しておく。（Ｓ４７０３）
次に、ポインタテーブル５２１を光ディスクに書き出す条件に合致するか判断する。（Ｓ４７０４）
条件としては、シェア情報テーブルの最終更新時刻から指定期間だけ時間がたった場合が考えられる。また、ポインタテーブル５２１に記録した行数が閾値以上となった場合が考えられる。
【０３０８】
書き出し条件に合致した場合は、光ディスクにポインタテーブル５２１を、書き出す。さらに、ＨＤＤ上のポインタテーブルを管理する管理テーブル（ポインタテーブルリスト５２５）を更新する。つまり、書き出した光ディスクを含むカートリッジのカートリッジＩＤやディスクＩＤ、書き出した位置とサイズ、保持しておいた最小所有者ＩＤと最大所有者ＩＤを、それぞれ、ポインタテーブルリスト５２５のメタデータカートリッジＩＤ１８１８、ディスクＩＤ１８１９、開始位置サイズ１８２０、最小ＯＩＤ最大ＯＩＤ１８２１に記録する。（Ｓ４７０５）
書き出し条件に合致しない場合は、書き出し処理は発生しない。
【０３０９】
Ｓ４７０２で書き出しが発生した場合でも、ポインタ１８１７にカートリッジ毎のパステーブル５１２へのポインタを記録しているため、書き出した光ディスクにアクセスすることなく管理テーブルの読み出しが可能であるという効果がある。
【０３１０】
バッファリングサーバ内の制御用メモリの空き容量を確保するためには、ポインタ１８１７が指すシェア情報テーブル５１５を削除し、ポインタ１８１７をＮＵＬＬに設定することで、実現可能である。この場合は、書き出した光ディスクにアクセスすることで管理テーブルを読み出しが可能である。メモリの空き容量が増えたため、より多数のカートリッジをポインタテーブル５２１に登録可能となるという効果がある。
【０３１１】
以上が、タイムスタンプから生成した所有者ＩＤを用いてファイル書き込みを行う処理フローの説明である。
【０３１２】
図５０は、図３１に示す所有者ＩＤと図４９に示すシェア情報テーブルの取得処理を用いて、ファイル読み出しを行う処理フローである。
【０３１３】
図５０によると、パスから所有者ＩＤを抽出する。パスは、例えば、／ＯｗｎｅｒＩＤ／ＤｉｒｅｃｔｏｒｙＮａｍｅ／ＦｉｌｅＮａｍｅという構成である。こここで、「ＯｗｎｅｒＩＤ」はシェア名の文字列であり、シェア情報テーブル５１５から、シェア１０１２から所有者ＩＤ１０１１を取得できる。「ＤｉｒｅｃｔｏｒｙＮａｍｅ」は、Ｆｉｌｅを格納するディレクトリの名前の文字列、「ＦｉｌｅＮａｍｅ」は記録するファイルの名前の文字列、を示す。また、「／」は区切り文字を示す文字である。「ＤｉｒｅｃｔｏｒｙＮａｍｅ」はこの例では１つのみを記載したが、階層構造をとっても良い。（Ｓ５００１）
次に、所有者ＩＤから、タイムスタンプ（年月日、時分秒）を抽出する。図３１の構成より、所有者ＩＤの文字列３２バイトのなかから、年月日を取り出すには、１６〜２３バイト３１１２に相当する部分を抽出しＢＣＤから数値へ変換すればよい。また、時分秒を取り出すには、８〜１５バイト３１１３に相当する部分を抽出しＢＣＤから数値へ変換すればよい。（Ｓ５００２）
次に、図４８に示すような、シェア情報テーブルの取得処理を行う。（Ｓ５００３）
次に、図４８のシェア情報取得処理により取得したシェア情報テーブル５１５を参照し、パスに含まれるシェア名１０１２から所有者ＩＤ１０１１を取得し、さらにカートリッジ情報テーブル５１６を参照し、所有者ＩＤ１１１２からカートリッジＩＤ１１１１を取得する。（Ｓ５００４）
取得したカートリッジＩＤのカートリッジの管理情報を保持したメタデータカートリッジと光ディスクは、ポインタテーブル５２１から分かるので、当該メタデータカートリッジから当該光ディスクを装填し、スタブ情報ファイルを読み出すことで、実施例７で示したような読み出し処理を行う。（Ｓ５００５）
図４８は、シェア情報テーブルの取得処理を示した処理フローである。
【０３１４】
図４８によると、シェア情報テーブル５１５がオンラインかどうかを判断する。（Ｓ４８０１）
判断方法は、ポインタテーブル５２０を参照し、当該ファイルが含まれるカートリッジのカートリッジＩＤの指すポインタが存在し、かつ、ＮＵＬＬとなっていないことを条件として、オンラインであると判断する。
【０３１５】
オンラインである場合は、処理を終了する。
【０３１６】
オンラインで無い場合は、ポインタテーブル５２１を参照し、当該ファイルが含まれるカートリッジのシェア情報テーブル５１５を光ディスクからバッファリングサーバ内の制御用メモリに読み出す。（Ｓ４８０２）
読み出すファイルのシェア情報テーブルが、メモリ上に読み出したポインタテーブル５２１の参照先に存在しなかった場合は、シェア情報テーブルをオンラインにできない。一方、シェア情報テーブルが、ポインタテーブル５２１の参照先に存在する場合は、オンラインにできる。（Ｓ４８０３）
オンラインにできた場合は、ポインタテーブル５２１のポインタ１８１７に、読み出したシェア情報テーブルへのポインタを設定する。（Ｓ４８０６）
オンラインにできなかった場合は、光ディスク上のポインタテーブルを指す管理テーブル（ポインタテーブルリスト５２５）を参照し、所有者ＩＤが最小ＯＩＤ最大ＯＩＤ１８２１に含まれるカートリッジと光ディスクを特定し、当該光ディスクを搬送し、ポインタテーブルを読み出す。（Ｓ４８０４）
読み出したポインタテーブル５２１を参照して、当該ファイルが含まれるカートリッジのシェア情報テーブル５１５を光ディスクからバッファリングサーバ内の制御用メモリに読み出す。ポインタテーブル５２１が指すシェア情報テーブルのうち、どれに所望のカートリッジのシェア情報テーブルが該当するかは、最小ＯＩＤ最大ＯＩＤ１８２１の範囲を、所有者ＩＤに含まれるタイムスタンプで二分木探索で絞り込むことで、効率的に探索可能である。二分木探索を行わない場合は、最悪でメタデータカートリッジ内の全ディスクを搬送する必要があり、時間がかかるが、二分木探索を行うことで、最悪でも半分のディスクの搬送で済む、という効果がある。（Ｓ４８０５）
読み出したポインタテーブル５２１のポインタ１８１７に、読み出したシェア情報テーブル５１５へのポインタを設定する。（Ｓ４８０６）
Ｓ４８０６で、ポインタ１８１７にシェア情報テーブル５１５へのポインタを記録しているため、以後、書き出した光ディスクにアクセスすることなく管理テーブルの読み出しが可能となるという効果がある。
【０３１７】
バッファリングサーバ内の制御用メモリの空き容量を確保するためには、Ｓ４８０２に先立って、ポインタ１８１７が指すシェア情報テーブル５１５のうちアクセス頻度が低いものを優先して削除し、ポインタ１８１７をＮＵＬＬに設定することで、実現可能である。
【０３１８】
以上のように、シェア情報テーブル５１５のみならず、ポインタテーブル５２１も光ディスクに書き出すことで、ストレージ装置に格納する管理情報のサイズを減らすことが可能となり、ストレージ装置の容量増によるコスト増を抑えることが可能であるという効果がある。さらに、アクセス頻度の高いファイルに対しては、ストレージ装置上に管理情報を残すことで、カートリッジ搬送やディスク搬送に伴う待ち時間発生を抑制し、アクセス性や検索性を確保できるという効果がある。さらに、光ディスクに格納したシェア情報テーブルの格納位置を取得するために、最大でも、ストレージ装置上のポインタテーブルリスト５２５と、光ディスクに書き出したポインタテーブル５２１を搬送して参照すればよいため、光ディスク搬送の回数を最大１回に抑制でき、本実施例の管理を行わない場合に想定される多数回の光ディスク搬送による待ち時間が発生せず、多数ファイルを対象にした場合でもアクセス性や検索性を確保できるという効果がある。
【０３１９】
以上が、タイムスタンプから生成した所有者ＩＤを用いて、ファイル読み出しを行う処理フローの説明である。
【０３２０】
実施例８のようにパスごとの記録時刻情報（タイムスタンプが含まれるＩＤ）をユーザ側で管理する必要がなく、パスのみで記録位置を識別可能であるという効果がある。また、ファイル数やシェア数が増加しシェア情報テーブルが大規模になった場合も、検索性を確保した状態で管理可能であるという効果がある。
【０３２１】
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０３２２】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラムは、ローカルメモリ以外にも、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。 
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０３２３】
１０１  光ディスクライブラリ装置
１０２  バッファリングサーバ
１０３  管理サーバ
１０４  ストレージ装置
１０５  ホスト
１１１  ＣＰＵ
１１２  制御用メモリ
１１３  光ディスク搬送装置
１１４  ドライブ
１１５  カートリッジ
１１６  光ディスク
２１１  ＣＰＵ
２１２  制御用メモリ
３１１  サーバコマンド制御部
３１２  資源管理部
４１１  ホストコマンド制御部
４１２  記録位置管理部
４１３  マイグレーション制御部
【図１】
2016199230.tif 000003
【図２】
2016199230.tif 000004
【図３】
2016199230.tif 000005
【図４】
2016199230.tif 000006
【図５】
2016199230.tif 000007
【図６】
2016199230.tif 000008
【図７】
2016199230.tif 000009
【図８】
2016199230.tif 000010
【図９】
2016199230.tif 000011
【図１０】
2016199230.tif 000012
【図１１】
2016199230.tif 000013
【図１２】
2016199230.tif 000014
【図１３】
2016199230.tif 000015
【図１４】
2016199230.tif 000016
【図１５】
2016199230.tif 000017
【図１６】
2016199230.tif 000018
【図１７】
2016199230.tif 000019
【図１８】
2016199230.tif 000020
【図１９】
2016199230.tif 000021
【図２０】
2016199230.tif 000022
【図２１】
2016199230.tif 000023
【図２２】
2016199230.tif 000024
【図２３】
2016199230.tif 000025
【図２４】
2016199230.tif 000026
【図２５】
2016199230.tif 000027
【図２６】
2016199230.tif 000028
【図２７】
2016199230.tif 000029
【図２８】
2016199230.tif 000030
【図２９】
2016199230.tif 000031
【図３０】
2016199230.tif 000032
【図３１】
2016199230.tif 000033
【図３２】
2016199230.tif 000034
【図３３】
2016199230.tif 000035
【図３４】
2016199230.tif 000036
【図３５】
2016199230.tif 000037
【図３６】
2016199230.tif 000038
【図３７】
2016199230.tif 000039
【図３８】
2016199230.tif 000040
【図３９】
2016199230.tif 000041
【図４０】
2016199230.tif 000042
【図４１】
2016199230.tif 000043
【図４２】
2016199230.tif 000044
【図４３】
2016199230.tif 000045
【図４４】
2016199230.tif 000046
【図４５】
2016199230.tif 000047
【図４６】
2016199230.tif 000048
【図４７】
2016199230.tif 000049
【図４８】
2016199230.tif 000050
【図４９】
2016199230.tif 000051
【図５０】
2016199230.tif 000052
【国際調査報告】
2016199230.tif 000053
2016199230.tif 000054