JP5180865B2 - ファイルサーバ、ファイル管理システムおよびファイル管理方法 - Google Patents

Description

本発明は、ストレージ装置にて作成されるファイルシステムを仮想化することによりファイルを管理する技術に関する。

ファイルシステムを管理するファイルサーバ（ＮＡＳ（Network Attached Storage）装置）と、ファイルシステムのファイルを格納する１以上のストレージ装置とを有するファイル管理システムを使用したファイルサービスのニーズが近年急速に高まっている。それに伴い、ストレージ装置に格納されるファイルの容量が増加し、ストレージ装置を構成するディスクデバイスの台数も増加の傾向にある。ディスクデバイスの台数が増加すると、ストレージ装置全体の消費電力も増加することになる。特に多数のディスクデバイスを搭載し、複数のディスクデバイスでＲＡＩＤ（Redundant Array of Inexpensive Disks）を構成している大容量のディスクアレイシステムでは、ストレージ装置全体の消費電力増加が課題となっている。

特許文献１には、ファイルシステムを作成した論理ボリュームに対応するＨＤＤ（Hard Disk Drive）がスピンダウン中であってもファイル属性の参照を可能とするために、スピンダウン前にキャッシュ上にメタデータを格納し、そのメタデータの参照を契機として論理ボリュームのスピンアップを行うことで、アクセス応答速度の劣化を防止するとともに、省電力化を実現する旨が開示されている。

特開２００７−８６８４３号公報

しかし、特許文献１の技術を以ってしても、ユーザがあるファイルシステムによって管理される複数のファイルのうち１つでもアクセスしている場合には、そのファイルシステムが作成される論理ボリュームに対応するＨＤＤのスピンダウンができない。つまり、ファイルへのアクセスが継続する環境では省電力化を期待することができない。

そこで、本発明では、ファイルへのアクセスが継続する環境であっても省電力化を実現することを目的とする。

前記目的を達成するために、本発明のファイル管理システムは、ファイルのアクセス状況を解析し、ファイルへのアクセスがなされる代表的な時間帯を特定する。ここで、アクセスがなされる時間帯を特定することは、アクセスがなされない時間帯も特定されることを意味する。そして、その特定された時間帯にアクセスされないことが見込まれる１以上のファイルを１つのグループとして扱い、そのグループに含まれるファイルと、スピンダウンして論理ボリューム（以下、単に、「ボリューム」または「ＬＵ（Logical Unit）」と称する場合がある。）の稼働を停止する停止時間帯が決められているＲＡＩＤグループとの対応付けを行う。この対応付けに従って、ある時刻にスピンダウンを行うことになっているＲＡＩＤグループに格納されているファイルは、必要であれば、スピンアップして稼動中の別のＲＡＩＤグループに移行する。

従って、元々は停止中であったはずのＲＡＩＤグループに格納されていたファイルに対するユーザからのアクセスが当該停止時間帯中になされたとしても、そのファイルはすでに稼働中のＲＡＩＤグループに格納されているので、ユーザのアクセスは継続されるとともに、停止しようとするＲＡＩＤグループは予定通りにスピンダウンすることができる。前記したように１つだけのファイルにアクセスがあったためにスピンダウンすることができない、といった事態も起こらない。このようにして、スピンダウンする時間帯を増やして省電力化を実現する。

なお、ファイルサーバによって管理されるファイルシステムには、複数の実ファイルシステムを仮想的に統合したファイルシステムを使用する。ファイルサーバは、ファイルシステムの仮想化によって、ユーザに対し１以上の論理ボリュームに作成された１以上の実ファイルシステムは見せず、実ファイルシステムを仮想的に統合した統合ファイルシステム（仮想ファイルシステム）を見せている。従って、ファイルの移行がなされ、そのファイルが格納されている実ファイルシステムが変わったとしても、統合ファイルシステムしか見えないユーザはそのことを意識せずにファイルのアクセスを実行できる。詳細は後記する。

本発明によれば、ファイルへのアクセスが継続する環境であっても省電力化を実現することができる。

本発明が適用されるファイル管理システムの構成例を示す図である。 本実施形態に係るＨＳＭ機能を使用した場合のファイルシステムツリー構造を示す図である。 ファイルシステムの構造の一例を示す図である。 ディレクトリエントリのデータ構造の一例を示す図である。 ｉノードとデータブロックの参照関係を示す図である。 ｉノードテーブルのデータ構造の一例を示す図である。 サーバのソフトウェア構成を示す図である。 ファイルシステムの階層の管理情報である階層管理テーブルを示す図である。 階層データリストの基本データ構造を示す図である。 基本データ構造に基づく、利用中の仮想ファイルシステムを構成する実ファイルシステムをリストとして管理する階層データリストのデータ構造を示す図である。 マッピングテーブルのデータ構造を示す図である。 スケジュールテーブルのデータ構造を示す図である。 グルーピングテーブルのデータ構造を示す図である。 アクセス解析テーブルのデータ構造を示す図である。 アクセス要求受付処理の様子が描かれたファイル管理システムの構成例を示す図である。 アクセス監視処理の様子が描かれたファイル管理システムの構成例を示す図である。 ファイル移行処理の様子が描かれたファイル管理システムの構成例を示す図である。 ファイルのグループ化およびそのグループの変更の様子を示す図である。 ファイルのグループ化およびそのグループの変更の様子を示す図である。 ファイルのグループ化およびそのグループの変更の様子を示す図である。 ファイルのグループ化およびそのグループの変更の様子を示す図である。 スピンダウンまたはスピンアップそのものに要する時間を考慮したファイルアクセスの様子を示す図である。 スピンダウンまたはスピンアップそのものに要する時間を考慮したファイルアクセスの様子を示す図である。 スピンダウン／アップ処理の様子が描かれたファイル管理システムの構成例を示す図である。 ファイルアクセスプログラム、ファイルアクセス情報収集プログラム、マイグレーションプログラム、スピンダウン／アッププログラムにより実行される処理全体のフローを示す図である。 ファイルアクセスプログラムにより実行される処理のフローを示す図である。 ファイルアクセス情報収集プログラムにより実行される処理のフローを示す図である。 マイグレーションプログラムにより実行される処理のフローを示す図である。 スピンダウン／アッププログラムにより実行される処理のフローを示す図である。

以下、本発明を実施するための形態について、図面に基づいて詳細に説明する。なお、これにより本発明が限定されるものではない。
（実施形態１）
図１は、本発明が適用されるファイル管理システムの構成例を示す図である。階層管理ファイルシステムは、サーバ１００１（ファイルサーバ）と、サーバ１００１に接続されたＲＡＩＤ（Redundant Arrays of Independent Disks）装置１０１４（記憶装置）、管理端末１０２０、クライアント１０３０を有する。サーバ１００１とＲＡＩＤ装置１０１４は、例えばＳＡＮ（Storage Area Network）で接続されている。また、管理端末１０２０、クライアント１０３０、およびサーバ１００１は、例えばＬＡＮ（Local Area Network）で接続されている。なお、管理端末１０２０は、クライアント１０３０と同等のコンピュータとみなす場合がある。

サーバ１００１は、メモリ（記憶部）１００８に格納されたプログラムを実行するＣＰＵ（Central Processing Unit：制御部）１００２、ＲＡＩＤ装置１０１４との通信に使用するディスクアダプタ１００３、管理端末１０２０やクライアント１０３０との通信に利用するネットワークアダプタ１００４、プログラムやデータを格納するメモリ１００８を搭載し、それらは内部的な通信路（例えば、バス）によって接続されている計算機である。なお、サーバ１００１がディスクアダプタ１００３を使用してＲＡＩＤ装置１０１４と接続するときは、ＦＣパスを経由し、ＦＣパスは稼働中のＲＡＩＤグループに振り分けられる。

サーバ１００１のメモリ１００８には、プログラムやデータが格納される。具体的には、メモリ１００８には、管理コマンド１００５、階層管理ファイルシステムプログラム１００６、実ファイルシステムプログラム１００７、オペレーティングシステム１００９、管理情報１０１０、ファイルアクセスプログラム３００１、ファイルアクセス情報収集プログラム３００２、マイグレーションプログラム３００３、スピンダウン／アッププログラム３００４が格納される。

管理コマンド１００５は、サーバ１００１が提供するＨＳＭ（Hierarchical Storage Management：階層ストレージ管理）機能を管理するコマンドである。階層管理ファイルシステムプログラム１００６は、ファイルシステムの階層化を実現し、サーバ１００１が提供するＨＳＭ機能の中心となるプログラムである。実ファイルシステムプログラム１００７は、ＲＡＩＤ装置１０１４のＦＣ（Fiber Channel）ディスクドライブ１０１２、ＳＡＴＡ（Serial Advanced Technology Attachment）ディスクドライブ１０１３のファイルシステムであるＦＳ Ａ（１０１５）、ＦＳ Ｂ（１０１６）を管理するプログラムである。なお、ＦＳはFile System（ファイルシステム）の略である。オペレーティングシステム１００９は、サーバ１００１全体を管理するプログラムである。オペレーティングシステム１００９は、後述するＶＦＳ（Virtual File System：仮想ファイルシステム）プログラム３０００を内部に有する。

ファイルアクセスプログラム３００１は、管理端末１０２０から端末プログラムの接続を受け付けたり、クライアント１０３０のファイルアクセス要求プログラム１０３１からファイルアクセス要求（説明の便宜上、単に、「アクセス要求」と称する場合がある。）を受け取ったりするサーバプログラムである。管理情報１０１０は、ＨＳＭ機能を提供するための管理データである。これらのプログラムやデータの詳細は後記する。ただ、管理情報１０１０に含まれる各種テーブル１００００とは、後記する階層管理テーブル４０００、マッピングテーブル６０００、スケジュールテーブル７０００、グルーピングテーブル８０００、アクセス解析テーブル９０００を含むテーブルの総称である。サーバ１００１でなされる処理によってこれらのテーブルがメモリ１００８の記憶領域で一時的に作成され、作成されたテーブルはＲＡＩＤ装置１０１４に保存される。

階層管理ファイルシステムプログラム１００６は、主に、階層管理参加処理、階層管理離脱処理、管理情報再構築処理、階層移動処理、Ｌｏｏｋｕｐ処理、Ｃｒｅａｔ処理、Ｍｋｄｉｒ処理、Ｒｅａｄｄｉｒ処理を行う。

ファイルアクセス情報収集プログラム３００２は、管理端末１０２０またはクライアント１０３０からのファイルアクセスを監視し、そのファイルアクセスの詳細を示すファイルアクセス情報をファイルごとに収集するサーバプログラムである。
マイグレーションプログラム３００３は、ＲＡＩＤ装置１０１４のあるボリューム（またはＲＡＩＤグループ）に格納されているファイルを別のボリューム（またはＲＡＩＤグループ）に移行するサーバプログラムである。
スピンダウン／アッププログラム３００４は、ＲＡＩＤ装置１０１４に作成されたＲＡＩＤグループのスピンダウン（ハードディスクのプラッタの回転速度を規定値まで下げること）またはスピンアップ（ハードディスクのプラッタの回転速度を規定値まで上げること）を行うサーバプログラムである。
なお、これらのプログラムを格納した記録媒体を製造し、サーバ１００１がその記録媒体から前記プログラムを読み込み、前記した処理を実行しても良い。
なお、ＲＡＩＤグループのスピンアップとは、ＲＡＩＤグループに含まれるハードディスクの状態をＲｅａｄ要求またはＷｒｉｔｅ要求を処理可能な状態まで遷移させる処理を指しても良い。また、ＲＡＩＤグループのスピンダウンとは、ＲＡＩＤグループに含まれるハードディスクの状態をスピンアップ後の電力消費量から低い消費電力状態に遷移する処理であれば、ハードディスクの回転速度を規定値まで下げる以外の状態遷移であっても良い。以後、ハードディスクの状態として、Ｒｅａｄ要求またはＷｒｉｔｅ要求を処理可能な状態またはハードディスクのプラッタの回転速度を規定値まで上げた状態をスピンアップ状態（または通常状態）と呼び、上記通常状態より消費電力の低い状態またはハードディスクのプラッタの回転速度を規定値まで下げた状態をスピンダウン状態（または省電力状態）と呼ぶことがある。

ＲＡＩＤ装置１０１４は、ＲＡＩＤ装置１０１４がサーバ１００１へ提供するボリュームを制御するディスク制御装置１０１１と、サーバ１００１へ提供する１以上のボリュームを作成するＦＣディスクドライブ１０１２ａ（１０１２），１０１２ｂ（１０１２）と、ＳＡＴＡディスクドライブ１０１３とを有する。ＦＣディスクドライブ１０１２ａには、後記する階層管理テーブル４０００（ファイルシステム階層管理情報）、マッピングテーブル６０００（マッピング情報）、スケジュールテーブル７０００（スケジュール情報）、グルーピングテーブル８０００、アクセス解析テーブル９０００（アクセス情報）を格納するＦＳＭファイルシステム１０１７を格納する。ディスク制御装置１０１１と、ＦＣディスクドライブ１０１２と、ＳＡＴＡディスクドライブ１０１３と、ＦＳＭファイルシステム１０１７とは、内部的な通信路で接続されている。なお、ＦＳＭは、File System Managementの略である。

なお、ＦＣディスクドライブ１０１２とＳＡＴＡディスクドライブ１０１３には、性能差がある。例えば、ＦＣディスクドライブ１０１２はＳＡＴＡディスクドライブ１０１３に比べて性能が良い。さらに、ＦＣディスクドライブ１０１２の代わりにＳＡＳ（Serial Attached SCSI）ドライブを用いても良い。

このように複数種類のディスクドライブを使い分ける理由としては、日々の技術進歩によってより安価に大容量のディスクドライブ（例えばＳＡＴＡディスクドライブ）が流通し、またそれと同時に、高価であるが高性能なディスクドライブ（例えば、ＦＣディスクドライブや、ＳＡＳディスクドライブや、フラッシュメモリを用いたＳＳＤ（Solid State Disk））が流通しているため、コスト、容量、信頼性、性能等に関する項目から少なくとも二つ以上の条件を満たす必要がでてきたためである。

なお、ディスクドライブは、ＦＣディスクドライブ１０１２やＳＡＴＡディスクドライブ１０１３だけでなく、ＣＤ（Compact Disc）やＭＯ（Magneto-Optical）ディスク、ＤＶＤ（登録商標）等の光学メディア等でも良く、ファイルシステムが作成できるストレージ装置であれば、本発明は適用できる。さらに、ディスクドライブだけでなく、ファイルシステムとして認識できれば本発明は適用することができる。また、ＮＦＳ（Network File System）やＣＩＦＳ（Common Internet File System）といったファイル共有プロトコルのファイルシステムも、本発明は適用でき、クライアント１０３０に対するファイル共有環境が実現される。

なお、ディスクドライブに関する性能差として考えられるのは、最大転送速度や、最大ＩＯＰＳ（Input/Output operations Per Second）等が第一に考えられるが、これらの値を価格や消費電力の少なくともいずれかで割った値を考えても良い。また、性能差以外の特徴値について差異（例えば、コスト、容量、信頼性）を考慮して複数種類のディスクドライブを使い分けても良い。また、当該特徴値としてはディスクドライブを製造するベンダが提供するカタログ値を元に判断することが考えられるが、個々のディスクドライブに実際にアクセスを行うことで特徴値を把握しても良い。以後、明細書では性能を例として説明を行うが、本発明は性能以外の特徴値を元としたディスクドライブの併用にも有効である。

ＦＳ Ａ（１０１５）はＦＣディスクドライブ１０１２に作成される。また、ＦＳ Ｂ（１０１６）はＳＡＴＡディスクドライブ１０１３に作成される。ファイルシステムは、クライアント１０３０のユーザが作成したデータをファイル形式で保持する。以降、これらのファイルシステムを実ファイルシステムと呼ぶ場合がある。これは、後述するように、本発明が「仮想」ファイルシステムを作成するため、ボリューム上に作成される「本当の」ファイルシステムという意味である。

なお、本実施形態では、ＦＣディスクドライブ１０１２ａに作成される１以上のボリュームを１つのＲＡＩＤグループとして扱い、「Ｒｇｒｏｕｐ−Ａ」と称する。また、ＳＡＴＡディスクドライブ１０１３に作成される１以上のボリュームを１つのＲＡＩＤグループとして扱い、「Ｒｇｒｏｕｐ−Ｂ」と称する。また、実ファイルシステムと仮想ファイルシステムとを対応付ける役割を果たすＦＣディスクドライブ１０１２ｂに作成される１以上のボリュームも１つのＲＡＩＤグループとして扱う。

ＦＣディスクドライブ１０１２ｂおよびＳＡＴＡディスクドライブ１０１３に作成されるボリューム（ＬＵ）には、クライアント１０３０からアクセス要求のあるファイルが格納される。ＦＳ Ａ（１０１５）、ＦＳ Ｂ（１０１６）により使用される記憶領域には、これらのＬＵが割り当てられる。これらのボリュームに格納されるファイルは、ユーザが業務目的に使用するものである。
また、ＦＣディスクドライブ１０１２ａに作成されるボリュームには、サーバ１００１が処理を実行するためのプログラムやテーブル（４０００、６０００等）が格納され、ユーザが使用するファイルは格納されない。従って、ユーザがこのボリュームを使用することは通常無い。

管理端末１０２０は、サーバ１００１を管理する管理者が使用する計算機である。管理者は、管理端末１０２０からネットワークを通して、サーバ１００１の管理コマンド１００５を使用する。クライアント１０３０は、サーバ１００１が提供するファイル共有サービスを利用する計算機である。クライアントを利用するユーザは、ファイルアクセス要求プログラム１０３１を通してサーバ１００１のファイル共有サービスを利用する。

なお、以後の説明で用いる用語の意味は、以下に示す。
（Ａ）「ファイル」：クライアント１０３０またはサーバ１００１が生成したデータを格納する論理的な存在。
（Ｂ）「ディレクトリ」：ファイルやディレクトリを集約して管理する論理的な単位。
（Ｃ）「ディレクトリ名」：ディレクトリに付与される名前。
（Ｄ）「パス」または「パス名」：ファイルまたはディレクトリを識別する識別情報。
（Ｅ）「ファイル名」：ファイルに付与される名前。なお、以後の説明ではファイル名にパス名が含まれることがある。

図２は、本実施形態に係るＨＳＭ機能を使用した場合のファイルシステムツリー構造を示す図である。ファイルシステムツリーは、サーバ１００１が構築し、クライアント１０３０へ提供しているファイルシステム名前空間である。

ファイルシステムツリー２０００は、「／（ルート）」と、ルートの下の「ＥＸＰＯＲＴ」と「Ｔｉｅｒ１」と「Ｔｉｅｒ２」で構成されている。ＦＳ Ａ（１０１５）は、Ｔｉｅｒ１にマウントされ、ＦＳ Ｂ（１０１６）はＴｉｅｒ２にマウントされている。本実施形態のＨＳＭ機能は、Ｔｉｅｒ１とＴｉｅｒ２をＥＸＰＯＲＴディレクトリへ重ねる。このとき、ファイルシステムスタック構造２００２のように、ＦＳ Ａ（１０１５）を上にＦＳ Ｂ（１０１６）を下に配置して、仮想ファイルシステム２００１を作成する。

本実施形態は、ＥＸＰＯＲＴ以下をクライアント１０３０が使用する。クライアント１０３０のユーザがファイルを作成すると、つまり、ファイルの作成要求をサーバ１００１に送信すると、ＦＳ Ａ（１０１５）にファイルが作成される。そして、そのファイルの利用頻度が低下すると、そのファイルをＦＳ Ｂ（１０１６）へ移動する。こうすることで、利用頻度の低いファイルが高速ボリュームから低速ボリュームへ移動する。なお、利用頻度が低下したファイルは、サーバ１００１の利用者が特定してもよく、サーバ１００１に予め設定された所定のルールに基づき特定してもよく、またその他の方法で特定しても良い。

ＨＳＭ機能が仮想ファイルシステム２００１を構成するときに、ＦＳ Ａ（１０１５）とＦＳ Ｂ（１０１６）に同名のファイルがあった場合、ＦＳ Ａ（１０１５）のファイルが仮想ファイルシステム２００１に登録される。その結果、ＦＳ Ｂ（１０１６）にある同名のファイルはクライアント１０３０へ提供されない。これは、ファイルシステムスタック構造２００２で示すように、ＦＳ Ａ（１０１５）がＦＳ Ｂ（１０１６）を覆うように配置されるためである。なお、ＦＳ Ｂ（１０１６）がＦＳ Ａ（１０１５）を覆うように配置されるファイルスタック構造となっても良い。

なお、ファイルシステム統合の対象となったＦＳ Ａ（１０１５）とＦＳ Ｂ（１０１６）は、クライアント１０３０への提供を停止しても良い。以上に示した方法により、管理者は使用中のファイルシステムを自由に統合できる。

ここで、ファイルシステムについて詳細に説明する。ファイルシステム（以下、「ＦＳ」と称する場合がある。）とは、ボリューム上にファイルという管理単位を実現するために構築された論理構造をいう。なお、このような論理構造は、例えばテーブルやキューであっても良い。

図３は、ファイルシステムの構造の一例を示す図である。ＦＳは、スーパーブロック（ファイル管理情報）３０１、ディレクトリエントリ（ファイル名−ファイル属性情報対応情報）３０２、ｉノードテーブル（ファイル属性情報管理情報）３０３、データブロック（Ｉ／Ｏ最小単位）３０４等を含んで構成されている。

スーパーブロック３０１とは、ＦＳの情報を一括保持している領域である。一括保持する情報としては、例えばＦＳの大きさ、ＦＳの空き容量等がある。

ディレクトリエントリ３０２とは、ファイル名とファイルの属性とを対応付けて管理するエントリである。これにより、ＦＳにおいて１つのファイルに１つのｉノード（ファイル属性情報）を対応させることができる。
図４は、ディレクトリエントリのデータ構造の一例を示す図である。図４で示すように、ディレクトリエントリ３０２は、ディレクトリパス名４０１とｉノードを指すインデックスであるｉノード番号４０２を組にしたテーブルである。ＦＳは、このディレクトリエントリのｉノード番号（またはｉｎｏｄｅ番号と表記する場合もある。）を用いてｉノードにアクセスする。ファイルシステムプログラム（例えば、実ファイルシステムプログラム１００７）は当該ｉノードエントリを参照することでファイル名（またはディレクトリパス名）からｉノード番号を取得する。なお、ディレクトリエントリはデータブロック中に分散して存在しても良い。

なお、ｉノードとは、ｉノード番号、ファイルの所有権、アクセス権、ファイルサイズ、データの格納位置（データブロックアドレス（または、ポインタ））を含む各種情報（属性）を保持する領域をいう。
図５は、ｉノードとデータブロックの参照関係を示す図である。後記するｉノードテーブル３０３に登録された情報に従うようにして、データブロック中の網掛け部分のブロック（データの格納位置を示す）内のデータがアクセス権の範囲内で参照される。

ｉノードテーブル３０３とは、ｉノードを格納するテーブルである。
図６は、ｉノードテーブルのデータ構造の一例を示す図である。図６で示すように、ｉノードテーブル３０３は、ｉノード番号６０１、所有者６０２、アクセス権６０３、サイズ６０４、データブロックアドレス１、２、３・・・（６０５ａ、６０５ｂ、６０５ｃ・・・）を組にしたテーブルである。

データブロック３０４とは、実際のファイルや管理データ等が格納されるブロックである。
以上で、ファイルシステムの説明を終える。

図７は、サーバのソフトウェア構成を示す図である。サーバ１００１のソフトウェア構成は、ファイルアクセスプログラム３００１、管理コマンド１００５、ＶＦＳプログラム３０００、階層管理ファイルシステムプログラム１００６、実ファイルシステムプログラム１００７から構成される。

管理コマンド１００５と、クライアント１０３０からのファイルアクセス要求を受信したファイル共有サーバプログラム等のファイルアクセスプログラム３００１とは、オペレーティングシステム１００９の一部であるＶＦＳプログラム３０００にアクセスを要求する。ＶＦＳプログラム３０００は、実ファイルシステムプログラム１００７や階層管理ファイルシステムプログラム１００６のアクセスインタフェースを仮想化し、管理コマンド１００５やファイルアクセスプログラム３００１に提供する機能を持つプログラムである。

階層管理ファイルシステムプログラム１００６は、ＶＦＳプログラム３０００を通してファイルアクセスプログラム３００１や管理コマンド１００５からアクセス要求を受け取る。また、階層管理ファイルシステムプログラム１００６は、実ファイルシステムプログラム１００７（例えば、ＦＳ Ａ（１０１５）、ＦＳ Ｂ（１０１６））へアクセスを要求する。一方、実ファイルシステムプログラム１００７は、ＶＦＳプログラム３０００から直接アクセス要求を受け取る場合もある。このように、ＶＦＳプログラム３０００は、ファイルアクセスプログラム３００１とファイルシステムプログラム（階層管理ファイルシステムプログラム１００６および実ファイルシステムプログラム１００７）の仲介を行うオペレーティングシステムを構成するソフトウェアである。

なお、サーバ１００１にて動作するファイルアクセスプログラム３００１や管理コマンド１００５はカーネルの一部として動作してもよく、カーネルとは別な、より保護された実行環境である一般プログラムとして動作しても良い。
ここで、カーネルとは、ＮＡＳ（つまり、サーバ１００１）上で動作する複数のプログラム（プロセス）のスケジュール制御やハードウェアからの割り込みをハンドリングする等し、ＮＡＳの全般的な制御を実施するソフトウェアであり、ＯＳ（Operating System）の基本機能を実装する。

ファイルアクセスプログラム３００１が、クライアント１０３０から受信する要求（ファイルアクセス要求）には、例えば以下の種類がある。なお、下記説明ではＮＦＳとＣＩＦＳにおける例示をしているが、これ以外のコマンドが含まれてもよく、また他のコマンドで代替しても良い。

（Ａ）ファイルまたはディレクトリのパス名から、以下（Ｂ）〜（Ｈ）のファイルまたはディレクトリに対する参照および操作のために必要な識別子（以後、ファイルハンドル識別子と呼ぶ。）を取得するｌｏｏｋｕｐ要求。ＮＦＳプロトコルの場合は、例えば、パス名を指定するＬｏｏｋｕｐコマンドがある。ｌｏｏｋｕｐ要求がなされると、階層管理ファイルシステムプログラム１００６は、Ｌｏｏｋｕｐ処理を実行する。

（Ｂ）指定したディレクトリに指定したファイル名でファイルを生成するｃｒｅａｔ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したディレクトリのファイルハンドル識別子と、ファイル名を引数とするＣｒｅａｔｅコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ディレクトリ名とファイル名を引数としたＳＭＢ＿ＣＯＭ＿ＣＲＥＡＴＥコマンドがある。ｃｒｅａｔ要求がなされると、階層管理ファイルシステムプログラム１００６は、Ｃｒｅａｔ処理を実行する。

（Ｃ）指定したディレクトリ配下に新規ディレクトリを生成するｍｋｄｉｒ要求（新規ディレクトリのディレクトリ名も指定する）。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したディレクトリのファイルハンドル識別子と、新規ディレクトリの名前を引数としたＭｋｄｉｒコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ディレクトリ名と新規ディレクトリ名を引数としたＳＭＢ＿ＣＯＭ＿ＣＲＥＡＴＥ＿ＤＩＲＥＣＴＯＲＹコマンドがある。ｍｋｄｉｒ要求がなされると、階層管理ファイルシステムプログラム１００６は、Ｍｋｄｉｒ処理を実行する。

（Ｄ）指定したディレクトリ配下に存在する１つ以上のファイルまたはディレクトリについてのファイル名やディレクトリ名をクライアント１０３０へ送信するｒｅａｄｄｉｒ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したディレクトリのファイルハンドル識別子を引数とするＲｅａｄｄｉｒコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ディレクトリ名を引数としたＳＭＢ＿ＣＯＭ＿ＴＲＡＮＳＡＣＴＩＯＮ２：ＴＲＡＮＳ２＿ＱＵＥＲＹ＿ＰＡＴＨ＿ＩＮＦＯＲＭＡＴＩＯＮコマンドがある。ｒｅａｄｄｉｒ要求がなされると、階層管理ファイルシステムプログラム１００６は、Ｒｅａｄｄｉｒ処理を実行する。

（Ｅ）指定したファイルを読み書きするための準備処理をサーバ１００１に依頼するｏｐｅｎ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したファイルのファイルハンドル識別子を引数とするｏｐｅｎコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ファイル名（パス名込み）を引数とするＳＭＢ＿ＣＯＭ＿ＯＰＥＮがある。なお、ＣＩＦＳプロトコルの場合は、ＳＭＢ＿ＣＯＭ＿ＯＰＥＮの応答情報としてファイルのｒｅａｄまたはｗｒｉｔｅ処理を行うための識別子（以後、ｏｐｅｎ識別子と呼ぶ。）をクライアント１０３０に送信する。

（Ｆ）ｏｐｅｎ要求で準備したファイルのデータを読み込むｒｅａｄ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したファイルのファイルハンドル識別子を引数とするｒｅａｄコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ｏｐｅｎ識別子を引数とするＳＭＢ＿ＣＯＭ＿ＲＥＡＤコマンドがある。

（Ｇ）ｏｐｅｎ要求で準備したファイルのデータを書き込むｗｒｉｔｅ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したファイルのファイルハンドル識別子を引数とするｗｒｉｔｅコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ｏｐｅｎ識別子を引数とするＳＭＢ＿ＣＯＭ＿ＷＲＩＴＥコマンドがある。

（Ｈ）ｏｐｅｎ要求で行った準備を終了するｃｌｏｓｅ要求。ＮＦＳプロトコルの場合は、例えば、ｌｏｏｋｕｐ要求で取得したファイルのファイルハンドル識別子を引数とするｃｌｏｓｅコマンドがある。ＣＩＦＳプロトコルの場合は、例えば、ｏｐｅｎ識別子を引数とするＳＭＢ＿ＣＯＭ＿ＣＬＯＳＥコマンドがある。

なお、各要求にディレクトリまたはファイルを指定する場合は、ディレクトリ名やファイル名を引数として各要求に付随させる以外に、サーバ１００１がディレクトリまたはファイルを特定することが可能な情報をサーバ１００１が受信さえ可能であれば、どのような形態の情報であっても良い。

また、サーバ１００１がボリュームに格納し管理するファイルには、サーバ１００１自体が用いるものやセキュリティの理由から複数のクライアント１０３０から特定のクライアントに対してのみ読み書きを許可したい場合もある。こうした要求に対応するため、サーバ１００１のファイルアクセスプログラム３００１は、エクスポートと呼ばれる機能を有する。エクスポート機能は、サーバ１００１が論理ボリュームに定義したファイルシステムの所定のディレクトリ（以後、エクスポートディレクトリ）配下のディレクトリおよびファイル（別な言い方では、ディレクトリ空間）を所定のクライアント１０３０（エクスポート先クライアント）にのみ提供する機能である。この場合、前述の所定のクライアント１０３０に対しては前述の所定のディレクトリ配下のディレクトリおよびファイルがトップディレクトリに存在するようディレクトリ空間を変換している。

例えば、配下に「ｈｏｍｅｗｏｒｋ．ｔｘｔ」ファイルを有する「ｗｏｒｋ」ディレクトリと「ｄｉａｒｙ．ｔｘｔ」ファイルとを有する「／ｈｏｍｅ／ｕｓｅｒ１」ディレクトリをサーバ１００１が管理している場合、「／ｈｏｍｅ／ｕｓｅｒ１」をエクスポートディレクトリと指定し、複数のクライアントからｆｏｏの名前を有するクライアントを指定した場合は、ｆｏｏクライアントからはサーバが提供するディレクトリ空間のルートディレクトリ直下に「ｗｏｒｋ」ディレクトリと「ｄｉａｒｙ．ｔｘｔ」が存在するように見える。

図８は、ファイルシステムの階層の管理情報である階層管理テーブルを示す図である。階層管理テーブル４０００は、管理情報１０１０の一部である。管理者が管理コマンド１００５を使用して仮想ファイルシステムを作成する際、階層管理ファイルシステムプログラム１００６が「仮想の」ファイルシステムと「実」ファイルシステムとの対応を管理するための情報である階層管理テーブル４０００を作成する。階層管理テーブル４０００は、ファイルシステム（例えば、ＦＳ Ａ（１０１５）、ＦＳ Ｂ（１０１６））のマウント位置を示すマウントパス４００１と、ファイルシステムの管理ＩＤ（Identifier）であるＦＳＩＤ４００２、ファイルシステムの階層を示す階層４００３が１つのレコードとして構成されている。

階層管理ファイルシステムプログラム１００６は、ファイルシステムがマウントされるパス情報を完全パス名でマウントパス４００１へ記録する。完全パス名とは、／（ルート）から始まるパスで、例えば、図８に示すように「／ＥＸＰＯＲＴ」等が該当する。

また、ＦＳＩＤ（４００２）は、管理者が実ファイルシステムをマウントするときに設定した値を記録する。以降に記述されるＦＳＩＤは管理者が設定した値を用いる。

また、階層管理ファイルシステムプログラム１００６は、階層４００３の特定の値を、階層以外の用途に使用する。例えば、階層４００３が０ｘ００に設定されている場合、管理コマンド１００５と階層管理ファイルシステムプログラム１００６は、その階層を仮想ファイルシステム２００１（図２参照）であると認識する。

さらに、管理コマンド１００５は、階層４００３を０ｘ０１（１０進数で１）から始めるのではなく、０ｘ０Ｆ（１０進数で１６）から２番おきに採番する。こうすることで、最高の階層の上に、さらに階層を追加することが容易になる。また、階層間に階層を追加することも容易となる。ただし、この採番方法については一例であり、本実施形態が採番方法について特に限定するものではない。

図９は、階層データリストの基本データ構造を示す図である。図１０は、基本データ構造に基づく、利用中の仮想ファイルシステムを構成する実ファイルシステムをリストとして管理する階層データリストのデータ構造を示す図である。階層データリスト５０００は、管理情報１０１０の一部である。図９に示すように、階層データリスト５０００の基本データ構造は、マウント中のパスを示すマウントパス５００１と、ファイルシステムのＩＤを示すＦＳＩＤ（５００２）と、ポインタ５００３で構成される。なお、図８で示した階層管理テーブル４０００は、恒久的なものであるのに対して、図９および図１０に示す階層データリスト５０００は、運用中（動作中）の一時的なものである点で異なっている。

具体的には、図１０に示す階層データリスト５０００は、仮想ファイルシステム２００１（／ＥＸＰＯＲＴ）を先頭にした階層構造を示している。例えば、管理者の指示により、「／Ｔｉｅｒ１」が外される（階層から離脱する）場合、階層管理テーブル４０００は変更されない。しかし、階層データリスト５０００は変更される。階層管理ファイルシステムプログラム１００６は、階層データリスト５０００のうち、「／ＥＸＰＯＲＴ」のポインタを書き換え、「／Ｔｉｅｒ２」を指すように変更する。そして、「／Ｔｉｅｒ１」のデータを破棄する。このようにすることで、階層管理ファイルシステムプログラム１００６は、恒久的な階層構成情報と一時的な階層構成情報を効率よく管理できる。

次に管理コマンド１００５について説明する。
（階層管理への参加コマンド）
（Ａ１）式および（Ｂ１）式は、管理者が実ファイルシステムを仮想ファイルシステム２００１へ統合する（実ファイルシステムを階層管理へ参加させる）際に入力するコマンドの一例を示す。（Ａ１）式は、ｍｏｕｎｔコマンドの書式であり、（Ｂ１）式は、具体例を示している。
mount -t hmfs -o T=<Tier>,D=<TARGET> <SRC> <SRC> …（Ａ１）
mount -t hmfs -o T=1,D=/EXPORT /Tier1 /Tier1 …（Ｂ１）

管理者は、管理端末１０２０の端末プログラムを利用して、サーバ１００１のファイル要求受信プログラム（端末サーバプログラム）３００１へ接続し、サーバ１００１へログインする。そして、管理者は、実ファイルシステムを階層管理へ参加させるため、管理コマンド１００５を実行する。

（Ａ１）式において、管理者は、マウントコマンドの「−ｔ」オプションにより、階層管理ファイルシステムを利用することを指定する。そして、管理者は、「−ｏ」オプションにより、階層管理ファイルシステムプログラム１００６のオプションを指定する。階層管理ファイルシステムプログラム１００６のオプションのうち、階層管理への参加処理で使用するオプションは「Ｔ」と「Ｄ」である。Ｔオプションは、実ファイルシステムの階層を示し、Ｄオプションは、仮想ファイルシステム２００１のパスを示す。そして、「ＳＲＣ」に、実ファイルシステムがマウントされているファイルシステムのパスを指定する。具体的には、ＦＳ Ａ（１０１５）が階層管理へ参加する場合（図２参照）、（Ｂ１）式に示すように、「／Ｔｉｅｒ１」を指定する。
このようにして、階層管理への参加コマンドが入力されると、階層管理ファイルシステムプログラム１００６は、階層管理参加処理を実行する。

（管理情報再構築コマンド）
（Ａ２）式および（Ｂ２）式は、マッピングテーブル６０００が壊れたときに再構築するためのコマンドの一例を示す。（Ａ２）式は、管理情報の再構築で使用するｍｏｕｎｔコマンドの書式であり、（Ｂ２）式は、具体例を示している。
mount -t hmfs -o I=<Tier DB>,D=<TARGET> hmfs hmfs …（Ａ２）
mount -t hmfs -o I=/HMDB,D=/EXPORT hmfs hmfs …（Ｂ２）

管理者は、管理端末１０２０の端末プログラムを利用して、サーバ１００１のファイル要求受信プログラム（端末サーバプログラム）３００１へ接続し、サーバ１００１へログインする。そして、管理者は、実ファイルシステムを階層管理へ参加させるため、管理コマンド１００５を実行する。

（Ａ２）式において、−ｔオプションは、階層管理への参加と同様に、階層管理ファイルシステムプログラム１００６を利用することを示す。管理情報の再構築では、−ｏオプションで指定する、階層管理ファイルシステムプログラム１００６のオプションが異なる。管理者は、Ｉオプションにマッピングテーブル６０００が格納されているファイルシステムパスを指定する。また、管理者は、Ｄオプションに仮想ファイルシステム２００１のパスを指定する。図２を例にすると、具体的には、（Ｂ２）式に示すように、管理者は／に格納しているＨＭＤＢファイルを再構築することを指示している。
このようにして、管理情報再構築コマンドが入力されると、階層管理ファイルシステムプログラム１００６は、管理情報再構築処理を実行する。

（階層管理からの離脱コマンド）
（Ａ３）式および（Ｂ３）式は、管理者が指定するファイルシステムを階層管理から外す際に入力するコマンドの一例を示す。（Ａ３）式は、階層管理から外す（階層管理から離脱）処理の書式であり、（Ｂ３）式は、具体例を示している。
umount <SRC> …（Ａ３）
umount /Tier1 …（Ｂ３）

管理者は、管理端末１０２０の端末プログラムを利用して、サーバ１００１のファイル要求受信プログラム（端末サーバプログラム）３００１へ接続し、サーバ１００１へログインする。そして、管理者は、実ファイルシステムを階層管理へ参加させるため、管理コマンド１００５を実行する。

管理者は、ｕｍｏｕｎｔコマンドを使用して、階層管理からファイルシステムを外すことができる。（Ａ３）式において、ｕｍｏｕｎｔコマンドに、実ファイルシステムがマウントされたファイルシステムパスを指定する。図２を例にすると、具体的には、（Ｂ３）式に示すように、管理者は、／Ｔｉｅｒ１にマウントされたファイルシステムを階層管理から外すことを、階層管理ファイルシステムプログラム１００６へ指示している。
このようにして、階層管理からの離脱コマンドが入力されると、階層管理ファイルシステムプログラム１００６は、階層管理離脱処理を実行する。

（階層の移動コマンド）
（Ａ４）式および（Ｂ４）式は、管理者やクライアント１０３０を利用するユーザが、ファイルの階層を移動させる際に入力するコマンドの一例を示す。（Ａ４）式は、階層の移動処理の書式であり、（Ｂ４）式は、具体例を示している。
mv_tier -t 2 <FILE> …（Ａ４）
mv_tier -t 2 FILE1 …（Ｂ４）

管理者は、管理端末１０２０の端末プログラムを利用して、サーバ１００１のファイル要求受信プログラム（端末サーバプログラム）３００１へ接続し、サーバ１００１へログインする。そして、管理者は、実ファイルシステムを階層管理へ参加させるため、管理コマンド１００５を実行する。

（Ａ４）式において、−ｔオプションは、移動先の階層を指定する。具体的には、（Ｂ４）式に示すように、／Ｔｉｅｒ１に格納されているＦＩＬＥ１は、本コマンドを実行することで、／Ｔｉｅｒ２へ移動することになる。
このようにして、階層の移動コマンドが入力されると、階層管理ファイルシステムプログラム１００６は、階層移動処理を実行する。

図１１は、マッピングテーブルのデータ構造を示す図である。マッピングテーブル６０００は、管理情報１０１０の一部であり、仮想ファイルシステムと実ファイルシステムとをマッピングすることにより、ファイルが格納されている実ファイルシステム情報を示す。マッピングテーブル６０００は、仮想ファイルシステムのファイル名をファイルパスとして示すファイルパス名６００１、仮想ファイルシステムのｉｎｏｄｅ番号を示す仮想ファイルシステム用ｉｎｏｄｅ番号６００２、当該ファイルが格納されているＲＡＩＤグループを示すＲＡＩＤグループ名６００３、当該ファイルを管理する実ファイルシステムを示すファイルシステム名６００４（図８のＦＳＩＤ（４００２）と同義）、その実ファイルシステムのｉｎｏｄｅ番号を示すファイルシステム用ｉｎｏｄｅ番号６００５で構成される。

マッピングテーブル６０００は、１レコードに１つのファイルを対応付けている。ＶＦＳプログラム３０００は、仮想ファイルシステム２００１の完全ファイルパスをファイルパス名６００１に記録する。ファイルパス名６００１に記録するファイル名は、階層管理するファイルシステム（実ファイルシステムのこと。図２の場合、ＦＳ Ａ（１０１５）やＦＳ Ｂ（１０１６）をいう。）が保持しているファイルパスと同じである。例えば、図２のＦＳ Ａ（１０１５）に「/home/user001/a.txt」というファイルがある場合は、ＶＦＳプログラム３０００は、ファイルパス名６００１に「/home/user001/a.txt」と記録する。一方、「/home/user002/b.txt」というファイルがある場合は、ＶＦＳプログラム３０００は、ファイルパス名６００１に「/home/user002/b.txt」と記録する。

クライアント１０３０を利用するユーザは、ファイル名６００１を指定して、ファイルへアクセスする。その際、ユーザから見ると仮想ファイルシステムにアクセスしているように見えるが、実際はＶＦＳプログラム３０００（または階層管理ファイルシステムプログラム１００６）が、ファイルパス名６００１に対応するレコードを特定し、実ファイルシステムプログラム１００７へのアクセスに切り替える。そして、実ファイルシステムプログラム１００７によって対応する実ファイルシステム上のファイルへのアクセスが実現される。なお、本実施形態では、管理情報再構築処理により、マッピングテーブル６０００が失われても再構築することができるため、高い可用性を実現できる。

なお、ＲＡＩＤグループが異なるボリューム間のファイルの移行があった場合、マッピングテーブル６０００において、ＲＡＩＤグループ名６００３、ファイルシステム名６００４、ファイルシステム用ｉｎｏｄｅ番号６００５に登録される値は当然変更するが、仮想ファイルシステムにおいてはその変化は現れないため、ファイルパス名６００１、仮想ファイルシステム用ｉｎｏｄｅ番号６００２に登録される値は変更しない。

図１２は、スケジュールテーブルのデータ構造を示す図である。スケジュールテーブル７０００は、管理情報１０１０の一部であり、サーバ１００１からアクセス可能なすべてのファイルシステムが属するＲＡＩＤグループのスピンアップ（起動）またはスピンダウン（停止）を行う時期を定めるスケジュール情報を登録する。スケジュールテーブル７０００は、起動または停止するＲＡＩＤグループを示すＲＡＩＤグループ名７００１、そのＲＡＩＤグループが停止する時間帯を示す停止時間帯７００２で構成される。停止時間帯は、例えば管理者が管理端末１０２０の入力手段から指定する。

図１３は、グルーピングテーブルのデータ構造を示す図である。グルーピングテーブル８０００は、管理情報１０１０の一部であり、ファイルのアクセス情報を集計することによりグループ化されたファイルのファイル情報を登録する。グルーピングテーブル８０００は、アクセス特性が共通するファイルをまとめるグループを示すグループ名８００１、そのグループに属するファイルを示すファイル名８００２で構成される。ファイル情報は、後記するアクセス解析テーブル９０００から定める。

図１４は、アクセス解析テーブルのデータ構造を示す図である。アクセス解析テーブル９０００は、管理情報１０１０の一部であり、クライアント１０３０からファイルアクセス要求がある度に、ファイルのアクセス情報を登録する。アクセス解析テーブル９０００は、アクセスがなされたファイルを示すファイル名９００１、そのファイルにアクセスしたユーザを示すユーザ９００２、そのアクセスがなされた日時を示すアクセス日時９００３で構成される。これらの他にアクセスの種類（例：read要求、write要求）を登録しても良い。ファイルアクセス要求には、アクセス対象となるファイルのファイル名、アクセスしようとするユーザ、ファイルアクセスがなされた日時（ファイルアクセス日時）が含まれている。このアクセス日時９００３には、ファイルアクセス日時として、特に、ファイルアクセスの開始日時、その終了日時、ファイルアクセスがなされた時間帯が登録されるようにしても良い。

ＲＡＩＤグループの停止時間帯は、アクセス解析テーブル９０００からファイルのアクセス情報を集計して、あるファイルへのアクセスがなされる代表的な時間帯を統計的に見積もり、その時間帯以外の時間帯を特定することにより決められる。
また、ファイルアクセスがなされる前には、ユーザはファイル管理システムの提供するファイルサービスを利用するためにログインをしており、ファイルアクセスがなされた後はそのユーザはログアウトしている。そこで、ユーザごとのログイン時からログアウト時までの代表的な時間帯を決定し、その決定した時間帯以外の時間帯を、ＲＡＩＤグループの停止時間帯とするようにしても良い。

次に、本実施形態で行う省電力化について説明する。
既に説明したとおり、ＲＡＩＤ装置１０１４において、１以上のＬＵから作成された１以上ファイルシステム（ＦＳ Ａ（１０１５）、ＦＳ Ｂ（１０１６））はサーバ１００１により一元管理される。サーバ１００１のＶＦＳプログラム３０００は、１以上のファイルシステムを仮想的に統合した仮想ファイルシステムを構築する。このＶＦＳプログラム３０００は、ファイルアクセスプログラム３００１、ファイルアクセス情報収集プログラム３００２、マイグレーションプログラム３００３、スピンダウン／アッププログラム３００４の実行により、後記する、アクセス要求受付処理、アクセス監視処理、ファイル移行処理、スピンダウン／アップ処理を、それぞれ実現する。

〔アクセス要求受付処理〕
図１５は、アクセス要求受付処理の様子が描かれたファイル管理システムの構成例を示す図である。説明の便宜上、図１の図面を簡略化してある。クライアント１０３０に対しては、各ＲＡＩＤグループにある個々のファイルシステムを見せず、仮想ファイルシステムを見せている。

クライアント１０３０は、/home/user001/a.txtというファイルに対してアクセス要求をする（図中（１）参照）。すると、ＶＦＳプログラム３０００を介して、ＲＡＩＤ装置１０１４にあるマッピングテーブル６０００から、/home/user001/a.txtというファイル名を検索キーとして、ＦＳ Ａ（１０１５）、実ファイルシステム用ｉｎｏｄｅ番号＝３００を特定する（図中（２）参照）。そして、特定したファイルシステム（ＦＳ Ａ（１０１５））に対してファイルアクセスし（図中（３）参照）、ファイル単位のアクセス処理（例：read処理、write処理）を実行する。

〔アクセス監視処理〕
図１６は、アクセス監視処理の様子が描かれたファイル管理システムの構成例を示す図である。説明の便宜上、図１の図面を簡略化してある。アクセス監視処理は、主に２つの独立した処理で構成されている。

第１の処理は、クライアント１０３０からのファイルアクセスがあったときに行う処理である。サーバ１００１は自身が管理するファイルシステムへのアクセス監視を行い、ファイル単位のアクセス情報をアクセス解析テーブルに格納する。例えば、fooというユーザから、/home/share/a.txtというファイルに対してread要求（アクセス属性の１つ）がなされる（図中（１）参照）と、ＶＦＳプログラム３０００を介してそのファイルが格納されているＲＡＩＤグループ（ここでは、このファイルがＦＳ Ｂ（１０１６）により管理されているので、Ｒｇｒｏｕｐ−Ｂであるとする。）から読み出される（図中（２）参照）。そして、このファイルアクセスのアクセス情報を書き出し（図中（３）参照）、アクセス解析テーブル９０００にそのアクセス情報を格納する。

第２の処理は、サーバ１００１において、クライアント１０３０からのファイルアクセスとは無関係に定期的になされる処理である。ＶＦＳプログラム３０００は、アクセス解析テーブル９０００を調べ、定期的に（適宜）アクセス解析を実行する（図中（４）参照）。具体的には、アクセス解析として、以前格納した古いアクセス情報を所定の条件の下で削除する。

前記条件としては、例えば、次の２つのようにするのが良い。
・ファイルアクセスのあった日時（アクセス日時９００３（図１４参照）から判定）が、設定された期限（１）より古い場合、無条件で削除する。
・ファイルアクセスのあった日時が、設定された期限（１）より新しく、期限（２）より古い場合において、アクセスユーザ数（ユーザ９００２（図１４参照）から判定）が所定値以上に多いファイルのアクセス情報については、段階的に削除し、アクセスユーザ数が所定値よりも少ないファイルのアクセス情報については、全削除する。

前記期限（１）および期限（２）は、メモリ１００８に記憶され、ファイルアクセス情報収集プログラム３００２により読み込まれる設定情報として定められる。設定情報は、例えば、次の２つのようにするのが良い。
（設定情報）
期限（１）：−１２５（現在日時より１２５日前であることを意味する）
期限（２）： −７５（現在日時より７５日前であることを意味する）
とすると良い。

このように定期的に処理することにより、次のような利点がある。まず、第１に、現状のアクセス状況を反映したスケジュールを作成することができる。過去のアクセス情報をいつまでも残しておくとスケジュールの決定に最新の状態がいつまでも反映されないからである。例えば、ファイルアクセスの時間帯が日々遅くなっていったとすると、スピンダウンの時間帯も遅くするようにすべきであるが、ファイルアクセスの時間帯が早い状態を示す過去のアクセス情報を反映させると、設定したスピンダウンの時間帯が早い側に設定されるようにスケジュールを作成してしまう。

第２に、アクセスユーザ数を用いることにより、スケジュールの作成に都合の良いアクセス情報を選び出すことができる。日時だけで判断してアクセス情報を削除してしまうと、変更前のスケジュールと変更後のスケジュールとの間に連続性がなくなってしまい、スケジュールと実際のファイルアクセスとの間に不整合が生じる。多少古いアクセス情報であったとしても、多くのユーザが利用するファイルのアクセス情報はスケジュールの作成において利用価値が高い。

〔ファイル移行処理〕
図１７は、ファイル移行処理の様子が描かれたファイル管理システムの構成例を示す図である。説明の便宜上、図１の図面を簡略化してある。アクセス監視処理により取得したアクセス情報を蓄積し、蓄積した結果からファイルアクセスの無い（または有る）時間帯を抽出し、スピンダウンのスケジュールおよび類似したアクセスパターンごとにファイルをグループ化（詳細は、後記）したファイル情報を生成する。抽出した時間帯に基づいてスケジュールテーブル７０００を生成し、ファイル情報に基づいてグルーピングテーブル８０００を生成する。

ファイルの移行を行うときには、各テーブル（６０００、７０００、８０００、９０００）が参照される（図中（１）参照）。参照した結果、ＶＦＳプログラム３０００は、ファイルシステムの仮想化におけるマッピングが最適か否かを判断する（図中（２）参照。詳細は、後記。）。そして、最適でなければ、最適になるように、マッピングテーブル６０００、スケジュールテーブル７０００、グルーピングテーブル８０００の更新をし（図中（３）参照）、ＲＡＩＤグループが停止していない時間帯にファイルを移行する（図中（４）参照）。

ファイルの移行の際、マッピングテーブル６０００において、当該ファイルについて、ＲＡＩＤグループ名６００３、ファイルシステム名６００４、実ファイルシステム用ｉｎｏｄｅ番号６００５の値を変更し、マッピングが変更されるため、移行によるファイルの格納位置の変更がユーザから隠蔽される。

ここで、ファイルのグループ化について詳細に説明する。
図１８、図１９、図２０、図２１はファイルのグループ化およびそのグループの変更の様子を示す図である。
グループ化をするときには、まず、アクセス解析テーブル９０００から当該ファイル（およびディレクトリ、ファイルシステム等）へのアクセス時刻を算出する。図１８において、ファイルごとに、ファイルアクセスのあった箇所は黒の帯で示されている。

次に、このアクセス時刻が現在のグルーピングテーブルとマッチしているか否かを判断する。図１９、図２０において、黒の帯の下側に描かれた細破線の枠（グループ属性）は、スケジュールテーブル７０００およびグルーピングテーブル８０００から求められるファイルごとの停止時間帯を反転したもの、つまり、ファイルアクセス可能時間帯を示す。図１９のように、アクセス時刻がグルーピングテーブルとマッチする場合、黒の帯が細破線の横幅に収まっていることがわかる。これは、実際になされたファイルアクセスは、決定したスケジュールのとおりになされているため、ファイルの移行を行う必要がないことを意味している。

一方、図２０のように、アクセス時刻がグルーピングテーブルとマッチしない場合、黒の帯が点線の横幅からはみ出していることがわかる（ＧｒｏｕｐＢ）。これは、実際になされたファイルアクセスは、決定したスケジュールのとおりになされていないため、ファイルのグループに対応付けられたＲＡＩＤグループの停止時間帯にファイルアクセスがなされることになり、基本的にはスピンダウンができず、ファイルの移行を行う必要があることを意味している。よって、スケジュールテーブル７０００およびグルーピングテーブル８０００から最適なファイルの移行を導出し、ファイルの移行を行う。

図２１において、ＧｒｏｕｐＢに属していたファイル「/home/share/z.ppt」は、ＧｒｏｕｐＡに対応付けられたＲＡＩＤグループのファイルアクセス可能時間帯（細破線）にマッチする（収まる）ので、当該ファイルのグループをＧｒｏｕｐＢからＧｒｏｕｐＡに変更する。これに伴い、マッピングテーブル６０００も変更する。

このようにファイルの移行の判断は、ファイルのアクセス時間帯がファイルアクセス可能時間帯とマッチするか否かということによるのであるが、換言すると、ＲＡＩＤグループの停止時間帯とファイルのアクセスのない時間帯とがファイルごとにマッチするか否かということによる。
また、ファイルの移行は、上記のようにファイルのグループを変更する代わりに、ファイルのグループはそのままにして、対応するＲＡＩＤグループのファイルアクセス可能時間帯を変更して、当該ファイルのアクセス時間帯を収めるようにしても良い。この場合は、所望する省電力化が達成される範囲内でファイルアクセス可能時間帯を変更することが好ましい。

なお、ファイルのグループ化において、スピンダウンまたはスピンアップそのものに要する時間を考慮する必要がある。
図２２、図２３は、スピンダウンまたはスピンアップそのものに要する時間を考慮したファイルアクセスの様子を示す図である。図２２に示すように、アクセスのない時間帯の時間がスピンダウンまたはスピンアップに要する時間（特に、ファイルの移行先となるＲＡＩＤグループで行うスピンダウンまたはスピンアップに掛かる時間）よりも短いと、短時間でのスピンダウンまたはスピンアップによる遅延によりアクセス可能な時間帯が減少し、微小な停止時間帯で、スピンダウンまたはスピンアップするとオーバーヘッドとなる。たとえアクセスのある時間帯であってもスピンダウンまたはスピンアップがなされるのであれば、その時間はアクセス不能時間といえる（図２２の太線）。

そこで、図２３に示すように、予め、スピンダウンまたはスピンアップに要する時間を計測し（計測した時間は、例えばメモリ１００８に格納されている。）、スピンダウンまたはスピンアップに要する時間よりも短い空白部分（アクセスのない時間帯）は、アクセスが発生しているものとみなして（図２３の破線）、アクセス時間帯をグループ化するのが良い。

従って、アクセス情報（ログ）を解析する際には、以下の手順を踏む必要がある。
（１）ログの読み込み
（２）抽出した空白時間帯が、スピンダウンまたはスピンアップに要する時間よりも短い場合は、ログを修正（穴埋め）
（３）修正したログを保存
（４）修正後のログで解析

〔スピンダウン／アップ処理〕
図２４は、スピンダウン／アップ処理の様子が描かれたファイル管理システムの構成例を示す図である。説明の便宜上、図１の図面を簡略化してある。スケジュールテーブル７０００に登録された、または更新されたスケジュールに基づいて、ＲＡＩＤグループのスピンダウンを実行する。

ＶＦＳプログラム３０００は、Ｒｇｒｏｕｐ−Ｂに対しスピンダウン要求をする（図中（１）参照）。スピンダウン中にユーザから、スピンダウンしたＲｇｒｏｕｐ−ＢのＬＵに格納されたファイルに対するファイルアクセスの要求があっても、そのファイルは既にスピンアップ中のＲｇｒｏｕｐ−ＡのＬＵに移行しており、そしてＲｇｒｏｕｐ−Ａおよびマッピングテーブル６０００が格納されているＲＡＩＤグループは稼働している。そのため、当該ファイルのアクセスを継続することが可能である。その一方でスピンダウンはきちんとなされているので省電力化は達成される。また、ユーザには仮想ファイルシステムしか見えないので、ファイルが移行していることに気づかない。なお、前記スケジュールに基づいて、ＲＡＩＤグループのスピンアップも実行する。

次に、ファイルアクセスプログラム３００１、ファイルアクセス情報収集プログラム３００２、マイグレーションプログラム３００３、スピンダウン／アッププログラム３００４により実行される処理について詳細に説明する。
図２５は、ファイルアクセスプログラム、ファイルアクセス情報収集プログラム、マイグレーションプログラム、スピンダウン／アッププログラムにより実行される処理全体のフローを示す図である。これらの処理の主体は、ＣＰＵ１００２であるが、説明の便宜上、各プログラムを中心にして説明する。

ファイルアクセスプログラム３００１は、ユーザからのread/write要求（説明の便宜上、ファイルアクセス要求としてread要求とwrite要求のみ採り上げるが、これらに限定しない。）を受けると、マッピングテーブル６０００を参照して、対象ファイルが格納されているＲＧ（ＲＡＩＤグループの意）を構成するＬＵにおいて、ファイルのread処理またはwrite処理（ファイルr/w）を実行する。

ファイルアクセス情報収集プログラム３００２は、ファイルアクセスプログラム３００１の実行した処理の結果である情報出力を読み込み、ファイルアクセス状況を分析する。そして、その分析の結果をアクセス解析テーブル９０００に登録して、更新する。一方、ファイルアクセス情報収集プログラム３００２は、アクセス解析テーブル９０００を定期的に参照または更新して、例えば、古いアクセス情報を削除する。

マイグレーションプログラム３００３は、アクセス解析テーブル９０００を参照してファイルをグループ化し、その結果をグルーピングテーブル８０００に登録して、更新する。一方、例えばユーザから指定されたスケジュールテーブル７０００を参照してスケジュール情報どおりにファイルを移行するためにファイルr/wを実行し、移行元のＲＧのＬＵに格納されたファイルを移行先のＲＧのＬＵにコピーする。ファイルの移行の結果は、必要に応じてマッピングテーブル６０００、スケジュールテーブル７０００、グルーピングテーブル８０００に反映し、更新する。これらの処理は定期的に実行される。

スピンダウン／アッププログラム３００４は、スケジュールテーブル７０００を参照し、スケジュール情報に従って、対象となるＲＧをスピンダウンまたはスピンアップする。

次に、ファイルアクセスプログラム３００１、ファイルアクセス情報収集プログラム３００２、マイグレーションプログラム３００３、スピンダウン／アッププログラム３００４により実行される処理について個別に説明する。なお、これらの処理の主体は、ＣＰＵ１００２である。
図２６は、ファイルアクセスプログラムにより実行される処理のフローを示す図である。この処理は、クライアント１０３０によるユーザからのファイルアクセス（ユーザアクセス）によって開始する。

まず、ステップＳ２６０１において、ＣＰＵ１００２は、ユーザアクセスに含まれるファイルアクセス要求からアクセス対象となるファイルのファイルパス名（ファイル名）を取得する。取得した後、ステップＳ２６０２に進む。

次に、ステップＳ２６０２において、ＣＰＵ１００２は、ファイルパス名とマッピングテーブル６０００を照合し、実際に格納されているファイルシステム（実ファイルシステム）とｉｎｏｄｅ番号（実ファイルシステム用ｉｎｏｄｅ番号）を特定する。ファイル名を検索キーとしてマッピングテーブル６０００から該当するレコードを抽出する。特定した後、Ｓ２６０３に進む。

次に、ステップＳ２６０３において、ＣＰＵ１００２は、上記の特定したファイルシステムに対して、ファイルアクセス（説明の便宜上、read要求またはwrite要求を例として採り上げる。）を実行する。実行した後、ステップＳ２６０４に進む。

次に、ステップＳ２６０４において、ＣＰＵ１００２は、後記するファイルアクセス情報収集処理（１）を実行する。実行した後、ファイルアクセスプログラム３００１により実行される処理を終了する。
以上で、ファイルアクセスプログラム３００１により実行される処理の説明を終了する。

図２７は、ファイルアクセス情報収集プログラムにより実行される処理のフローを示す図である。この処理は、主に、ファイルアクセス情報収集処理（１）およびファイルアクセス情報収集処理（２）からなる。まず、ファイルアクセス情報収集処理（１）について説明する。ファイルアクセス情報収集処理（１）は、ファイルアクセスプログラム３００１からの呼出し（Ｓ２６０４）によって開始する。

まず、ステップＳ２７０１において、ＣＰＵ１００２は、ステップＳ２６０３において実行されたファイルアクセスに関するアクセス情報を取得する。取得した後、ステップＳ２７０２に進む。

次に、ステップＳ２７０２において、ＣＰＵ１００２は、ＦＣディスクドライブ１０１２ａに記憶されているアクセス解析テーブル９０００を参照する。参照した後、ステップＳ２７０３に進む。

次に、ステップＳ２７０３において、ＣＰＵ１００２は、取得したアクセス情報を、アクセス解析テーブル９０００へマージする。マージした後、ステップＳ２７０４に進む。

次に、ステップＳ２７０４において、ＣＰＵ１００２は、マージした結果を反映させるべく、アクセス解析テーブル９０００を更新する。更新した後、ファイルアクセス情報収集処理（１）を終了し、呼出し元であるファイルアクセスプログラム３００１に処理に戻る。

次に、ファイルアクセス情報収集処理（２）について説明する。ファイルアクセス情報収集処理（２）は、定期的に開始する。

まず、ステップＳ２７０５において、ＣＰＵ１００２は、アクセス解析テーブル９０００を検索し、期限（１）（設定情報を参照）よりも古いアクセス情報を削除する。削除した後、ステップＳ２７０６に進む。

次に、ステップＳ２７０６において、ＣＰＵ１００２は、期限（１）よりも新しく、期限（２）（設定情報を参照）よりも古いアクセス情報を検索する。検索した後、ステップＳ２７０７に進む。

次に、ステップＳ２７０７において、ＣＰＵ１００２は、ファイル毎に検索結果を分類する。検索結果としては、当該ファイルに対するアクセスユーザ数を含む。分類した後、ステップＳ２７０７に進む。

次に、ステップＳ２７０８において、ＣＰＵ１００２は、上記分類による分類結果で、アクセスユーザ数が一定数より多いか否かを判定する。なお、この一定数は、例えば、管理者から入力され、メモリ１００８に記憶されている。アクセスユーザ数が一定数よりも多くはないとき（ステップＳ２７０８でＮｏ）、ステップＳ２７０９に進む。一方、アクセスユーザ数が一定数よりも多いとき（ステップＳ２７０８でＹｅｓ）、ステップＳ２７１０に進む。

次に、ステップＳ２７０９において、ＣＰＵ１００２は、アクセスユーザ数が少ない分類結果としてのアクセス情報は、スケジュール作成の利用価値が低いものとしてすべて削除する。削除した後、ファイルアクセス情報収集処理（２）を終了する。

次に、ステップＳ２７１０において、ＣＰＵ１００２は、アクセスユーザ数が多い分類結果としてのアクセス情報の一部を削除する。削除した後の残りは次回削除することで段階的に削除する。このとき、削除するときの段階数は任意に設定することができる。また、段階的に削除するときは、アクセスユーザ数が少ないものから削除するとスケジュールの作成において都合が良い。削除した後、ファイルアクセス情報収集処理（２）を終了する。
以上で、ファイルアクセス情報収集プログラム３００２により実行される処理の説明を終了する。

図２８は、マイグレーションプログラムにより実行される処理のフローを示す図である。この処理は、定期的に開始する。

まず、ステップＳ２８０１において、ＣＰＵ１００２は、アクセス解析テーブル９０００を参照する。参照した後、ステップＳ２８０２に進む。

次に、ステップＳ２８０２において、ＣＰＵ１００２は、グルーピングテーブル８０００を参照する。参照した後、ステップＳ２８０３に進む。

次に、ステップＳ２８０３において、ＣＰＵ１００２は、アクセス解析データ（アクセス解析テーブル９０００に登録されているアクセス情報）とグループデータ（グルーピングテーブル８０００に登録されているファイル情報）を比較する。比較した後、ステップＳ２８０４に進む。

次に、ステップＳ２８０４において、ＣＰＵ１００２は、マッピングテーブル６０００の書き換えを意味するリマップの必要があるか否かを判定する。ここで、リマップが必要であるとは、少なくとも、移行元となるＲＡＩＤグループのＬＵに格納されているファイルへのアクセスを可能とする時間帯以外の時間帯、つまりＲＡＩＤグループの停止時間帯において、そのファイルが、所定の期限内に所定の頻度以上にアクセスされるようになってきた、という状況であることを含む。リマップが必要であるとき（ステップＳ２８０４でＹｅｓ）、ステップＳ２８０５に進む。リマップが必要でないとき（ステップＳ２８０４でＮｏ）、特に、移行を必要とするファイルがないので、マイグレーションプログラム３００３により実行される処理を終了する。

次に、ステップＳ２８０５において、ＣＰＵ１００２は、マッピングテーブル６０００を参照する。参照した後、ステップＳ２８０６に進む。

次に、ステップＳ２８０６において、ＣＰＵ１００２は、スケジュールテーブル７０００を参照する。参照した後、ステップＳ２８０７に進む。

次に、ステップＳ２８０７において、ＣＰＵ１００２は、適切なＲＧ（ＲＡＩＤグループ）を（任意に）選択する。選択したＲＧはファイルの移行先のＲＧであり、そのＲＧが適切であるか否かは、後記ステップＳ２８０８の判定に委ねられる。選択した後、ステップＳ２８０８に進む。

次に、ステップＳ２８０８において、ＣＰＵ１００２は、スケジュールテーブル７０００の書き換えを意味するリスケジュールの必要があるか否かを判定する。ここで、リスケジュールが必要であるとは、少なくとも、移行先となるＲＡＩＤグループのいずれについても、ファイルへのアクセスを可能とする時間帯、つまり稼働時間帯が、移行しようとするファイルの移行の時期（スピンダウンまたはスピンアップに要する時間も含まれる）を含んでいない、という状況であることを含む。リスケジュールが必要であるとき（ステップＳ２８０８でＹｅｓ）、ステップＳ２８０９に進む。リスケジュールが必要でないとき（ステップＳ２８０８でＮｏ）、ステップＳ２８０７において選択したＲＧが、ファイルの移行の時期においては稼働しており、適切であることを意味しており、ステップＳ２８１０に進む。

次に、ステップＳ２８０９において、ＣＰＵ１００２は、スケジュールテーブル７０００を更新する。この更新では、移行先となるＲＡＩＤグループにおける、ファイルへのアクセスを可能とする時間帯がファイルの移行の時期を含むように処理がなされる。例えば、ユーザから相応の停止時間帯が指定される。更新した後、ステップＳ２８１０に進む。

次に、ステップＳ２８１０において、ＣＰＵ１００２は、ファイルの移行に対応するようにマッピングテーブル６０００を更新する。更新した後、ステップＳ２８１１に進む。

次に、ステップＳ２８１１において、ＣＰＵ１００２は、ファイルの移行に対応するようにグルーピングテーブル８０００を更新する。更新した後、ステップＳ２８１２に進む。

次に、ステップＳ２８１２において、ＣＰＵ１００２は、指定されたマップ、つまり更新された各テーブル（６０００、７０００、８０００）に従い、ファイルの配置を変更（つまり、ファイルを移行）する。変更した後、マイグレーションプログラム３００３により実行される処理を終了する。
以上で、マイグレーションプログラム３００３により実行される処理の説明を終了する。

図２９は、スピンダウン／アッププログラムにより実行される処理のフローを示す図である。この処理は、定期的に開始する。

まず、ステップＳ２９０１において、ＣＰＵ１００２は、現在日時を取得する。現在日時は、例えば、サーバ１００１に備えられたタイマ（不図示）から取得する。取得した後、ステップＳ２９０２に進む。

次に、ステップＳ２９０２において、ＣＰＵ１００２は、スケジューリングテーブル７０００と現在日時を比較し、スピンアップすべきＲＡＩＤグループを取得する。スピンアップすべきＲＡＩＤグループとは、例えば、現在日時が停止時間帯の終了時刻と一致するＲＡＩＤグループをいう。取得した後、ステップＳ２９０３に進む。

次に、ステップＳ２９０３において、ＣＰＵ１００２は、上記取得したＲＡＩＤグループのうち、スピンダウン中のＲＡＩＤグループを取得する。なお、本実施形態では、説明の便宜上、ＲＡＩＤグループのスピン状態はスピンアップおよびスピンダウンしか扱わないので、このステップで取得するＲＡＩＤグループとステップＳ２９０２で取得したＲＡＩＤグループは一致するが、他のスピン状態（例：スピンダウン予約状態、スピンオフ状態）を含む場合には、そのスピン状態にあるＲＡＩＤグループは除外する。取得した後、ステップＳ２９０４に進む。

次に、ステップＳ２９０４において、ＣＰＵ１００２は、スケジューリングテーブル７０００と現在日時を比較し、スピンダウンすべきＲＡＩＤグループを取得する。スピンダウンすべきＲＡＩＤグループとは、例えば、現在日時が停止時間帯の開始時刻と一致するＲＡＩＤグループをいう。取得した後、ステップＳ２９０５に進む。

次に、ステップＳ２９０５において、ＣＰＵ１００２は、上記取得したＲＡＩＤグループのうち、スピンアップ中のＲＡＩＤグループを取得する。なお、本実施形態では、説明の便宜上、ＲＡＩＤグループのスピン状態はスピンアップおよびスピンダウンしか扱わないので、このステップで取得するＲＡＩＤグループとステップＳ２９０２で取得したＲＡＩＤグループは一致する。取得した後、ステップＳ２９０６に進む。

次に、ステップＳ２９０６において、ＣＰＵ１００２は、ステップＳ２９０３で取得したＲＡＩＤグループに対して、スピンアップ要求を行い、ステップＳ２９０５で取得したＲＡＩＤグループに対して、スピンダウン要求を行う。
以上で、スピンダウン／アッププログラム３００４により実行される処理の説明を終了する。

実施形態１により、スピンダウンがなされるＲＡＩＤグループに格納されているファイルに対し、ファイルアクセスがなされたとしても、そのファイルをスピンアップ中のＲＡＩＤグループに事前に移行して、ファイルアクセスを受け付けることができるので、ファイルへのアクセスが継続する環境であっても省電力化を実現することができる。

また、ファイルシステムについては、ユーザには、実ファイルシステムを仮想的に統合した仮想ファイルシステムを見せ、実ファイルシステム自体を見せることはない。よって、ＲＡＩＤグループ間のファイルの移行があったとしても、そのことをユーザに意識させず済ませることができ、換言すれば、ユーザは通常通りにファイルアクセスを行なうことができる。

また、各プログラムがオペレーティング機能であるシステムコール等を利用する場合、目的のシステムコールを代わりに呼び出してくれるスタブを用いるとは異なり、仮想ファイルシステムを用いることで、ファイルの移行先の選択の幅が広がる。つまり、スタブを用いるときは、スタブ自体ですでに定められた移行先にしかファイルを移行させることができないが、仮想ファイルシステムを使用するときは、ＲＡＩＤグループの稼働状況を考慮しつつ、管理者が最適な移行先を指定することができる。指定する移行先は、省電力化が最大になる、つまり、各ＲＡＩＤグループの停止時間帯の合計が最長となるように選ぶことが好ましい。

（実施形態２）
実施形態１では、ファイルのアクセス状況に基づいてファイルの分類および移行を行っているため、類似したアクセス特性（例えば、ファイルアクセスがなされる時間帯が大体同じであること）を持つファイルが、１つのＲＡＩＤグループまたはＬＵに集中し、それらのファイルの一部または全部が頻繁にアクセスされる場合には、性能上の問題、例えば性能ボトルネックが発生する可能性がある。

そこで、スピンダウンしたＲＡＩＤグループとＮＡＳ装置（サーバ１００１）との接続に使用されているＦＣ（Fiber Channel）パス（ポート）を稼働中（スピンアップ中）のＲＡＩＤグループに一時的に振り分け、ファイルアクセスの集中に起因する性能ボトルネックを回避することができる。

具体的には、スケジュールテーブル７０００において、ＲＡＩＤグループごとに、ＦＣパスを振り分けるための条件、振り分け先のＲＡＩＤグループ（例：当該ＲＡＩＤグループを除くすべての（稼働中の）ＲＡＩＤグループ）等を格納するフィールドを設けるようにすると良い。前記条件としては、例えば、単位時間内のファイルアクセス数や振り分けを受け付けるＲＡＩＤグループを構成するボリュームの空き容量が所定値以上であること等とすれば良い。前記条件が満たされないようなファイルアクセス状況になった場合には、前記振り分けを終了するように制御する。振り分けの終了は一度に行なっても良いし、段階的に行なっても良い。

（実施形態３）
実施形態１のスケジュールテーブル７０００で定めるスケジュールは、ファイルアクセス情報を統計的に処理して得られたものであるため、そのスケジュールで定めた停止時間帯になってもファイルアクセスが発生する可能性はある。これにより、スピンダウンが遅延を招き、省電力化が効果的に達成されない可能性がある。所望する省電力化を達成する場合には、スピンダウンの遅延による消費電力増分を打ち消す必要があり、どこかで、例えば次にファイルアクセスがなされたときにでも良いので、スピンアップの遅延を行わなくてはならない。

そこで、スピンアップの遅延を各ＲＡＩＤグループに按分するように制御する。このとき、各ＲＡＩＤグループには、例えば、運用上から決まる重要度が存在するので、重要度に応じて前記按分を行なうと良い。例えば、あるＲＡＩＤグループで５００秒の遅延が発生した場合、ＲＡＩＤグループの重要度に従って、下記のように按分する。

＜ＲＡＩＤグループ名＞ ＜重要度＞ ＜スピンアップ遅延時間／〔ｓ〕＞
Ｒｇｒｏｕｐ−Ａ０１ Ａ ５
： ： ：
Ｒｇｒｏｕｐ−Ａ１０ Ａ ５

Ｒｇｒｏｕｐ−Ｂ０１ Ｂ １５
： ： ：
Ｒｇｒｏｕｐ−Ｂ１０ Ｂ １５

Ｒｇｒｏｕｐ−Ｃ０１ Ｃ ３０
： ： ：
Ｒｇｒｏｕｐ−Ｃ１０ Ｃ ３０

計 ５×１０＋１５×１０＋３０×１０＝５００〔ｓ〕

重要度は大きいほうからＡ、Ｂ、Ｃの順に定めてあり、重要度が大きいほど、按分するスピンアップ遅延時間を短くする。また、重要度は、例えば、当該ＲＡＩＤグループに含まれるＬＵの数やユーザからのファイルアクセス数等に基づいて決定するようにし、メモリ１００８に格納される。

これにより、節電効果を損ねることなく、かつ、遅延を分散するため、ユーザの利便性への影響を小さくすることができる。なお、この按分は、スピンアップしているかスピンダウンしているか否かに関わらず、すべてのＲＡＩＤグループに行うことができる。

なお、本発明を実施するための形態は、これに限定されるものでなく、その形態の実施形式を種々変形することが可能である。

例えば、スピンダウンするＲＡＩＤグループを選ぶときには、ハードディスクの性能を考慮しても良い。ハードディスクの性能としては、例えば、使用するＣＰＵの周波数やディスクの種類、容量、信頼性があげられる。これは、実施形態１〜３に共通する。

また、本実施形態では、ファイルシステムを階層化しており、既に説明したとおり、スタブを使用した場合と比べて、ファイルの移行先の選択幅が広がるのであるが、移行先としては、そのファイルがよくアクセスされるのであれば、階層が上位にある実ファイルシステム（本実施形態では、ＦＳ Ａ（１０１５）（図２参照））を作成する高速ボリュームを有するＲＡＩＤグループとするのが良いし、そのファイルがあまりアクセスされないのであれば、階層が下位にある実ファイルシステム（本実施形態では、ＦＳ Ｂ（１０１６）（図２参照））を作成する低速ボリュームを有するＲＡＩＤグループとするのが良い。つまり、ファイルシステムの階層性を、ファイルの移行先を選択するための基準とすると良い。

その他、ハードウェア、ソフトウェア、各テーブル、各フローチャート等の具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１００１ サーバ（ファイルサーバ）
１００２ ＣＰＵ（制御部）
１００５ 管理コマンド
１００６ 階層管理ファイルシステムプログラム
１００７ 実ファイルシステムプログラム
１００８ メモリ（記憶部）
１００９ オペレーティングシステム
１０１０ 管理情報
１０１１ ディスク制御装置
１０１２ ＦＣディスクドライブ
１０１３ ＳＡＴＡディスクドライブ
１０１４ ＲＡＩＤ装置（記憶装置）
１０１５ ＦＳ Ａ
１０１６ ＦＳ Ｂ
１０１７ ＦＳＭファイルシステム
１０２０ 管理端末
１０３０ クライアント
１０３１ ファイルアクセス要求プログラム
３０００ ＶＦＳプログラム
３００１ ファイルアクセスプログラム
４０００ 階層管理テーブル（ファイルシステム階層管理情報）
５０００ 階層データリスト
６０００ マッピングテーブル（マッピング情報）
７０００ スケジュールテーブル（スケジュール情報）
８０００ グルーピングテーブル
９０００ アクセス解析テーブル（アクセス情報）

Claims (15)

1. １以上のボリュームで構成される複数のＲＡＩＤグループを有する記憶装置と、ファイルアクセス要求をするクライアントと通信可能に接続し、前記ＲＡＩＤグループに対して作成した実ファイルシステムおよび前記実ファイルシステムを仮想的に統合した仮想ファイルシステムを用いて前記ＲＡＩＤグループに格納されるファイルを管理するファイルサーバにおいて、
   前記記憶装置は、
   前記ファイルを前記仮想ファイルシステムで管理するときに使用するファイル名と、前記ファイルが格納される前記ＲＡＩＤグループと、前記ファイルを実際に管理する前記実ファイルシステムとを、ファイルごとに対応付けたマッピング情報と、
   スピンダウンをして前記ＲＡＩＤグループを停止する停止時間帯と、スピンアップをして前記ＲＡＩＤグループを稼働する稼働時間帯とを、ＲＡＩＤグループごとに定めたスケジュール情報と、
   を記憶しており、
   前記ファイルサーバは、
   前記記憶装置に記憶させる情報を生成するための記憶領域を有する記憶部と、
   前記クライアントのファイルアクセス要求に対し、前記ファイルアクセス要求に含まれる前記ファイル名およびファイルアクセス日時を取得し、前記ファイル名と、前記ファイルアクセス日時とを対応付けたアクセス情報を生成して前記記憶装置に記憶させる制御と、
   前記アクセス情報に基づいてファイルアクセス時間帯が共通するファイルを１つのグループとすることでファイルを分類し、前記ファイルアクセス時間帯が前記停止時間帯と重複しないようにして、前記グループに属するファイルが格納されることになる前記ＲＡＩＤグループを決定し、前記決定したＲＡＩＤグループの稼働中に当該ファイルを移行し、前記移行したファイルについて前記マッピング情報を更新する制御と、
   前記スケジュール情報に基づいて前記停止時間帯では前記ＲＡＩＤグループについてスピンダウンをし、前記稼働時間帯では前記ＲＡＩＤグループについてスピンアップをする制御と、
   を実行する制御部とを有する
   ことを特徴とするファイルサーバ。
2. 前記スケジュール情報には、ファイルサーバとＲＡＩＤグループとの接続に使用されるポートを、当該ＲＡＩＤグループとは別のＲＡＩＤグループに振り分けをする条件が、あるＲＡＩＤグループに格納されるファイルが所定数以上あり、かつ、前記所定数以上のファイルの一部または全部に対して所定頻度以上のファイルアクセスがなされることとして定められており、
   前記制御部は、
   前記条件が満たされたとき、当該グループに属するファイルが格納されているＲＡＩＤグループとは別のＲＡＩＤグループに対して前記振り分けをする
   ことを特徴とする請求項１に記載のファイルサーバ。
3. 前記記憶部は、ＲＡＩＤグループについてするスピンアップの遅延に関する重要度を、ＲＡＩＤグループごとに記憶し、
   前記制御部は、
   あるＲＡＩＤグループに格納されたファイルに対して前記クライアントのファイルアクセス要求が当該ＲＡＩＤグループの停止中にあったとき、前記重要度が大きいほどスピンアップの遅延時間が短くなるように、すべてのＲＡＩＤグループについてするスピンアップを遅延する
   ことを特徴とする請求項１に記載のファイルサーバ。
4. 前記制御部は、
   前記クライアントのファイルアクセス要求に対し、ファイルアクセスなかった時間が、当該ファイルが格納されることになるＲＡＩＤグループのスピンダウンに要する時間よりも短いとき、前記ファイルアクセスのなかった時間にはファイルアクセスがあったものとみなして、前記ファイルの分類を行う
   ことを特徴とする請求項１に記載のファイルサーバ。
5. 前記アクセス情報には、前記ファイルアクセス要求を行ったユーザも対応付けられており、
   前記制御部は、
   前記ファイルアクセス日時および前記ファイルアクセス要求を行ったユーザ数に基づいて前記アクセス情報を削除する
   ことを特徴とする請求項１に記載のファイルサーバ。
6. １以上のボリュームで構成される複数のＲＡＩＤグループを有する記憶装置と、ファイルアクセス要求をするクライアントと、前記ＲＡＩＤグループに対して作成した実ファイルシステムおよび前記実ファイルシステムを仮想的に統合した仮想ファイルシステムを用いて前記ＲＡＩＤグループに格納されるファイルを管理するファイルサーバが通信可能に接続するファイル管理システムにおいて、
   前記記憶装置は、
   前記ファイルを前記仮想ファイルシステムで管理するときに使用するファイル名と、前記ファイルが格納される前記ＲＡＩＤグループと、前記ファイルを実際に管理する前記実ファイルシステムとを、ファイルごとに対応付けたマッピング情報と、
   スピンダウンをして前記ＲＡＩＤグループを停止する停止時間帯と、スピンアップをして前記ＲＡＩＤグループを稼働する稼働時間帯とを、ＲＡＩＤグループごとに定めたスケジュール情報と、
   を記憶しており、
   前記ファイルサーバは、
   前記記憶装置に記憶させる情報を生成するための記憶領域を有する記憶部と、
   前記クライアントのファイルアクセス要求に対し、前記ファイルアクセス要求に含まれる前記ファイル名およびファイルアクセス日時を取得し、前記ファイル名と、前記ファイルアクセス日時とを対応付けたアクセス情報を生成して前記記憶装置に記憶させる制御と、
   前記アクセス情報に基づいてファイルアクセス時間帯が共通するファイルを１つのグループとすることでファイルを分類し、前記ファイルアクセス時間帯が前記停止時間帯と重複しないようにして、前記グループに属するファイルが格納されることになる前記ＲＡＩＤグループを決定し、前記決定したＲＡＩＤグループの稼働中に当該ファイルを移行し、前記移行したファイルについて前記マッピング情報を更新する制御と、
   前記スケジュール情報に基づいて前記停止時間帯では前記ＲＡＩＤグループについてスピンダウンをし、前記稼働時間帯では前記ＲＡＩＤグループについてスピンアップをする制御と、
   を実行する制御部とを有する
   ことを特徴とするファイル管理システム。
7. 前記スケジュール情報には、ファイルサーバとＲＡＩＤグループとの接続に使用されるポートを、当該ＲＡＩＤグループとは別のＲＡＩＤグループに振り分けをする条件が、あるＲＡＩＤグループに格納されるファイルが所定数以上あり、かつ、前記所定数以上のファイルの一部または全部に対して所定頻度以上のファイルアクセスがなされることとして定められており、
   前記制御部は、
   前記条件が満たされたとき、当該グループに属するファイルが格納されているＲＡＩＤグループとは別のＲＡＩＤグループに対して前記振り分けをする制御、を実行する
   ことを特徴とする請求項６に記載のファイル管理システム。
8. 前記記憶部は、ＲＡＩＤグループについてするスピンアップの遅延に関する重要度を、ＲＡＩＤグループごとに記憶し、
   前記制御部は、
   あるＲＡＩＤグループに格納されたファイルに対して前記クライアントのファイルアクセス要求が当該ＲＡＩＤグループの停止中にあったとき、前記重要度が大きいほどスピンアップの遅延時間が短くなるように、すべてのＲＡＩＤグループについてするスピンアップを遅延する制御、を実行する
   ことを特徴とする請求項６に記載のファイル管理システム。
9. 前記制御部は、
   前記クライアントのファイルアクセス要求に対し、ファイルアクセスなかった時間が、当該ファイルが格納されることになるＲＡＩＤグループのスピンダウンに要する時間よりも短いとき、前記ファイルアクセスのなかった時間にはファイルアクセスがあったものとみなして、前記ファイルの分類を行う制御、を実行する
   ことを特徴とする請求項６に記載のファイル管理システム。
10. 前記アクセス情報には、前記ファイルアクセス要求を行ったユーザも対応付けられており、
    前記制御部は、
    前記ファイルアクセス日時および前記ファイルアクセス要求を行ったユーザ数に基づいて前記アクセス情報を削除する制御、を実行する
    ことを特徴とする請求項６に記載のファイル管理システム。
11. １以上のボリュームで構成される複数のＲＡＩＤグループを有する記憶装置と、ファイルアクセス要求をするクライアントと通信可能に接続し、前記ＲＡＩＤグループに対して作成した実ファイルシステムおよび前記実ファイルシステムを仮想的に統合した仮想ファイルシステムを用いて前記ＲＡＩＤグループに格納されるファイルを管理するファイルサーバにおけるファイル管理方法において、
    前記記憶装置は、
    前記ファイルを前記仮想ファイルシステムで管理するときに使用するファイル名と、前記ファイルが格納される前記ＲＡＩＤグループと、前記ファイルを実際に管理する前記実ファイルシステムとを、ファイルごとに対応付けたマッピング情報と、
    スピンダウンをして前記ＲＡＩＤグループを停止する停止時間帯と、スピンアップをして前記ＲＡＩＤグループを稼働する稼働時間帯とを、ＲＡＩＤグループごとに定めたスケジュール情報と、
    を記憶しており、
    前記ファイルサーバは、
    前記記憶装置に記憶させる情報を生成するための記憶領域を有する記憶部を有し、
    前記ファイルサーバの制御部は、
    前記クライアントのファイルアクセス要求に対し、前記ファイルアクセス要求に含まれる前記ファイル名およびファイルアクセス日時を取得し、前記ファイル名と、前記ファイルアクセス日時とを対応付けたアクセス情報を生成して前記記憶装置に記憶させるステップと、
    前記アクセス情報に基づいてファイルアクセス時間帯が共通するファイルを１つのグループとすることでファイルを分類し、前記ファイルアクセス時間帯が前記停止時間帯と重複しないようにして、前記グループに属するファイルが格納されることになる前記ＲＡＩＤグループを決定し、前記決定したＲＡＩＤグループの稼働中に当該ファイルを移行し、前記移行したファイルについて前記マッピング情報を更新するステップと、
    前記スケジュール情報に基づいて前記停止時間帯では前記ＲＡＩＤグループについてスピンダウンをし、前記稼働時間帯では前記ＲＡＩＤグループについてスピンアップをするステップと、
    を実行する
    ことを特徴とするファイル管理方法。
12. 前記スケジュール情報には、ファイルサーバとＲＡＩＤグループとの接続に使用されるポートを、当該ＲＡＩＤグループとは別のＲＡＩＤグループに振り分けをする条件が、あるＲＡＩＤグループに格納されるファイルが所定数以上あり、かつ、前記所定数以上のファイルの一部または全部に対して所定頻度以上のファイルアクセスがなされることとして定められており、
    前記制御部は、
    前記条件が満たされたとき、当該グループに属するファイルが格納されているＲＡＩＤグループとは別のＲＡＩＤグループに対して前記振り分けをするステップ、を実行する
    ことを特徴とする請求項１１に記載のファイル管理方法。
13. 前記記憶部は、ＲＡＩＤグループについてするスピンアップの遅延に関する重要度を、ＲＡＩＤグループごとに記憶し、
    前記制御部は、
    あるＲＡＩＤグループに格納されたファイルに対して前記クライアントのファイルアクセス要求が当該ＲＡＩＤグループの停止中にあったとき、前記重要度が大きいほどスピンアップの遅延時間が短くなるように、すべてのＲＡＩＤグループについてするスピンアップを遅延するステップ、を実行する
    ことを特徴とする請求項１１に記載のファイル管理方法。
14. 前記制御部は、
    前記クライアントのファイルアクセス要求に対し、ファイルアクセスなかった時間が、当該ファイルが格納されることになるＲＡＩＤグループのスピンダウンに要する時間よりも短いとき、前記ファイルアクセスのなかった時間にはファイルアクセスがあったものとみなして、前記ファイルの分類を行うステップ、を実行する
    ことを特徴とする請求項１１に記載のファイル管理方法。
15. 前記アクセス情報には、前記ファイルアクセス要求を行ったユーザも対応付けられており、
    前記制御部は、
    前記ファイルアクセス日時および前記ファイルアクセス要求を行ったユーザ数に基づいて前記アクセス情報を削除するステップ、を実行する
    ことを特徴とする請求項１１に記載のファイル管理方法。

Images