JP6152484B2 - ファイルサーバ装置、方法、及び、計算機システム - Google Patents

Description

本発明は、ファイルサーバ装置に関する。

ユーザ毎に与えられたファイルの格納領域の容量を管理し、ユーザがその容量を超えたデータを格納しようとした場合に、ユーザにエラーを返すファイルストレージシステムが知られている（特許文献１）。

また、ファイルストレージシステムに書き込まれたデータを、ファイルストレージシステムに接続されたアーカイブストレージシステムにアーカイブする計算機システムが知られている（特許文献２）。

米国特許公開第２００５／００４４１９８号明細書 米国特許公開第２０１２／００６６１７９号明細書

特許文献１は、ファイルストレージシステムが、自身に記憶されるファイルの容量をユーザ毎に管理している。

特許文献２は、ファイルストレージシステムが、ユーザ毎に格納するデータの容量制限を設けており、このファイルストレージシステムの容量制限に基づき、ユーザのデータの書込みの可否を判断している。

しかしながら、ファイルストレージシステムと、アーカイブストレージシステムとで、ユーザが使用できる記憶領域の容量が異なる場合がある。このため、ファイルストレージシステムが自身の容量制限に基づきデータを格納していくと、アーカイブシステムの容量制限を超え、アーカイブファイルを格納できなくなる場合がある。

上記課題を解決するために、本発明に係るファイルサーバ装置は、ホスト計算機と、ファイルのデータを格納する記憶装置と、記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、プログラムを実行するプロセッサと、を有する。プロセッサは、アーカイブシステムの記憶領域の容量と、記憶領域の使用容量と、を管理する。プロセッサは、ホスト計算機からファイルの書込み要求を受信すると、書込み要求にかかるファイルがアーカイブされた場合のアーカイブシステムの記憶領域の使用容量を算出し、アーカイブシステムの記憶領域の容量と、算出した使用容量と、に基づいて書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定する。プロセッサは、アーカイブが不可能と判定した場合、ホスト計算機にエラーを通知する。

本発明によると、アーカイブシステムに適切にアーカイブファイルを格納することができる。

本実施例に係る計算機システムのハードウェア構成を示す。 本実施例に係る計算機システムのソフトウェア構成を示す。 サブツリー情報管理テーブル３００の一例を示す。 使用量推測テーブル４００の一例を示す。 連携情報５００の一例を示す。 ｉｎｏｄｅ管理テーブルの一例を示す。 連携処理のフローチャートを示す。 ファイルのリード又はライト要求の受付処理のフローチャートの前半部である。 ファイルのリード又はライト要求の受付処理のフローチャートの後半部である。 ファイルの作成要求及びライト要求時の容量推測処理のフローチャートである。 ファイルの削除要求の受付処理のフローチャートである。 ファイルの削除要求時の容量推測処理のフローチャートである。 データムーバ処理のフローチャートの前半部である。 データムーバ処理のフローチャートの後半部である。 誤差補正処理のフローチャートである。 ファイルの作成要求の受付処理のフローチャートである。 ＮＳ連携処理の指示画面の一例である。

以下、図面を参照して、本発明の実施例を説明する。以下の図中、同一の部分には同一の符号を付加する。ただし、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。

なお、以下の説明では、「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ(Central Processing Unit)）によって実行されることで、定められた処理を適宜に記憶資源（例えばメモリ）及び通信インタフェース装置（例えば通信ポート）を用いながら行うため、処理の主語がプロセッサとされても良い。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

また、各要素は、ＩＤ、番号、識別子、などの識別情報で識別可能であるが、識別可能な情報であれば、名前など他種の情報が用いられても良い。なお、以下の説明では、図面の参照符号に代えて、何らかの対象を識別するための情報として、ＩＤ、識別子、番号などの識別情報を用いる場合がある。

図１は、本実施例の計算機システムのハードウェア構成を示す。

計算機システムは、ファイルストレージシステム２とアーカイブシステム３を有する。ファイルストレージシステム２は、例えば、支点や営業所などユーザが業務を行う拠点である。また、アーカイブシステム３は、例えば、データセンタなどであり、少なくとも一つのストレージ装置を含む。

なお、図１では、ファイルストレージシステム２は複数、アーカイブシステム３が単数であるが、これらそれぞれの数はどのようでもよい。また、図１では、ファイルストレージシステム２として、複数のファイルサーバ装置１０と複数のクライアント／ホスト（以下、ホストと略記する）１２とが示されるが、これらそれぞれの数もどのようであってもよい。

ファイルストレージシステム２は、ＲＡＩＤシステム１１と、ファイルサーバ装置１０と、を備える。また、ファイルストレージシステム２は、ホスト１２に接続されていてもよく、ホスト１２を備えていてもよい。ファイルサーバ装置１０は、例えば、ＬＡＮ（Local Area Network）などの通信ネットワークＣＮ２経由でホスト１２に接続されている。また、ファイルサーバ装置１０は、例えば、ＳＡＮ（Storage Area Network）などの通信ネットワークＣＮ３経由でＲＡＩＤシステム１１に接続されている。

ＲＡＩＤシステム１１は、ストレージ装置であり、ＣＨＡ（Channel Adaptor）１１０と、ＤＫＣ（Disk Controller）１１１と、ＤＩＳＫ１１２とを備える。ＤＫＣ１１１に、ＣＨＡ１１０及びＤＩＳＫ１１２が接続されている。ＣＨＡ１１０は、ファイルサーバ装置１０に接続される通信インタフェース装置である。ＤＫＣ１１１は、コントローラである。ＤＩＳＫ１１２は、ディスク型の物理記憶デバイス（例えば、ＨＤＤ(Hard Disk Drive)）である。物理記憶デバイスは、他種の物理記憶デバイス（例えば、フラッシュメモリデバイス）であってもよい。また、図１では、ＤＩＳＫ１１２は単数であるが複数であってもよい。複数のＤＩＳＫ１１２で１以上のＲＡＩＤ（redundant array of inexpensive disks）グループが構成されてよい。

ＲＡＩＤシステム１１は、ファイルサーバ装置１０から送信されたブロックレベルのＩ／Ｏ（Input or Output）要求をＣＨＡ１１０で受信し、ＤＫＣ１１１の制御に基づいて、適切なＤＩＳＫ１１２へのＩ／Ｏを実行する。

ファイルサーバ装置１０は、メモリ１００とプロセッサ（ＣＰＵ）１０１と、ＮＩＣ（Network Interface Card）１０２と、ＨＢＡ（Host Bus Adaptor）１０３と、ＤＩＳＫ１０４と、を備える。メモリ１００、ＮＩＣ１０２及びＨＢＡ１０３に、ＣＰＵ１０１が接続されている。

ＮＩＣ１０２は、アーカイブサーバ装置２０及びホスト１２と通信するインタフェースである。

ＨＢＡ１０３は、ＲＡＩＤシステム１１と通信するインタフェースである。

メモリ１００は、ＣＰＵ１０１が直接読み書きできる記憶領域（例えば、ＲＡＭ（Random Access Memory）やＲＯＭ(Read Only Memory)）である。ファイルサーバ装置１０は、ファイルサーバ装置１０を制御するプログラム（例えばＯＳ（Operating System））をメモリ１００に読み込み、ＣＰＵ１０１に実行させる。このプログラムは、ＲＡＩＤシステム１１のＤＩＳＫ１１２に記憶されるが、ＤＩＳＫ１１４に記憶されていてもよいし、予めメモリ１００に記憶されていてもよい。また、ファイルサーバ装置１０は、メモリ１００及びＤＩＳＫ１０４に代えて又は加えて、他の種類の記憶資源を有してもよい。

ファイルサーバ装置１０は、ＮＩＣ１０２経由でホスト１２からファイルの処理要求を受信する。ファイルの処理要求には、例えば、リード要求、ライト要求（更新要求）、作成要求、削除要求、及び、メタデータ変更要求などが含まれる。ファイルサーバ装置１０は、その処理要求で指定されているファイルを構成するデータブロックのＩ／ＯのためのブロックレベルのＩ／Ｏ要求を作成する。ファイルサーバ装置１０は、ブロックレベルのＩ／Ｏ要求を、ＨＢＡ１０３経由でＲＡＩＤシステム１１に送信する。

ホスト１２は、メモリ１２０と、ＣＰＵ１２１と、ＮＩＣ１２２と、ＤＩＳＫ１２３と、を備える。ホスト１２は、メモリ１２０及びＤＩＳＫ１２３に代えて又は加えて、他の種類の記憶資源を有してもよい。

ホスト１２は、ホスト１２を制御するプログラム（例えばＯＳ）をメモリ１２０上に読み込み、ＣＰＵ１２１にそのプログラムを実行させる。このプログラムは、ＤＩＳＫ１２３に記憶されていてもよいし、予めメモリ１２０に記憶されていてもよい。また、ホスト１２は、ＮＩＣ１２２経由で、ファイルの処理要求をファイルサーバ装置１０に送信する。

アーカイブシステム３は、ＲＡＩＤシステム２１と、アーカイブサーバ装置２０と、を備える。アーカイブサーバ装置２０にＲＡＩＤシステム２１が接続されている。

ＲＡＩＤシステム２１は、ストレージ装置であり、ＣＨＡ２１０と、ＤＫＣ２１１と、ＤＩＳＫ２１２と、を備える。図１では、ＲＡＩＤシステム２１の構成とＲＡＩＤシステム１１の構成は同じである。従って、ＲＡＩＤシステム２１も、アーカイブサーバ装置２０から送信されたブロックレベルのＩ／Ｏ要求をＣＨＡ２１０で受信し、ＤＫＣ２１１の制御に基づいて、適切なＤＩＳＫ２１２へのＩ／Ｏを実行する。なお、ＲＡＩＤシステム２１の構成とＲＡＩＤシステム１１の構成は異なってもよい。

アーカイブサーバ装置２０は、メモリ２００と、プロセッサ（ＣＰＵ）２０１と、ＮＩＣ２０２と、ＨＢＡ２０３と、ＤＩＳＫ２０４と、を備える。アーカイブサーバ装置２０は、アーカイブサーバ装置２０を制御するプログラム（例えばＯＳ）をメモリ２００上に読み込み、ＣＰＵ２０１にそのプログラムを実行させる。このプログラムは、ＲＡＩＤシステム２１のＤＩＳＫ２１２に記憶されるが、ＤＩＳＫ２０４に記憶されていてもよいし、予めメモリ２００に記憶されていてもよい。また、アーカイブサーバ装置２０は、メモリ２００及びＤＩＳＫ２０４に代えて又は加えて、他の種類の記憶資源を有してもよい。また、アーカイブサーバ装置２０は、ＮＩＣ２０２及び通信ネットワークＣＮ４経由で、ファイルサーバ装置１０と通信する。アーカイブサーバ装置２０は、ＨＢＡ２０３経由で接続され、ブロック単位のアクセスを行う。

図２は、実施例１の計算機システムのソフトウェア構成を示す。

ＲＡＩＤシステム１１（２１）は、ＯＳＬＵ１１３（２１３）と、ＬＵ（Logical Unit）１１４（２１４）を有する。ＯＳＬＵ１１３（２１３）及びＬＵ１１４（２１４）は、論理的な記憶デバイスである。ＯＳＬＵ１１３（２１３）及びＬＵ１１４（２１４）は、それぞれ、１以上のＤＩＳＫ１１２（２１２）に基づく実体的なＬＵであってもよいし、Thin Provisioningに従う仮想的なＬＵであってもよい。ＯＳＬＵ１１３（２１３）及びＬＵ１１４（２１４）は、それぞれ、複数のブロック（記憶領域）で構成されている。ＯＳＬＵ１１３（２１３）には、各サーバ装置１０（２０）を制御するプログラム（ＯＳ）が記憶されてよい。ＬＵ１１４（２１４）には、ファイルが記憶される。また、ＬＵ１１４（２１４）に、後述のファイル管理情報の全部又は一部が記憶されてもよい。

ファイルサーバ装置１０のメモリ１００には、ファイル共有プログラム１０５と、データムーバプログラム１０６と、受付プログラム１１０と、ファイルシステムプログラム１０７と、カーネル／ドライバ１０９と、が記憶されている。ファイルシステムプログラム１０７は、サブツリー管理情報１０８を含む。

ファイル共有プログラム１０５は、ＣＩＦＳ（Common Internet File System）、ＮＦＳ（Network File System）といった通信プロトコルを使用して、ホスト１２との間で、ファイル共有サービスを提供するプログラムである。受付プログラム１１０は、ホスト１２からのファイルの処理要求に基づき、各種のファイル操作を行うプログラムである。カーネル／ドライバ１０９は、ファイルサーバ装置１０上で動作する複数のプログラム（プロセス）のスケジュール制御やハードウェアからの割り込みをハンドリングするなど、全般的な制御及びハードウェア固有の制御を行う。データムーバプログラム１０６については、後述する。

ファイルシステムプログラム１０７は、ファイルシステムを実現するプログラムである。ファイルシステムプログラム１０７は、サブツリーを管理するためのサブツリー管理情報１０８（図中ではサブツリー）を管理する。サブツリー管理情報１０８は、サブツリーに属するファイルの管理情報（ファイル管理情報）を含む。サブツリー管理情報１０８は、例えば、後述するｉｎｏｄｅ管理テーブル６００であってよい（図６）。また、サブツリー管理情報１０８は、例えば、サブツリー情報管理テーブル３００（図３）、使用量推測テーブル４００（図４）、及び、連携情報５００（図５）などが含まれてよい。なお、本実施例では、サブツリーは、ファイルシステム内のツリーの一部を成すオブジェクト（ファイル及びディレクトリ）群であり、１つのユーザから書き込まれるファイルが管理される単位であるとする。しかし、サブツリーの単位は、これに限られず、複数のユーザ（ユーザグループ）から書き込まれるファイルが管理される単位であってもよいし、１つ又は複数のホスト１２から書き込まれるファイルが管理される単位であってもよい。

アーカイブサーバ装置２０のメモリ２００には、データムーバプログラム２０５と、ネームスペースプログラム２０６と、カーネル／ドライバ２０７と、が記憶されている。カーネル／ドライバ２０７は、上述のカーネルドライバ１０９とほぼ同様である。

ネームスペースプログラム２０６は、ネームスペースを実現するプログラムである。本実施例では、ネームスペースは、アーカイブシステム３上に作成される名前空間であり、ファイルシステムの１つのサブツリーが、１つのネームスペースに対応づけられる。例えば、１つのユーザから書き込まれるファイルは、１つのサブツリーにより管理されてＬＵ１１４に書き込まれるとともに、このサブツリーに対応する１つのネームスペースにレプリケーション又は同期されることにより、ＬＵ２１４にアーカイブファイルとしてアーカイブされる。以下の説明及び図面では、ネームスペースをＮＳと略記する場合がある。ネームスペースプログラム２０６は、ネームスペースに格納されるアーカイブファイルのファイル管理情報であるアーカイブファイル管理情報を含む。なお、アーカイブサーバ装置２０におけるファイルシステムは、ファイルサーバ装置１０におけるファイルシステムと異なる場合がある。また、アーカイブファイル管理情報は、前述したファイル管理情報とは異なる情報であり、その情報のサイズも異なる。アーカイブファイル管理情報は、例えば、アーカイブファイル毎のｉｎｏｄｅを管理するテーブル（ｉｎｏｄｅ管理テーブルに相当するテーブル）を含んでもよいが、当該テーブルに含まれるメタデータは異なる。例えば、当該テーブルには、アーカイブファイルを圧縮又は重複排除した場合の情報が含まれてもよいし、アーカイブファイルを世代管理した場合の情報が含まれてもよい。

ファイルサーバ装置１０のデータムーバプログラム１０６、及びアーカイブサーバ装置２０のデータムーバプログラム２０５を説明する。以下、ファイルサーバ装置１０内のデータムーバプログラム１０６を「ローカルムーバ」と言い、アーカイブサーバ装置２０内のデータムーバプログラム２０５を「リモートムーバ」と言い、それらを特に区別しない場合に、「データムーバプログラム」と言う。ファイルサーバ装置１０とアーカイブサーバ装置２０との間では、ローカルムーバ１０６及びリモートムーバ２０５を介して、ファイルのやり取りが行われる。

ローカルムーバ１０６は、ＲＡＩＤシステム１１のＬＵ１１４にファイルを書き込むとともに、ＬＵ１１４に書き込まれたレプリケーション対象ファイルをアーカイブサーバ装置２０に転送する。リモートムーバ２０５は、レプリケーション対象ファイルをファイルサーバ装置１０から受信し、そのファイルのアーカイブファイルをＲＡＩＤシステム２１のＬＵ２１４に書き込む。この一連の処理により、アーカイブシステム３には、ファイルストレージシステム２に格納されているファイルの複製が作成される。この一連の処理を、レプリケーション対象ファイルをレプリケーションするという。また、アーカイブシステム３には、ファイルストレージシステム２に格納されているファイルの複製が作成することをアーカイブするともいう。

また、ローカルムーバ１０６は、ＲＡＩＤシステム１１のＬＵ１１４から、レプリケーション後に更新された対象ファイルを取得し、更新後の対象ファイルをアーカイブサーバ装置２０に転送する。リモートムーバ２０５は、更新後の対象ファイルをファイルサーバ装置１０から受信し、受信されたファイルのアーカイブファイルにより、ＬＵ２１４に格納されているアーカイブファイルを上書きする。この一連の処理を、対象ファイルとアーカイブファイルとを同期するという。

なお、ローカルムーバ１０６は、更新後の対象ファイルをレプリケーションしてもよい。例えば、この場合、レプリケーション対象ファイルが世代管理されているという。世代管理が行われる場合、対象ファイルのアーカイブファイルは、対象ファイルの複数のレプリケーションによりアーカイブシステム３に作成されたファイルを含んでもよい。

また、ローカルムーバ１０６は、所定の条件が満たされた場合に、ＬＵ１１４内のレプリケーション済みファイルの実体（データ）を削除する。これは、例えば、レプリケーション済みファイルの実質的なマイグレーションである。この処理を、以下ではファイルをスタブ化するという。その後、そのスタブに対してホスト１２からリード要求を受けた場合、ローカルムーバ１０６は、リモートムーバ２０５を経由してスタブにリンクしているファイルを取得し、取得したファイルをホスト１２に送信する。なお、本実施例において、スタブとは、ファイルの格納先（リンク先）情報に関連付けられたオブジェクト（メタデータ）である。ホスト１２からは、ファイルであるかスタブであるかはわからない。

ホスト１２のメモリ１２０には、アプリケーション１２１と、ファイルシステムプログラム１３１と、カーネル／ドライバ１２３と、が記憶されている。

アプリケーション１２１は、ホスト１２が作業の目的に応じて使うソフトウェア（アプリケーションプログラム）である。ファイルシステムプログラム１３１及びカーネル／ドライバ１２３は、上述のファイルシステムプログラム１０７及びカーネルドライバ１０９（２０７）と同様である。

図６は、ｉｎｏｄｅ管理テーブルの一例を示す。

ｉｎｏｄｅ管理テーブル６００は、複数のｉｎｏｄｅより構成される。１つのエントリが１つのｉｎｏｄｅに対応し、１つのｉｎｏｄｅが、１つのファイルに対応する。各ｉｎｏｄｅは、複数のメタデータで構成される。メタデータの種類としては、ファイルのｉｎｏｄｅ番号、ファイルの所有者、ファイルのアクセス権、ファイルのサイズ、ファイルの最終アクセス日時、ファイル名、レプリケーション済フラグ、スタブ化フラグ、ファイルのリンク先、ファイルの実体が格納されるＬＵ１１４の位置（ブロックアドレス・・・）などがある。レプリケーション済フラグは、当該ファイルに対しアーカイブシステム３内のアーカイブファイルが同期した状態（同期状態）か否かを示す。つまり、この状態において、ファイルストレージシステム２内の当該ファイルとアーカイブシステム３内のアーカイブファイルとで、データの整合性がとれている。当該ファイルがレプリケーション又は同期された後に更新されていない状態のとき、レプリケーション済フラグは“ＯＮ”となる、また当該ファイルの作成又は更新の後にレプリケーション又は同期がされていない状態のとき、レプリケーション済フラグは“ＯＦＦ”となる。スタブ化フラグは、当該ファイルがスタブ化されている場合は“ＯＮ”であり、当該ファイルがスタブ化されていない場合は“ＯＦＦ”である。リンク先は、当該スタブがリンクするファイルのｉｎｏｄｅ番号である。また、当該ファイルは、アーカイブファイルと同期状態の時にスタブ化される。従って、当該ファイルがスタブ化されている状態のとき、つまりスタブ化フラグが“ＯＮ”のときは、当該ファイルのレプリケーションフラグは“ＯＮ”である。

また、本実施例では、各ｉｎｏｄｅは、サブツリーＩＤ６０１を含む。サブツリーＩＤ５０１は、当該ファイルが格納されるサブツリーの識別子である。

図３は、サブツリー情報管理テーブル３００の一例を示す。

サブツリー情報管理テーブル３００は、各ファイルサーバ装置１０のメモリに記憶される。このテーブル３００は、ファイルサーバ装置１０が有するファイルシステムのサブツリーに関する情報を管理するテーブルである。例えば、このテーブル３００では、サブツリーに対応するアーカイブシステムの記憶領域（ＮＳ）の容量と、その記憶領域（ＮＳ）の使用容量が管理される。このテーブル３００は、サブツリー毎のエントリを有する。サブツリーＩＤ３０１は、当該サブツリーの識別子である。Ｑｕｏｔａ値３０３は、当該サブツリーが使用できるＬＵ１１４の制限容量を示す。従って、例えば、１つのユーザが1つのサブツリーを使用する場合、Ｑｕｏｔａ値３０３は、1つのユーザが使用できるＬＵ１１４の制限容量（容量）となる。使用量３０５は、当該サブツリーが実際に使用しているＬＵ１１４の量（容量）を示す。連携ビット（Ａ１）３０７は、当該ファイルストレージシステム２がアーカイブシステム３と連携しているか否かを示すビットである。ここでいう連携とは、例えば、当該ファイルストレージシステム２のサブツリーがアーカイブシステム３のＮＳに対応づけられており、サブツリーが管理するファイルのアーカイブファイルをＮＳが管理し得る状態をいう。連携ビットが「１」の場合、ファイルストレージシステム２とアーカイブシステム３は連携しており、連携ビットが「０」の場合、これらは連携していない。ファイルストレージシステム２とアーカイブシステム３が連携する場合、サブツリーのＱｕｏｔａ値（記憶領域の容量）と、そのサブツリーに対応するＮＳのＱｕｏｔａ値（記憶領域の容量）は同じであり、ＮＳ Ｑｕｏｔａ取得値３０９、ＮＳ取得使用量３１１、ＮＳ Ｑｕｏｔａ推測値３１３及びＮＳ推測使用量３１５の項目に値が設定される。

ＮＳ Ｑｕｏｔａ取得値３０９は、当該サブツリーに対応するＮＳが使用できるＬＵ２１４の制限容量を示す。従って、例えば、１つのユーザが１つのサブツリーを使用する場合、ＮＳ Ｑｕｏｔａ取得値３０９は、1つのユーザが使用できるＬＵ２１４の制限容量となる。ＮＳ取得使用量３１１は、当該サブツリーに対応するＮＳが実際に使用しているＬＵ２１４の量を示す。ＮＳ Ｑｕｏｔａ推測値３１３は、当該サブツリーに対応するＮＳが使用できるＬＵ２１４の制限容量の推測値を示す。ＮＳ推測使用量３１５は、当該サブツリーに対応するＮＳが実際に使用しているＬＵ２１４の量の推測値を示す。なお、本実施例では、Ｑｕｏｔａ値２０２及びＮＳ Ｑｕｏｔａ取得値３０９は、ユーザとの契約に基づきあらかじめ設定されるが、これに限られない。また、ＮＳ Ｑｕｏｔａ推測値３１３は、ＮＳ Ｑｕｏｔａ取得値３０９と同じ値であってよい。ＮＳ取得使用量３１１は、アーカイブサーバ装置２０により測定され記憶されており、レプリケーション又は同期においてアーカイブサーバ装置２０から取得される値である。また、ＮＳ推測使用量３１５は、ファイルサーバ装置１０により推定される値である。同期状態において、ＮＳ推測使用量３１５は、ＮＳ取得使用量３１１に等しくなる。

以下、具体的に説明する。まず前提として、サブツリーに属するファイルＡに対しファイル操作が行われた場合を考える。ファイルＡに対するファイル操作が行われた後のサブツリーの使用量をＢ（使用量３０５）とし、その内訳を、当該サブツリーに格納される全てのファイルの実データ量の合計値Ｂ１０と、当該サブツリーに格納される全てのファイルのファイル管理情報の量Ｂ２０とする。また、当該サブツリーに格納される全てのファイルが、当該サブツリーに対応するＮＳにアーカイブされる場合の当該ＮＳの使用量としてファイルサーバ装置１０が推定する値をＣとし、その内訳を、ＮＳに格納される全アーカイブファイルの実データ量の合計としてファイルサーバ装置１０が推定する値Ｃ１０と、当該ＮＳに管理される全てのアーカイブファイルのアーカイブファイル管理情報の量としてファイルサーバ装置１０が推定する値をＣ２０とする。また、Ｂに対するＣの差分の容量をαとする。ファイルサーバ装置１０は、ファイルサーバ装置１０とアーカイブサーバ装置２０の管理情報の違いに基づいてαを算出してもよいし、アーカイブサーバ装置２０から取得されたＮＳの使用量に基づいてαを算出してもよい。

このとき、ＮＳ推測使用量３１５は、Ｂにαを加えた値であってよい。また、ＮＳ推測使用量３１５は、Ｂ１０にＣ２０を加えた値であってもよい。なお、αは、当該サブツリーに格納される全てのファイル（ｆ１、ｆ２・・・ｆｎ）のファイル操作における、サブツリーの使用量Ｂの増減量とＮＳの使用量Ｃの増減量との差分の合計（α＝α１＋α２・・・αｎ）であってよい。ファイルとそのアーカイブファイルの実データ量が変わらない場合においては、ＮＳ推測使用量３１５を、実データとファイル管理情報（アーカイブ管理情報）とに分けて推定することにより、ファイルを格納したときのファイルサーバ装置１０とアーカイブサーバ装置２０とでファイルを格納した場合の誤差を低減できる。

また、ＮＳ推測使用量３１５は、例えば、ホスト１２からファイルの処理要求があったときなどに、図４の使用量推測テーブル４００に基づき、ファイルサーバ装置１０のＣＰＵ１０１が算出してよい。例えば、各ファイルサーバ装置１０は、ホスト計算機からファイル処理要求を受信すると、以下に説明するファイル処理要求応じたファイルサイズの推測方法により、ファイルがアーカイブされた場合のアーカイブシステムの記憶領域の使用容量を算出する。

また、ファイルストレージシステム２側のＱｕｏｔａ値３０３と、アーカイブシステム３側のＮＳ Ｑｕｏｔａ取得値（ＮＳ Ｑｕｏｔａ推測値３１３）とは、同じ値であってもよいし、異なる値であってもよい。

図４は、使用量推測テーブル４００の一例を示す。

使用量推測テーブル４００は、各ファイルサーバ装置１０のメモリに記憶されてよい。このテーブル４００は、ファイルの処理要求に応じたファイル操作毎に、ファイル操作を行ったときのアーカイブファイルのファイルサイズの推測方法を示す。以下、ファイル操作を説明する。

ファイル作成は、ファイル作成要求に基づくファイル操作である。この操作では、サブツリーに格納されるファイルを新たに作成する。

ファイル編集は、ライト要求に基づくファイル操作である。この操作では、同期状態にあるファイルを上書きする。つまりｉｎｏｄｅ管理テーブル６００のレプリケーション済フラグが“ＯＮ”のとき、サブツリーに格納されるファイルを更新する。

ファイル再編集は、ライト要求に基づくファイル操作である。この操作では、同期状態にないファイルの上書きをする。つまり、ｉｎｏｄｅ管理テーブル６００のレプリケーション済フラグが“ＯＦＦ”のとき、サブツリーに格納されるファイルを更新する。

ファイル削除は、ファイル削除要求に基づくファイル操作である。この操作では、サブツリーに格納されるファイルを削除する。

メタデータ操作は、メタデータ変更要求に基づくファイル操作である。この操作では、例えば、ｉｎｏｄｅ管理テーブル６００の所有者やアクセス権などのメタデータを直接編集する。

次に、ファイル操作を行ったときのファイルのファイルサイズの推測方法（容量推測処理）を説明する。各ファイル操作には、ＮＳ推測使用量３１５の推測方法が対応づけられる。各ファイル操作の推測方法は、例えば以下である。

ファイル作成の場合（Ａ１：第１状態）、ファイル作成後のＮＳ推測使用量３１５は、ファイル作成前のＮＳ使用量に、対象ファイルのアーカイブファイルのサイズを加えた値である。ファイル作成前のＮＳ使用量として採用される値は、ＮＳ推測使用量３１５である。

ファイル編集の場合（Ａ２：第２状態）、ファイル編集前のＮＳ使用量に、ファイル編集後の対象ファイルのアーカイブファイルのサイズの変化量を加えた値である。なお、ファイル編集は、編集対象のファイルが同期状態で行われるファイル操作である。

ファイル再編集の場合（Ａ３：第２状態）、ファイル再編集前のＮＳ使用量に、ファイル再編集後の対象ファイルのアーカイブファイルのサイズの変化量を加えた値である。なお、ファイル再編集は、編集対象のファイルが同期状態で行われるファイル操作ではない。ファイル再編集前のＮＳ使用量として採用される値は、ＮＳ推測使用量３１５である。

ファイル削除の場合（Ａ４：第３状態）、ファイル削除前のＮＳ使用量から対象ファイルのアーカイブファイルのサイズを減じた値である。ファイル削除前のＮＳ使用量として採用される値は、ＮＳ推測使用量３１５である。

メタデータ操作の場合（Ａ５：第４状態）、メタデータ操作前のＮＳ使用量に、メタデータ操作によるアーカイブファイル管理情報のサイズの変化量を加えた値である。メタデータ操作前のＮＳ使用量として採用される値は、ＮＳ推測使用量３１５である。

なお、上記Ａ１〜Ａ４において、ファイルストレージシステム２は、対象ファイルのサブツリーへの書き込みの前に、対象ファイルのサイズに基づいて、対象ファイルのアーカイブファイルのサイズを推測する。ここで、対象ファイルのファイルサイズは、対象ファイルの実データのサイズに、ファイル管理情報のうち対象ファイルに対応する部分であるファイル部分のサイズを加えたものである。当該アーカイブファイルのファイルサイズは、当該アーカイブファイルの実データのサイズに、アーカイブファイル管理情報のうち当該アーカイブファイルに対応する部分であるアーカイブファイル部分のサイズを加えたものである。ファイルストレージシステム２は、対象ファイルの実データのサイズに基づいて、当該アーカイブファイルの実データのサイズを推測し、当該ファイル部分のサイズに基づいて、当該アーカイブファイル部分のサイズを推測する。

例えば、レプリケーション又は同期に伴い、圧縮、重複排除、世代管理等が行われることにより、ファイルの実データのサイズと、アーカイブファイルの実データのサイズが異なる場合がある。例えば、ファイルストレージシステム２は、ファイルの実データのサイズに、予め設定された係数ｘを乗じた値を、アーカイブファイルの実データのサイズとして推測する。係数ｘは例えば、データ加工処理の特性に基づいて決定される。また、係数ｘは例えば、実際のファイルの実データのサイズと、実際のアーカイブファイルの実データのサイズとの比較に基づいて決定されても良い。また、ファイルストレージシステム２は、同期処理の度にアーカイブファイルの実データのサイズを記憶し、記憶されたサイズに基づいて、同期処理後のアーカイブファイルの実データのサイズを推測してもよい。

例えば、ファイルストレージシステム２は、ファイル部分のサイズに、予め設定された係数βを乗じた値を、アーカイブファイル部分のサイズとして推測する。係数ｙは例えば、ファイルストレージシステム２内のファイルシステムの特性と、アーカイブシステム３内のファイルシステムの特性とに基づいて決定される。また、係数ｙは例えば、実際のファイル管理情報のサイズと、実際のアーカイブファイル管理情報のサイズとの比較に基づいて決定されても良い。また、ファイルストレージシステム２は、同期の度にアーカイブファイル部分のサイズを記憶し、記憶されたサイズに基づいて、同期後のアーカイブファイル部分のサイズを推測してもよい。

図５は、連携情報５００の一例を示す。

連携情報５００は、ファイルストレージシステム２のサブツリーと、アーカイブシステム３のＮＳとの連携（対応）を示す。サブツリーＩＤ５０１は、当該サブツリーの識別子である。ＮＳパス名５０３は、当該サブツリーに対応するＮＳへのパスを示す。

連携処理は、ホスト１２が利用するファイルストレージシステム２のサブツリーを、アーカイブシステム３のＮＳに対応づける処理である。この処理は、ファイルサーバ装置１０のＣＰＵ１０１が、メモリ１００内の連携プログラムを実行することにより行われる。この処理は、ホスト１２から、ホスト１２が利用するサブツリーに対してＮＳ連携処理の指示があった場合に行われる。ＮＳ連携処理の指示を、図１７を参照して説明する。ホスト１２の表示装置に表示される指示画面１７０１において、ユーザは、自身が利用するサブツリーがＮＳと連携する旨をチェックし、連携先のＮＳへのパス名を入力して、「確定」ボタンを押すことにより指示を送信する。これにより、表示装置に確認画面１７０２が表示される。ユーザは、確認画面１７０２において、連携先ＮＳのパス名と、連携先ＮＳの使用できる制限容量（Ｑｕｏｔａ値）とを確認し、確定ボタンを押すことにより指示を確定する。以下の説明においては、ホスト１２からの連携処理の指示の対象となるサブツリー及びＮＳを、対象サブツリー及び対象ＮＳという。

図７は、連携処理のフローチャートを示す。

ステップＳ７０１で、連携処理プログラムは、対象サブツリーと対象ＮＳとを対応づける。具体的には、例えば、連携処理プログラムは、アーカイブシステム３から対象ＮＳを取得し、各テーブルを更新する。具体的には、連携処理プログラムは、サブツリー情報管理テーブル３００の対象サブツリーの連携ビットを「１」にし、かつ、連携情報５００の対象ＮＳのＮＳパス名５０３に、対象ＮＳへのパスを登録する。

ステップＳ７０３で、連携処理プログラムは、対象ＮＳのＱｕｏｔａ値及び使用量を取得する。

ステップＳ７０５で、連携処理プログラムは、サブツリー情報管理テーブル３００を更新する。例えば、連携処理プログラムは、対象ＮＳのＱｕｏｔａ値を、ＮＳ Ｑｕｏｔａ取得値３０９及びＮＳＱｕｏｔａ推測値３１３にそれぞれ登録する。また、例えば、連携処理プログラムは、対象ＮＳの使用量を、ＮＳ取得使用量３１１及びＮＳ推測使用量３１５にそれぞれ登録する。

上記処理により、ファイルシステムのサブツリーとアーカイブシステムのＮＳとを対応づけることができる。また、サブツリーに対応するＮＳのＱｕｏｔａ値及び使用量を、アーカイブ装置から取得することができる。なお、上述の通り、連携処理プログラムは、ＮＳのＱｕｏｔａ値として、ユーザにより予め設定された値を、ＮＳ Ｑｕｏｔａ取得値３０９及びＮＳＱｕｏｔａ推測値３１３にそれぞれ登録してもよい。

次に、受付プログラム１１０が行う受付処理を説明する。この処理は、ＣＰＵ１０１が受付プログラム１１０を実行することにより行われる。この処理は、ファイルの処理要求毎に異なってよい。以下、順に説明する。

まず、処理要求がファイルの作成要求の場合を説明する。図１６は、ファイルの作成要求の受付処理のフローチャートである。

ステップＳ１６０１で、受付プログラム１１０は、ファイルの処理要求として作成要求を受け付けると、対象ファイルについて、容量推測処理を行う。容量推定処理については、後述する。

ステップＳ１６０３で、受付プログラム１１０は、作成したファイルをレプリケーションリストに登録し処理を終了する。ここで、レプリケーションリストは、作成されたファイルであってレプリケーションの対象となるファイルの一覧である。当該ファイルのレプリケーションが行われた後、当該ファイルはレプリケーションリストから削除される。

上記処理により、ファイルストレージシステム２のサブディレクトリにファイルを作成するときに、対象ファイルのアーカイブファイルを作成した場合のＮＳの使用量を、ファイルサーバ装置１０が推測することができる。

次に、処理要求がリード又はライト要求の場合を説明する。図８は、ファイルのリード又はライト要求の受付処理のフローチャートの前半部である。図９は、ファイルのリード又はライト要求の受付処理のフローチャートの後半部である。

ステップＳ８０１で、受付プログラム１１０は、ファイルの処理要求を受け付けると、その処理要求の対象となるファイルを特定する。このフローチャートの説明においては、このファイルを対象ファイルいう。そして、受付プログラムは、ｉｎｏｄｅ管理テーブル６００を参照し、対象ファイルのスタブ化フラグをチェックする。スタブ化フラグが「ＯＮ」であれば（Ｓ８０１：Ｙｅｓ）、受付プログラム１１０は、ステップＳ８０３に処理を進める。スタブ化フラグが「ＯＦＦ」であれば（Ｓ８０１：Ｎｏ）、受付プログラム１１０は、ステップＳ８３１に処理を進める（図９の１へ）。

ステップＳ８０３で、受付プログラム１１０は、受信した処理要求をチェックする。処理要求がリード要求の場合（Ｓ８０３：read）、受付プログラム１１０は、ステップＳ８０５に処理を進める。処理要求がライト要求の場合（Ｓ８０３：write）、受付プログラム１１０は、ステップＳ８１３に処理を進める。

ステップＳ８０５で、受付プログラム１１０は、対象ファイルのメタデータの中のブロックアドレスが有効か否かをチェックする。ブロックアドレスが有効な場合（Ｓ８０５：Ｙｅｓ）、受付プログラム１１０は、対象ファイルをＬＵ１１４から読み出し、読み出したファイルを要求元（ホスト１２）へ送信し、ステップＳ８１１へ処理を進める。

一方、ブロックアドレスが有効でない場合（Ｓ８０５：Ｎｏ）、受付プログラム１１０は、ファイルのリコールを行う。つまり、受付プログラム１１０は、ローカルムーバ１０６に対し、アーカイブシステム３から対象ファイルを取得するための取得要求のイベントを発行し、その要求に基づいてアーカイブサーバ装置２０から取得されたファイルを要求元へ送信するとともに、対象ファイルをＬＵ１１４に格納する。

ステップＳ８１１で、受付プログラム１１０は、ｉｎｏｄｅ管理テーブル６００について、対象ファイルの最終アクセス日時を更新し、処理を終了する。

ステップＳ８１３で、受付プログラム１１０は、ファイルのリコール、つまり、ローカルムーバ１０６に対し、対象ファイルの取得要求のイベントを発行し、アーカイブシステム３から対象ファイルを取得する。

ステップＳ８１７で、受付プログラム１１０は、対象ファイルについて容量推測処理を行う。容量推測処理については、後述する。なお、この処理では、同期状態のファイルが上書きされることになるので、ファイルの再編集操作が行われることとなる。

ステップＳ８１９で、受付プログラム１１０は、対象ファイルについて、ｉｎｏｄｅ管理テーブル６００のスタブ化フラグをＯＦＦにし、レプリケーションフラグをＯＦＦにする。

ステップＳ８２１で、受付プログラムは、Ｓ８１３で取得した対象ファイルを同期リストに登録し処理を終了する。ここで、同期リストは、更新されたファイルであって同期処理の対象となるファイルの一覧である。当該ファイルの同期処理が行われた後、当該ファイルは同期リストから削除される。

続いて、図９を説明する。ステップＳ８３１で、受付プログラム１１０は、受信した処理要求をチェックする。処理要求がリード要求の場合（Ｓ８３１：ｒｅａｄ）、受付プログラム１１０は、対象ファイルをＬＵ１１４から読み出して要求元（ホスト１２）へ送信する（Ｓ８３３）。そして、Ｓ８４７で、受付プログラム１１０は、対象ファイルについて、ｉｎｏｄｅ管理テーブル６００の最終アクセス日時を更新し、処理を終了する。

一方、処理要求がライト要求の場合（Ｓ８３１：ｗｒｉｔｅ）、ステップＳ８３５で、受付プログラム１１０は、対象ファイルのレプリケーション済フラグを確認する。レプリケーション済フラグがＯＮの場合（Ｓ８３５：Ｙｅｓ）、ステップＳ８３７で、受付プログラム１１０は、対象ファイルを同期リストに追加する。

ステップＳ８４１で、受付プログラム１１０は、対象ファイルについて、容量推測処理を行う。容量推測処理については、後述する。なお、この処理では、同期状態のファイルが上書きされることになるので、ファイルの編集操作が行われることとなる。

ステップＳ８４５で、受付プログラム１１０は、ｉｎｏｄｅ管理テーブル６００の対象ファイルのレプリケーション済フラグをＯＦＦにし、処理を終了する。

一方、レプリケーション済フラグがＯＦＦの場合（Ｓ８３５：Ｎｏ）、ステップＳ８３９で、受付プログラム１１０は容量推測処理を行い、処理を終了する。なお、この処理では、同期状態にないファイルが上書きされることになるので、ファイルの再編集操作が行われることとなる。

上記処理により、対象ファイルのアーカイブファイルが、対象ファイルが格納されるサブツリーに対応するＮＳに格納される場合のＮＳの使用量を、ファイルストレージシステム２に対象ファイルを書き込むときに、ファイルサーバ装置１０が推測することができる。
ここで、前述したように、ファイル管理情報とアーカイブ管理情報とは、異なる情報であり、サイズが異なることがある。そのため、同じファイルを格納した場合でも、ファイルサーバ装置１０に格納した場合と、アーカイブサーバ装置２０に格納した場合と、ではそれぞれの使用容量が異なることがある。また、後述のように、ファイルを更新した際等のファイルの管理方式も、ファイルサーバ装置１０とアーカイブサーバ装置２０とでは異なる。そのため、ファイルサーバ装置１０での使用容量を算出するのではなく、アーカイブ管理情報のサイズやアーカイブサーバ装置２０での管理方式に基づいて、ファイルサーバ装置１０がアーカイブサーバ装置２０での使用容量を推測することにより、より正確にアーカイブサーバ装置２０の使用容量を把握することができる。

図１０は、ファイルの作成要求及びライト要求時の容量推測処理のフローチャートである。
この容量推測処理は、ファイルの作成要求及びライト要求の時の受付処理内で（Ｓ１６０１Ｓ８１７、Ｓ８４１及びＳ８３９）行われる。

ステップＳ１００１で、受付プログラム１１０は、サブツリー情報管理テーブル３００について、対象ファイルが格納されるサブツリー連携ビットが「１」であるか否かを判断する。連携ビットが「０」の場合（Ｓ１００１：Ｎｏ）、受付プログラム１１０は、ステップＳ１０１１で、対象ファイルの作成、編集、又は再編集を実行し、ｉｎｏｄｅ管理テーブル６００を更新し、処理を終了する。ファイルの作成の場合、受付プログラム１１０は、ｉｎｏｄｅ管理テーブル６００に対象ファイルのエントリを追加し、各項目を登録する。ファイル編集又は再編集の場合、受付プログラム１１０は、例えば、ｉｎｏｄｅ管理テーブル６００のファイルのサイズ、最終アクセス日時などを更新する。

ステップＳ１００３で、受付プログラム１１０は、ファイル操作後の対象ファイルのアーカイブファイルである対象アーカイブファイルをＮＳに格納したと仮定した場合のＮＳの使用量を推測する。つまり、受付プログラム１１０は、使用量推測テーブル４００のＡ１、Ａ２、又はＡ３を参照し、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５となりうる値を算出する。

ステップＳ１００５で、受付プログラム１１０は、サブツリー情報管理テーブル３００を参照し、推測されたＮＳの使用量がＮＳ Ｑｕｏｔａ推測値３１３以下であるか否かを判定する。判定の結果、推測されたＮＳの使用量がＮＳ Ｑｕｏｔａ推測値３１３を超える場合（Ｓ１００５：Ｎｏ）、アーカイブが不可能であることを意味するので、受付プログラム１１０は、ホスト１２にエラー応答を送信し、処理を終了する。

一方、判定の結果、推測されたＮＳの使用量がＮＳ Ｑｕｏｔａ値（３０９又は３１３）以下の場合（Ｓ１００５：Ｙｅｓ）、アーカイブが可能であることを意味するので、受付プログラム１１０は、処理要求に従って対象ファイルをＬＵ１１４へ書き込み、ｉｎｏｄｅ管理テーブル６００を更新する（Ｓ１００７）。ファイルの作成の場合、受付プログラム１１０は、ｉｎｏｄｅ管理テーブル６００に対象ファイルのエントリを追加し、各項目を登録する。ファイル編集又は再編集の場合、受付プログラム１１０は、例えば、ｉｎｏｄｅ管理テーブル６００のファイルのサイズ、最終アクセス日時などを更新する。

ステップＳ１００９で、受付プログラム１１０は、推測されたＮＳの使用量により、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５を更新する。

上記処理により、ファイルサーバ装置１０が、対象アーカイブファイルをアーカイブシステム３に格納したときのＮＳの使用量を推測し、対象アーカイブファイルをＮＳに書き込めるか否かを判定できる。これにより、対象アーカイブファイルをＮＳに格納できない場合は、対象ファイルをファイルストレージシステム２に格納せずに、ホストにエラー応答することができる。

次に、処理要求がファイルの削除要求の場合を説明する。図１１は、ファイルの削除要求の受付処理のフローチャートである。

ステップＳ１１０１で、受付プログラム１１０は、ファイルの処理要求としての削除要求を受け付けると、その処理要求の対象となるファイルを特定する。このフローチャートの説明においては、このファイルを対象ファイルいう。そして、受付プログラムは、ｉｎｏｄｅ管理テーブル６００を参照し、対象ファイルのスタブ化フラグをチェックする。スタブ化フラグが「ＯＦＦ」であれば（Ｓ１１０１：Ｎｏ）、受付プログラム１１０は、ステップＳ１１１１に処理を進める。スタブ化フラグが「ＯＮ」であれば（Ｓ１１０１：Ｙｅｓ）、受付プログラム１１０は、ステップＳ１１０５に処理を進める。

ステップＳ１１１１で、受付プログラム１１０は、ｉｎｏｄｅ管理テーブル６００の対象ファイルのレプリケーションフラグがＯＮか否かを判定する。レプリケーションフラグがＯＮの場合（Ｓ１１１１：Ｙｅｓ）、受付プログラム１１０は、ステップＳ１１０５に処理を進める。レプリケーションフラグがＯＦＦの場合、（Ｓ１１１１：Ｎｏ）、受付プログラム１１０は、ステップＳ１１０７に処理を進める。

ステップＳ１１０５で、受付プログラム１１０は、アーカイブサーバ装置２０に対し、対象ファイルのアーカイブファイルの削除を指示する。そして、受付プログラム１１０は、ファイルの削除操作に伴う容量推測処理を行い、処理を終了する。容量推測処理については、後述する。なお、この処理においてファイルが削除される場合、ファイルの削除操作となる。また、アーカイブサーバ装置２０は、Ｓ１１０５の削除指示を受信したときに、アーカイブファイルの削除処理を実行し、削除処理完了を受付プログラム１１０に応答してよい。

上記処理により、ファイルストレージシステム２のサブディレクトリに対応づけられる対象ファイルを削除する際に、対象ファイルのアーカイブファイルを削除した場合のＮＳの使用量を、ファイルサーバ装置１０が推測することができる。

なお、上記のＳ１１０５では、受付プログラム１１０が対象ファイルのアーカイブファイルの削除指示をしていたが、これに限られない。例えば、受付プログラム１１０は、対象ファイルのアーカイブファイルを、削除候補のアーカイブファイルとしてリストに追加し、所定のタイミングにおいて、そのリストを元にアーカイブサーバ装置２０に削除指示を送信してもよい。

図１２は、ファイルの削除要求時の容量推測処理のフローチャートである。

この容量推測処理は、ファイルの削除要求時の受付処理内で（Ｓ１１０７）行われる。

ステップＳ１２０１で、受付プログラム１１０は、サブツリー情報管理テーブル３００について、対象ファイルが格納されるサブツリー連携ビットが「１」であるか否かを判断する。連携ビットが「０」の場合（Ｓ１２０１：Ｎｏ）、受付プログラム１１０は、ステップＳ１２０９で、ＬＵ１１４に格納された対象ファイルを削除し、ｉｎｏｄｅ管理テーブル６００の対象ファイルのｉｎｏｄｅ（エントリ）を削除し、処理を終了する。

ステップＳ１２０３で、受付プログラム１１０は、対象ファイルのアーカイブファイルである対象アーカイブファイルを削除した場合のＮＳの使用量を推測する。つまり、受付プログラム１１０は、使用量推測テーブル４００のＡ４を参照し、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５となる値を算出する。

ステップＳ１２０５で、受付プログラム１１０は、ＬＵ１１４に格納された対象ファイルを削除し、ｉｎｏｄｅ管理テーブル６００の対象ファイルのｉｎｏｄｅ（エントリ）を削除する。

ステップＳ１２０７で、受付プログラム１１０は、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５を更新する。

上記処理により、ファイルサーバ装置１０が、対象アーカイブファイルをアーカイブシステム３から削除したときのＮＳの使用量を推測できる。

図１３は、データムーバ処理のフローチャートの前半部である。図１４は、データムーバ処理のフローチャートの後半部である。データムーバ処理は、ファイルサーバ装置１０のＣＰＵ１０１が、メモリ１２０に記憶されたローカルムーバ１０６を実行することよって行われる。この処理は、イベントが発生することにより起動される、イベント駆動型の処理である。また、レプリケーション及び同期のイベントは、定期的又はホスト１２からの指示等により発生するものとする。

ステップＳ１３０１で、ローカルムーバ１０６は、予め設定された複数のイベントのうちいずれかのイベントが発生したかを確認し、イベントの発生を判定する（Ｓ１３０３）。イベントが発生していない場合（Ｓ１３０３：Ｎｏ）、ローカルムーバ１０６は、Ｓ１３０１へ処理を戻す。イベントが発生した場合（Ｓ１３０３：ＹＥＳ）、ローカルムーバ１０６は、Ｓ１３０５で、一定時間が経過したというイベントが発生したのか判定する。

一定時間の経過を知らせるイベントが発生した場合（Ｓ１３０５：ＹＥＳ）、ローカルムーバ１０６は、ステップＳ１３２１で、ファイルシステムに格納される各サブツリーの空き容量をチェックする。なお、空き容量は、Ｑｕｏｔａ値３０３から使用量３０５を減じた値である。

空き容量が閾値未満のサブツリーがない場合（Ｓ１３２３：Ｎｏ）（図中、Ａ）、ローカルムーバ１０６は、ステップＳ１３０１に処理を戻す。

空き容量が閾値未満のサブツリーがある場合（Ｓ１３２３：Ｙｅｓ）、ローカルムーバ１０６は、その（それらの）サブツリーの空き容量が閾値以上になるまで、その（それらの）サブツリーに格納されるファイルを選択する。

ステップＳ１３２７で、ローカルムーバ１０６は、選択したファイルのデータをＬＵ１１４から削除し、ｉｎｏｄｅ管理テーブル６００の、対象ファイルのスタブ化フラグをＯＮにするとともに、ブロックアドレスの値を削除する。そして、ローカルムーバ１０６は、Ｓ１３０１に処理を戻す（図中、Ａ）。

ステップＳ１３０７で、ローカルムーバ１０６は、発生したイベントがレプリケーション要求であるか否かを判定する。イベントがレプリケーション要求でない場合（Ｓ１３０７：Ｎｏ）（図中、Ｂ）、ローカルムーバ１０６は、ステップＳ１４０１に処理を進める（図１４参照）。

イベントがレプリケーション要求の場合（Ｓ１３０７：Ｙｅｓ）、ステップＳ１３０９で、ローカルムーバ１０６は、アーカイブサーバ装置２０からレプリケーション対象ファイルのアーカイブファイルの格納先を取得する。

ステップＳ１３１１で、ローカルムーバ１０６は、ｉｎｏｄｅ管理テーブル６００のリンク先にアーカイブファイルの格納先を設定する。

ステップＳ１３１３で、ローカルムーバ１０６は、レプリケーションリストに登録されたファイルであるレプリケーション対象ファイルをＬＵ１１４から取得する。具体的には、例えば、ローカルムーバ１０６は、レプリケーション対象ファイルのリード要求を、受付プログラム１１０に送信する。

ステップＳ１３１５で、ローカルムーバ１０６は、取得したレプリケーション対象ファイルをアーカイブサーバ装置２０に転送し、その後、レプリケーション対象ファイルをアーカイブした後のＮＳの使用量の取得を指示する。

ステップＳ１３１７で、ローカルムーバ１０６は、誤差補正処理を行う。誤差補正処理については、後述する。

ステップＳ１３１９で、ローカルムーバ１０６は、ｉｎｏｄｅ管理テーブル６００のレプリケーション対象ファイルのレプリケーション済フラグをＯＮにし、レプリケーションリストの内容を削除し、Ｓ１３０１に処理を戻す（図中、Ａ）。

続いて図１４を説明する。ステップＳ１４０１で、ローカルムーバ１０６は、イベントがファイルの同期要求であるか否かを判定する。イベントが同期要求でない場合（Ｓ１４０１：Ｎｏ）、ローカルムーバ１０６は、ステップＳ１４１１に処理を進める。

イベントが同期要求の場合（Ｓ１４０１：Ｙｅｓ）、ステップＳ１４０３で、ローカルムーバ１０６は、ｉｎｏｄｅ管理テーブル６００から、同期リストに登録されたファイルである同期対象ファイルのアーカイブファイルの格納先を取得する。

ステップＳ１４０４で、ローカルムーバ１０６は、同期対象ファイルをＬＵ１１４から取得する。そして、ステップＳ１４０５で、ローカルムーバ１０６は、取得した同期対象ファイルをアーカイブサーバ装置２０に転送し、同期対象ファイルをアーカイブした後のＮＳの使用量の取得を指示する。

ステップＳ１４０７で、ローカルムーバ１０６は、ローカルムーバ１０６は、誤差補正処理を行う。誤差補正処理については、後述する。

ステップＳ１４０９で、ローカルムーバ１０６は、同期リストの内容を削除し、Ｓ１３０１に処理を戻す（図中、Ａ）。

ステップＳ１４１１で、ローカルムーバ１０６は、イベントがリコール要求であるか否かを判定する。イベントがリコール要求でない場合（Ｓ１４１１：Ｎｏ）、ローカルムーバ１０６は、Ｓ１３０１に処理を戻す（図中、Ａ）。

イベントがリコール要求の場合（Ｓ１４１１：Ｙｅｓ）、ステップＳ１４１３で、ローカルムーバ１０６は、アーカイブサーバ装置２０からリコール対象ファイルのアーカイブファイルのデータを取得し、要求元（受付プログラム１１０）に送信し、処理を終了する。

上記処理により、対象ファイルのレプリケーション又は同期に伴って、ＮＳ推測使用量３１５の誤差を補正できる。

図１５は、誤差補正処理のフローチャートである。

誤差補正処理は、データムーバ処理のステップＳ１３１７又はステップＳ１４０７の処理である。

ステップＳ１５０１で、ローカルムーバ１０６は、サブツリー情報管理テーブル３００について、対象ファイルが格納されるサブツリー連携ビットが「１」であるか否かを判断する。

連携ビットが「０」の場合（Ｓ１５０１：Ｎｏ）、ローカルムーバ１０６は、処理を終了する。一方、連携ビットが「１」の場合（Ｓ１５０３：Ｎｏ）、ローカルムーバ１０６は、ステップＳ１３１５で取得したＮＳの使用量に基づき、サブツリー情報管理テーブル３００のＮＳ取得使用量３１１を更新する。そして、ローカルムーバ１０６は、ＮＳ取得使用量３１１の値に基づき、ＮＳ推測使用量３１５の値を修正する。なお、このとき、ローカルムーバ１０６は、ＮＳのＱｕｏｔａ値を取得して、サブツリー情報管理テーブル３００のＮＳＱｕｏｔａ取得値３０９及びＮＳＱｕｏｔａ推測値３１３を更新してもよい。

上記処理により、アーカイブサーバ装置２０から、対象ファイルが格納されるサブツリーに対応するＮＳの実際の使用量を取得することができる。これにより、ローカルムーバ１０６は、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５の誤差を補正できることで、次に、この（対象ファイルが格納される）サブツリーに格納されるファイルにファイル操作を行う場合に、ＮＳの使用量の推測値の誤差が大きくなるのを抑制できる。

なお、本実施例では、この処理は、データムーバ処理のステップＳ１３１７又はステップＳ１４０７の処理として行われていたが、これに限られない。例えば、ファイルサーバ装置１０が、ＮＳのＱｕｏｔａ値を変更する場合に行われてもよいし、ホスト１２からＮＳの使用量を取得する旨の指示を受信したときに行われてもよい。

なお、アーカイブシステム３が世代管理を行う場合、ＮＳの使用量は、複数の世代を含むアーカイブファイルのサイズを含んでもよいし、最新の世代のアーカイブファイルのサイズのみを含んでもよい。

なお、本実施例では、ファイルの作成要求、ライト要求、削除要求時の容量推測処理を、フローチャートを用いて説明したが、これに限られない。例えば、前述のメタデータ変更要求時においても、サブツリー情報管理テーブル３００の連携ビットが「０」のときに容量推測処理が行われてよい。この場合、ファイルサーバ装置１０は、使用量推測テーブル４００のＡ５を参照し、ファイル管理情報（例えばｉｎｏｄｅ管理テーブル６００）に基づくアーカイブファイル管理情報が変更された場合のＮＳの使用量を推定（算出）する。具体的には、そして、ファイルサーバ装置１０は、サブツリー情報管理テーブル３００を参照し、推定されたＮＳの使用量がＮＳ Ｑｕｏｔａ推測値３１３以下であるか否かを判定する。ファイルサーバ装置１０は、推定されたＮＳの使用量がＮＳ Ｑｕｏｔａ推測値３１３を超える場合、ホスト１２にエラー応答をする。一方、ファイルサーバ装置１０は、推定されたＮＳの使用量がＮＳ Ｑｕｏｔａ値以下の場合、ｉｎｏｄｅ管理テーブル６００を更新し、このＮＳの使用量を、サブツリー情報管理テーブル３００のＮＳ推測使用量３１５に登録する。

上記処理により、ファイルサーバ装置１０が、ファイルストレージシステム２側のメタデータを変更したことによりアーカイブシステム３側のメタデータが変更された場合のＮＳの使用量を推測し、メタデータの変更が可能か否かを判定できる。これにより、アーカイブシステム３側のメタデータを変更できない場合には、ファイルストレージシステム２側のメタデータを変更せずに、ホストにエラー応答することができる。
以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

なお、プロセッサは、ＣＰＵ１０１などに対応し、記憶装置は、ＲＡＩＤシステム１１などに対応し、アーカイブ記憶装置は、ＲＡＩＤシステム２１などに対応する。また、アーカイブは、レプリケーション及び同期を含む概念としてよい。また、アーカイブシステムの記憶領域の容量は、ＮＳ Ｑｕｏｔａ取得値３０９又はＮＳ Ｑｕｏｔａ推測値３１３などに対応し、アーカイブシステムの記憶領域の使用容量は、ＮＳ取得使用量３１１及びＮＳ推測使用量３１５を含む。また、算出した使用容量は、ＮＳ推測使用量３１５などに対応し、取得した使用容量は、ＮＳ取得使用量３１１などに対応する。

２ファイルストレージシステム ３アーカイブシステム １０ファイルサーバ装置 １０７ファイルシステム １０８サブツリー ２０６ネームスペース

Claims (10)

1. ホスト計算機と、ファイルのデータを格納する記憶装置と、前記記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、
   前記記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、前記プログラムを実行するプロセッサと、を有し、
   前記プロセッサは、
   前記アーカイブシステムの記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
   前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出し、
   前記アーカイブシステムの記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定し、
   アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とするファイルサーバ装置。
2. 請求項１に記載のファイルサーバ装置であって、
   前記プロセッサは、
   アーカイブが可能と判定した場合、前記記憶領域の使用容量の値を、前記算出した使用容量の値に置き換え、
   前記記憶装置に前記書込み要求にかかるファイルのデータを格納する、
   ファイルサーバ装置。
3. 請求項２に記載のファイルサーバ装置であって、
   前記プロセッサは、
   所定の契機で前記アーカイブシステムから前記アーカイブシステムの前記記憶領域の使用容量を取得し、
   前記記憶領域の使用容量の値を、前記取得した使用容量の値に置き換える、
   ファイルサーバ装置。
4. 請求項３に記載のファイルサーバ装置であって、
   前記所定の契機とは、前記記憶装置に格納されたファイルのデータを前記アーカイブシステムに送信した後である、
   ファイルサーバ装置。
5. 請求項１に記載のファイルサーバ装置であって、
   前記プロセッサは、
   前記書込み要求が、前記書込み要求にかかるファイルの作成要求か編集要求かによって、異なる方法で、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
   ファイルサーバ装置。
6. 請求項１に記載のファイルサーバ装置であって、
   前記書込み要求にかかるファイルは、実データと管理情報とを含み、
   前記書込み要求にかかるファイルは、前記アーカイブシステムにアーカイブされると、前記実データとアーカイブ管理情報とを含むアーカイブファイルとして格納され、
   前記プロセッサは、
   前記書込み要求が作成要求の場合、前記記憶領域の使用容量と、前記実データの容量と、前記アーカイブ管理情報の容量と、に基づいて、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
   ファイルサーバ装置。
7. 請求項６に記載のファイルサーバであって、
   前記プロセッサは、
   前記書込み要求が更新要求の場合、前記書込み要求にかかるファイルの更新前の容量と更新後の容量との差分容量を算出し、
   前記記憶領域の使用容量と、前記差分容量と、に基づいて、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
   ファイルサーバ装置。
8. 請求項１に記載のファイルサーバ装置であって、
   前記アーカイブシステムの記憶領域の容量は、前記ホスト計算機を使用するユーザごとに設定された容量である、
   ファイルサーバ装置。
9. ホスト計算機と、ファイルのデータを格納する記憶装置と、前記記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、
   前記記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、前記プログラムを実行するプロセッサと、を有するファイルサーバ装置の制御方法であって、
   前記アーカイブシステムの記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
   前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出し、
   前記アーカイブシステムの記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定し、
   アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とする制御方法。
10. ホスト計算機と接続され、前記ホスト計算機からファイルへのアクセス要求を受信するファイルサーバ装置と、
    前記ファイルサーバ装置に接続され、前記ファイルサーバ装置に送信されたファイルのデータを格納する記憶装置と、
    前記ファイルサーバ装置に接続され、前記記憶装置に格納されたファイルのデータのアーカイブ要求を前記ファイルサーバ装置から受信するアーカイブサーバ装置と、
    前記アーカイブサーバ装置と接続され、前記アーカイブサーバ装置に送信されたファイルのデータを格納するアーカイブ記憶装置と、
    を備える計算機システムであって、
    前記ファイルサーバ装置は、
    前記アーカイブ記憶装置の記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
    前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブ記憶装置の前記記憶領域の使用容量を算出し、
    前記アーカイブ記憶装置の記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブサーバ装置にアーカイブ可能か判定し、
    アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とする計算機システム。
    
    

Images