JP2009163367A - ファイルシステム、プログラム及びファイルの管理方法 - Google Patents

Abstract

【課題】大量のファイルの一括操作を高速化する。
【解決手段】グループ化するファイルについて、そのデータブロック情報とｉノード情報を持つ仮想集合ファイル（アグリゲートファイル）を作成し、管理する。アグリゲートファイルを指定したファイル操作コマンドが実行された場合、アグリゲートファイルのデータブロック情報とｉノード情報を用いたファイル操作を行うことで、ディスクへのランダムアクセスの削減や、ｉノードの一括更新を実現する。また、アグリゲートファイルに適宜属性を与えて管理することで、グループ化するファイルの自由度や多次元性の制限を無くすことができる。
【選択図】図３

Description

本発明は、ファイルシステム、プログラム及びファイルの管理方法に関し、特に、複数のファイルを、仮想的な１つのファイルとして取り扱うことのできるファイルシステム、プログラム及びファイルの管理方法に関する。

ディスクの大容量化やシステムの統合に伴い、ストレージに格納されるファイルサイズ、ファイル数は加速度的に増大している。数年前にはハードディスク容量は１００ＧＢ未満だったが、現在は１ＴＢハードディスクが出荷されている。システムとしても、数ＴＢ規模のストレージを持つものが一般的になってきている。

こうしたストレージに格納されるファイルの側では、マルチメディア系のファイルが増え、アプリケーションもリッチになる等、個々のファイルサイズが大きくなることに加え、コンプライアンスや履歴管理の側面からファイルを消さずに保存しておくようになり、ファイル数が増える原因となっている。

これらのデータの中には高速アクセスが必要なものもあれば、ほとんどアクセスされないものもあり、すべてを同列に扱うのは不合理である。すべてのデータに高速アクセスを実現することは可能であるが、コストが膨大になってしまう。そこで高速高価なストレージと低速安価なストレージを用意し、データの求められるサービスレベルに合わせて振り分けて全体のコストを削減する、階層ストレージ管理（ＨＳＭ：Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ）が注目されるようになってきた。

前記階層ストレージ管理を実現するには、上記大容量のストレージに格納される無数のファイルの取り扱いが必須となる。例えば、特許文献１には、ファイル格納部に格納したファイルをグループ化するグループ情報を用いてファイル格納部に格納されたファイルをグループ処理するグループ処理部を備えたファイルのグループ処理装置が開示されている。

また、特許文献２には、１つのファイルをグループに登録する際に、グループ間の包含関係を参照し、一のグループへの登録をもって、関係する他のグループにも該当ファイルを登録するファイル管理方法が開示されている。

データは、その作成当初は頻繁に書き換えられアクセスされるため、高速でアクセス性の高いサービスレベルが要求されるが、ファイルとして完成したあとは更新がなくなり、さらに時間が経つとアーカイブとなるといったライフサイクルがある。このような観点でデータの管理を行う考え方として、ＩＬＭ（Ｉｍｆｏｍａｔｉｏｎ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ：情報ライフサイクル管理）がある。

特開平０４−１６０４３９号公報 特開平０９−２６５４２１号公報

上記階層ストレージ管理にしても、情報ライフサイクル管理にしても、異なるサービスレベルが設定されたストレージ間を、多数、大容量のファイルを移動させる処理が必要となってくる。ファイル数が少ないときには逐次処理でもそれほど時間がかからず、無視できるレベルであった。しかしながら、上記に述べたように、ストレージが大容量化し、ファイル数が膨大になると処理時間が相当なものとなり、また負荷も相当かかるため、従来のように無視することができなくなっている。

従来から、ユーザ操作のレベルでは複数ファイルを一括操作することは一見可能に見えている。しかしながら、ファイルシステムのレベルでは、一括処理ではなく逐次処理になっている。例えばファイルを削除する場合、ファイルマネージャのようなＧＵＩからディレクトリをクリックして削除を選べばディレクトリ配下の全ファイルを削除することができる。ＵＮＩＸ（登録商標）であればコンソールから「ｒｍ −ｒ ディレクトリ名」といった一つのコマンドでディレクトリ配下の多数のファイルを再帰的に削除することができる。これらのＧＵＩやコマンドはユーザ空間のプログラムにすぎず、カーネルファイルシステムに対してはディレクトリ配下のファイル一つ一つに対して再帰的に削除コマンドを発行しているのである。

逐次処理だとなぜ遅くなるかは大きく２つの原因が挙げられる。１つ目は同じ処理をシーケンシャルに繰り返し行うことである。複数ファイルに対して一括処理をする場合、ほとんどの処理はファイル個々で共通である。しかしファイルシステムレベルでは個々のファイルに対して処理を行うので、ファイル数だけ同じ処理を行わなければならない。しかも、ファイル削除のような変更を伴う処理はファイルシステムレベルでは並列処理ができない。バックグラウンド実行すれば並列処理をしているように見えるかもしれないが、ファイルシステムレベルではロックをとって直列に処理されているのである。

２つ目はディスクＩ／Ｏが細分化、ランダムアクセスになってしまうことである。ランダムなディスクＩ／Ｏはとてもオーバーヘッドが大きい。ディスクのヘッドをアクセス位置まで移動する時間（シークタイム）は高速なものでも数ｍｓかかってしまう。ＧＨｚレベルで動作するＣＰＵやメモリにとっては、とてつもなく大きい待ち時間となる。どれだけディスクアクセスをシーケンシャルにするかが性能に最も影響すると言っても過言ではない。その点ではファイル毎の逐次処理は決して望ましいものではない。

更に、索引割付け方式でファイルを管理するファイルシステムでは、ファイルの削除をするとき、ファイルに対しユニークに与えられるインデックス番号（ｉｎｏｄｅ番号）を未使用に戻す処理を行う。たいていのファイルシステムはｉｎｏｄｅをビットマップで管理しているため、対応するビットを変更する処理を行う。ビットマップはメモリにも持っているが、ディスク上にもあるためディスクへ書き込みをしなければならない。ファイルを逐次削除すると、１つのファイルの削除を行う度に毎回変更したビットマップをディスクに書き込んでいるのである。これをまとめて処理できれば、ビットマップの書き込み回数を大幅に減らすことができる。

ファイルをまとめて処理する既存技術について述べる。通常のファイルシステム経由ではなくまとめて処理をする方法として、ブロックレベル処理、ループバックマウント、アーカイブファイル（ＴＡＲ）がある。ブロックレベル処理はファイルシステムを経由せずディスクをＲＡＷデバイスとしてアクセスする方式である。細かいランダムアクセスはせず、シーケンシャルＩ／Ｏができるので高速な処理が可能である。しかしファイルシステムを経由しないために、ファイルやメタデータ自体の区別ができない。そもそもファイルシステム的に空いているか使っているかも意識できない。そのため、ブロックレベル処理はファイルシステム全体に対しての処理となってしまい、当然に後記するグルーピングや多次元性を実現することも不可能である。

ループバックマウントとアーカイブファイルは、ファイルシステム上では１つのファイルに複数のファイルが含まれるものである。ループバックマウントはファイル自体をボリュームとして再度マウントする。アーカイブファイルは複数ファイルをまとめたファイルであり、ＴＡＲはテープバックアップで使われる形式である。両方ともファイルシステムレベルであるため、ブロックレベル処理と違いファイルを意識できるが、これらを用いてファイル操作をしても、元のファイルに変更が及ぶわけではなく、元のファイルを削除する場合には、上記した逐次処理を行わなければならないという問題点がある。

また、特許文献１、２のいずれも、管理性や操作性を向上させる観点で、ファイルをグループ化する技術であり、多数、大容量のファイルを移動するような処理をした場合、上述した逐次処理による遅延、負荷が発生する。

本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、ストレージ間の移動を伴う、多数、大容量のファイルの管理に好適なファイルシステムを提供することにある。

本発明の第１の視点によれば、複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルにより、該仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理する仮想集合ファイル管理機構を有し、前記仮想集合ファイル管理機構は、前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を行うファイルシステムが提供される。

本発明の第２の視点によれば、複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルにより、該仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理する仮想集合ファイル管理機構としてコンピュータを機能させ、前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を前記コンピュータに実行させるプログラムが提供される。

本発明の第３の視点によれば、所定の記憶装置に保存されたファイルの管理方法であって、コンピュータに、複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルを作成させ、前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記コンピュータに、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を実行させ、前記仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理させることを特徴とするファイルの管理方法が提供される。

本発明によれば、多数のファイルをグループ化し、一括操作する処理の遅延解消、負荷低減が達成される。その理由は、ファイルシステムレベルで、できるだけシーケンシャル、かつ、まとまった処理ができるよう仮想集合ファイルという概念を導入したことにある。

続いて、本発明を実施するための最良の形態について説明する。図１は、本発明の第１の実施形態のシステム構成図である。図１を参照すると、Ａ、Ｂ２つのストレージ１ａ、１ｂがネットワーク６で接続されている。この間である特定の属性を持つファイルの集まりであるファイルグループ５を移動させるケースを想定する。ストレージ１ａがコピー元ストレージ、ストレージ１ｂがコピー先ストレージになる。ストレージ１ａ、１ｂの双方に、本発明のファイルシステム３がインストールされているものとする。

ファイルの移動は、コピー元ストレージからコピー先ストレージへのコピーと、コピー元ストレージのファイル削除である。

始めに、上記ストレージ間のファイルの移動を一括操作で実現するための仮想的な集合ファイル（以下、「アグリゲートファイル」という。）の構造、ファイルアクセス時のアグリゲートファイルに対する操作について説明する。

図２は、アグリゲートファイルの構造を説明するための図である。図２を参照すると、アグリゲートファイル１０は、大きくｉｎｏｄｅ情報１１を記述する領域と、データブロック情報１２を記述する領域とに分けることができる。

ｉｎｏｄｅ番号は、ファイルやディレクトリを割付けたデータブロック情報を取得するためのインデックス情報の番号であり個々のファイルに一意に与えられる。アグリゲートファイル１０のｉｎｏｄｅ情報１１は、グループ化するファイルのｉｎｏｄｅ番号＋親ディレクトリのｉｎｏｄｅ番号のリストである。親ディレクトリのｉｎｏｄｅ番号が必要な理由は後述する。

アグリゲートファイル１０のデータブロック情報１２は、グループ化するファイルのデータブロック情報を並び替え（マージ）したものである。単純に各ファイルのデータブロック情報を並べたものでもよいが、ファイルシステムに応じてソートやＢ−Ｔｒｅｅ化すると高速化の効果が高くなる。

図３は、アグリゲートファイル１０とファイルｉｎｏｄｅ、ディレクトリｉｎｏｄｅの関係を示している。ディレクトリｉｎｏｄｅ１５のｉｎｏｄｅ情報はファイルｉｎｏｄｅ１３とファイルｉｎｏｄｅ１４のｉｎｏｄｅ番号を持っている。これはディレクトリｉｎｏｄｅ１５の配下にファイルｉｎｏｄｅ１３、ファイルｉｎｏｄｅ１４があることを示している。ファイルｉｎｏｄｅ１３のデータブロック情報とファイルｉｎｏｄｅ１４のデータブロック情報がアグリゲートファイル１０のデータブロック情報に含まれている。

図３の例では、アグリゲートファイル１０には、ファイルグループを示す属性＝Ａが与えられているものとする。ファイルシステム３の後記するアグリゲートファイル管理機構（仮想集合ファイル管理機構）は、アグリゲートファイルを用いて、ファイルｉｎｏｄｅ内の属性がＡであるファイルを一括で管理する。

図４は、本実施形態に係るファイルシステム周辺の機能ブロック図である。図４を参照すると、本実施形態に係るファイルシステム３は、ファイルシステムコア（ファイルシステム制御部）７と、アグリゲートファイル管理機構８と、アグリゲートファイル管理テーブル９を含んで構成されている。

ユーザアプリケーション２０は、ファイルシステムＡＰＩ（Application Program Interface）を通じてファイルシステム３に対するファイル操作と、アグリゲートファイル管理機構８専用のＡＰＩを通じたファイル操作を行うことができる各種アプリケーションである。

ファイルシステムコア（ファイルシステム制御部）７は、ディスク４に対するファイルの作成、更新、削除を受け付けるほか、アグリゲートファイル管理機構８に対してファイルが作成、更新された旨を通知する。

アグリゲートファイル管理機構８は、アグリゲートファイル１０に記述された複数のファイルを仮想的な一つのファイルとして管理する手段である。また、アグリゲートファイル管理機構８は、ファイルシステムコア（ファイルシステム制御部）７からファイルが作成、更新された旨の通知を受けると、アグリゲートファイル管理テーブル９を参照して、アグリゲートファイル１０に対する参照、更新を行う。

ユーザアプリケーション２０からアグリゲートファイル１０に対する操作は、アグリゲートファイル管理機構８専用のＡＰＩを通して行う。

なお、本実施形態では、アグリゲートファイル１０は通常のファイルのようにディレクトリに属さないものとしている。従って、通常のファイルアクセスＡＰＩからはアクセスできない。専用ＡＰＩを通して削除やコピーコマンドが通知されると、アグリゲートファイル管理機構８においてアグリゲートファイル専用の削除やコピーコマンドが実行される。

図５は、アグリゲートファイル管理テーブル９の例である。図９の例では、属性とキーとしてアグリゲートファイルのｉｎｏｄｅ番号を取得できるようになっている。例えば、属性＝Ｂをキーとして、ｉｎｏｄｅ番号＝１０１のアグリゲートファイルを特定することができる。なお、アグリゲートファイル管理テーブル９自体も失ってはいけない情報なので、ファイルとしてディスク４内に保存される。

続いて、本実施形態のファイルシステムの動作について図面を参照して詳細に説明する。図６は、新たにファイルが作成されたときのファイルシステム３の動作を表したフローチャートである。図６を参照すると、まず、通常のファイルシステムＡＰＩ経由で新規ファイルが作成されると（ステップＳ００１）、ファイルシステムコア（ファイルシステム制御部）７より、アグリゲートファイル管理機構８に通知が行われる（ステップＳ００２）。

アグリゲートファイル管理機構８は、ファイルシステムコア（ファイルシステム制御部）７より通知されたファイルの属性を調べ、アグリゲートファイル管理テーブル９に該当するアグリゲートファイル１０が存在するか否かを確認する（ステップＳ００３）。なお、ある属性に該当するアグリゲートファイル１０は複数ある可能性があるため、基本的にはアグリゲートファイル管理テーブル９を全探索する必要がある。

アグリゲートファイル管理テーブル９に該当するアグリゲートファイル１０があったら（ステップＳ００４の「Ｙ」）、アグリゲートファイル管理機構８は、アグリゲートファイル１０内の情報を更新する（ステップＳ００５）。具体的には、ｉｎｏｄｅ情報１１への新規ファイルのｉｎｏｄｅ番号の追加と、データブロック情報１２の再マージが行われる。アグリゲートファイル管理テーブル９に該当するアグリゲートファイル１０がない場合は（ステップＳ００４の「Ｎ」）、終了しファイルシステムコア（ファイルシステム制御部）７に処理を返すことになる（ステップＳ００６）。

なお、ファイルが更新された場合はｉｎｏｄｅ情報１１の更新は行わず、データブロック情報１２の更新が行われる。データブロックが増えたときは、新たに確保されたデータブロックが確定した段階で、アグリゲートファイル管理機構８に処理が回るようにすればよい。データブロックが減った場合（Ｔｒｕｎｃａｔｅ）は、解放されたデータブロックが確定できる段階で処理を回すようにすればよい。

ファイルが個別に削除される場合も、上記作成時と同様の流れで、ｉｎｏｄｅ情報１１からの削除と、データブロック情報１２の更新が行われる。

上記したアグリゲートファイル１０の作成は、専用ＡＰＩを通じてアグリゲートファイル管理テーブル９に属性を設定すると、アグリゲートファイル管理機構８がアグリゲートファイル１０を生成するようにすればよい。

また上述のようにアグリゲートファイル１０が既にある状態で、該当する属性の新規ファイルが作成されるとアグリゲートファイル１０への登録が行われるが、アグリゲートファイル１０作成時にすでにあったファイルは登録されないというケースが生じる。例えば、アグリゲートファイル管理機構８が、アグリゲートファイル１０作成時に、ユーザから、グループ化する（アグリゲートファイルに登録する）ファイルの条件（属性等）の指定を受け付けることし、ファイルシステム全体を探索して該当するファイルを登録するようにしてもよい。

図７は、本実施形態に係るファイルシステムにおいて、アグリゲートファイルを指定した一括コピーコマンドが実行されたときの動作を表したフローチャートである。なお、アグリゲートファイルを指定した一括コピーコマンドの実行は、コピー元、コピー先の両方が、アグリゲートファイル管理機構８を備えたファイルシステム３であることが前提である。

図７を参照すると、まず、専用ＡＰＩを通じて一括コピーコマンドが発行されると（ステップＳ１０１）、アグリゲートファイル管理機構８は、コピー先に、必要な容量を確保する（ステップＳ１０２）。通常のファイルコピーであれば、対象ファイルサイズを積算しなければならないが、アグリゲートファイル１０に、登録されたすべてのファイルのファイルサイズ（総サイズ）も保存しておくようにすることで、対象ファイルサイズの積算処理を省略することができ、時間と負荷の短縮になる。

所定の容量を確保可能な場合は、アグリゲートファイル管理機構８は、アグリゲートファイル１０を、一つのファイルとみなしてコピーする（ステップＳ１０４）。具体的には、アグリゲートファイル管理機構８は、アグリゲートファイル１０のｉｎｏｄｅを通常ファイルのｉｎｏｄｅとみなし、データブロック情報１２に基づいてデータをコピーする。ファイル個々にコピーする場合は、冒頭に述べたような逐次処理となるが、データブロック情報１２がソートされていれば、シーケンシャルアクセスが可能になり、コピーを高速化できる。なお、所定の容量を確保できない場合は、エラー終了となる（ステップＳ１２０）。

ここで、コピー先とコピー元とはデータブロック番号が異なるのでその対応をとらなければならないという問題が生じる。そこで、本実施形態のアグリゲートファイル管理機構８は、コピー元のデータブロック情報とコピー先のデータブロック情報を関連づけるテーブルを作成する（ステップＳ１０５）。例えば、コピー元データブロック情報を拡張してコピー先データブロックを引けるようにすればよい。このようなデータブロック変換テーブルの例を図８に示す。このデータブロック変換テーブルを用いることで、次のｉｎｏｄｅをコピーする際にデータブロックの付け替えが可能となる。

アグリゲートファイルのコピーが終了したら、アグリゲートファイル管理機構８は、ｉｎｏｄｅのコピーを行ない（ステップＳ１０６）、親ディレクトリへの登録を行う（ステップＳ１０７）。最後に、アグリゲートファイル管理機構８は、前述のデータブロック変換テーブルを参照して、ｉｎｏｄｅ内のデータブロック情報をコピー先データブロックに変換する処理を行う（ステップＳ１０８）。

なお、この変換をしつつコピーすると時間が掛かる場合には、ひとまずコピー元データブロック情報のままで処理を終了させてしまってもよい。実際にデータアクセスする際には、データブロック変換テーブルを介してアクセスするようにすればよいからである。データブロック変換は、任意のタイミングで行うようにすればよい。データブロック変換が必要か（データアクセス時にデータブロック変換テーブルの参照が必要か否か）は、データブロック変換が済んでいないことを示すフラグをｉｎｏｄｅ内に持つことで判定を行うようにすればよい。

図９は、本実施形態に係るファイルシステムにおいて、アグリゲートファイルを指定した一括削除コマンドが実行されたときの動作を表したフローチャートである。図９を参照すると、まず、専用ＡＰＩを通じて一括削除コマンドが発行されると（ステップＳ２０１）、アグリゲートファイル管理機構８は、アグリゲートファイル１０のｉｎｏｄｅ情報１１を参照し、記述されたすべてのｉｎｏｄｅのＬＯＣＫと、親ディレクトリのＬＯＣＫを取る（ステップＳ２０２）。ここで、ＬＯＣＫを獲得できない場合は（ステップＳ２０３の「Ｎ」）、エラー終了となる（ステップＳ２２０）。

次に、アグリゲートファイル管理機構８は、ｉｎｏｄｅが有効か、アグリゲートファイル１０で持っている情報が古くないかを確認する（ステップＳ２０４）。ファイルが他のアグリゲートファイル１０と多次元化（多重登録）されていたり、ハードリンクが設定されていたりする場合、そのまま削除してしまうと困るケースも考えられるからである。

上述したファイルとディレクトリのＬＯＣＫがすべて取れ、ｉｎｏｄｅの有効性を確認できた場合、アグリゲートファイル管理機構８は、データブロック情報１２を参照し、すべてのデータブロックを未使用に戻す（ステップＳ２０５）。具体的な処理は、ファイルシステムによって異なる。未使用領域がビットマップ方式で管理されているファイルシステムの場合は、ビットマップを落として未使用にすればよい。この場合も、アグリゲートファイル１０のデータブロック情報１２をあらかじめソートしておけば、ビットマップをまとめて書き換えることができる。

一方、未使用領域がＢ−Ｔｒｅｅ方式で管理されているファイルシステムの場合は、Ｂ−Ｔｒｅｅに繋げる処理を行う。Ｂ−Ｔｒｅｅの場合には、一般にＥｘｔｅｎｔという単位でデータブロックが管理されている。Ｅｘｔｅｎｔとは１．データのファイル内オフセット、２．スタートブロック番号、３．ブロック数、の３つのフィールドを持つデータブロック管理形式である。データブロックを個々に管理するのではなく、スタートブロック番号＋ブロック数なので可変長の連続ブロックを１つのＥｘｔｅｎｔで管理できる。この場合も、アグリゲートファイル１０のデータブロック情報１２に対し、Ｅｘｔｅｎｔのマージを行っておくことで、個々のファイルではＥｘｔｅｎｔが分割（フラグメント）されているがファイルグループとすれば連続しているケースがありうるため、Ｅｘｔｅｎｔ数が減り、Ｂ−Ｔｒｅｅにつなげる処理も高速にすることができる。

空き領域を戻す処理が終わったら、アグリゲートファイル管理機構８は、ｉｎｏｄｅ情報１１に従いｉｎｏｄｅを未使用にする（ステップＳ２０６）。ｉｎｏｄｅはたいていビットマップで管理されているので、まとめて書き換えができる。ｉｎｏｄｅの処理が終わったら、アグリゲートファイル管理機構８は、親ディレクトリから該当ｉｎｏｄｅエントリを削除し（ステップＳ２０７）、最後に取っていたＬＯＣＫを解放して（ステップＳ２０８）、終了となる（ステップＳ２０９）。

次に、上記アグリゲートファイルを用いることにより達成される、自由度の高いファイルのグループ化と、多次元的なグループ化（多次元性）について説明する。ファイルのグルーピングは、特許文献２にも記載されているように、例えば、「ユーザＡが所有者になっているファイル」や「プロジェクトＢのファイル」や「拡張子ＸＸのファイル」のようなものが考えられる。このようにある特定の属性を持つファイルの集まり（ファイルグループと呼ぶ。）は、特定のディレクトリ配下に固まっているとは限らない。また、複数のファイルグループに属するファイルも当然ありうる。

上記説明したとおり、本発明によれば、属性Ａ、Ｂを持つファイルを、それぞれの属性のアグリゲートファイルに登録することが可能となり、グルーピングの自由度、多次元性を損なうことなく、一括管理を行うことが可能となる。このようにアグリゲートファイル毎に属性を与え、一括管理できるという特徴は、冒頭に既存技術として述べたループバックマウント、アーカイブファイル（ＴＡＲ）と、本発明が決定的に異なる点でもある。

なお、多次元化され、単独のファイルが複数のアグリゲートファイル１０に登録されている場合、１つのアグリゲートファイル１０で削除された場合に、どう対応するかは複数の考え方がある。

ハードリンク的な考え方をすれば、すべてのアグリゲートファイル１０から削除された場合に、実ファイルを削除するという動きになる。例えば、実ファイル（ｉｎｏｄｅ内）にリンクカウンタを持っておき、いくつのアグリゲートファイル１０で管理されているかカウントしておくことで、すべてのアグリゲートファイル１０から削除されたことを確認することが可能となる。

多次元化されていても１つのアグリゲートファイル１０から削除されたら削除してしまうという考え方もある。ある属性のファイルはすべて削除したい時に、別の属性も持っているから削除しないというのは不都合な場合が考えられる。この場合、他のアグリゲートファイル１０からも削除しなければならないので、実ファイル（ｉｎｏｄｅ内）にアグリゲートファイル１０に対する逆リンクを設定しておくことが考えられる。例えば、あるファイルが、１つのアグリゲートファイル１０から削除されるときには逆リンクをたどって他のアグリゲートファイル１０からも削除していくような動作となる。

また、別の方法として、実ファイルの削除はしてしまうが他のアグリゲートファイル１０から削除しないでおく方式もある。その場合、アグリゲートファイル１０に含まれていても実際には他のアグリゲートファイル１０からの削除の時点で実ファイルが削除されているケースがありえる。もしｉｎｏｄｅやデータブロックが他のファイルで再利用されていたら、削除によりデータ破壊をしてしまう可能性がある。その問題に対応するために、前述のようにｉｎｏｄｅ情報１１を実ｉｎｏｄｅとつき合わせて有効なことをチェックする必要がある。

上記した方式のいずれを採用すべきかは、冒頭に述べたサービスレベルの問題でもあり、ファイルシステムの用途や、取り扱われるデータの種類や、ライフサイクルによって適宜選択することが可能である。

以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、上記した実施形態では、アグリゲートファイル１０はディレクトリに属さないため通常のファイルシステムＡＰＩからは見ることができないものとして説明したが、アグリゲートファイル用のディレクトリを作ってファイルシステムＡＰＩから見せるようにしてもよい。

その場合、アグリゲートファイルを、ファイルとしてではなくディレクトリとして見せることができる。図３を見ればわかるように、アグリゲートファイル１０とディレクトリｉｎｏｄｅ１５は、ｉｎｏｄｅ情報１１をリストとして持っている点では同じである。よって、図４のファイルシステムコア７にアグリゲートファイル１０をディレクトリと解釈させ、アグリゲートファイル１０に登録されたファイルを、実ファイルの一覧と同等に表示するように変更を加えればよい。このようにすると、ある属性を持ったファイルをディレクトリとして一覧でき、ファイルの検索や網羅性チェックに役立てることができる。

また、上記した実施形態では、索引情報としてｉｎｏｄｅを持つＵＮＩＸ（登録商標）系のシステムを前提として説明したが、同等のファイルに割り当てられたブロック情報をまとめて持つ方式（索引割付け方式）を採用するファイルシステム全般に適用することが可能である。

本発明の第１の実施形態のシステム構成図である。 アグリゲートファイルの構造を説明するための図である。 アグリゲートファイルとファイルｉｎｏｄｅ、ディレクトリｉｎｏｄｅの関係を説明するための図である。 本実施形態に係るファイルシステム周辺の機能ブロック図である。 アグリゲートファイル管理テーブルの例である。 本発明の第１の実施形態に係るファイルシステムにおいて、新たにファイルが作成されたときの動作を表したフローチャートである。 本発明の第１の実施形態に係るファイルシステムにおいて、アグリゲートファイルを指定した一括コピーコマンドが実行されたときの動作を表したフローチャートである。 データブロック変換テーブルの例である。 本実施形態に係るファイルシステムにおいて、アグリゲートファイルを指定した一括削除コマンドが実行されたときの動作を表したフローチャートである。

符号の説明

１ａ、１ｂ ストレージ
３、３ａ、３ｂ ファイルシステム
４、４ａ、４ｂ ディスク
５ ファイルグループ
６ ネットワーク
７ ファイルシステムコア（ファイルシステム制御部）
８ アグリゲートファイル管理機構
９ アグリゲートファイル管理テーブル
１０ アグリゲートファイル
１１ ｉｎｏｄｅ情報
１２ データブロック情報
１３、１４ ファイルｉｎｏｄｅ
１５ ディレクトリｉｎｏｄｅ
２０ ユーザアプリケーション

Claims (16)

1. 複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルにより、該仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理する仮想集合ファイル管理機構を有し、
   前記仮想集合ファイル管理機構は、前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を行うこと、
   を特徴とするファイルシステム。
2. 前記仮想集合ファイル管理機構は、前記仮想集合ファイルの作成又は更新時に、前記複数のファイルのデータブロック情報の並び替えを行うことを特徴とする請求項１に記載のファイルシステム。
3. 前記仮想集合ファイル管理機構は、前記仮想集合ファイルに対するコピーコマンドが実行された場合、前記仮想集合ファイルのデータブロック情報を用いて、複数ファイルのデータブロックをまとめて読み出すことを特徴とする請求項２に記載のファイルシステム。
4. 前記仮想集合ファイルに対するコピーコマンドが実行された場合、前記仮想集合ファイル管理機構は、コピー元のファイルのデータブロック情報と、コピー先のデータブロック情報とを関連付けたデータブロック変換テーブルを作成し、
   前記データブロック変換テーブルを参照して、前記仮想集合ファイルに記述された個々のファイルのコピー先のインデックス情報に格納されているデータブロックのリストの書き換えを行う請求項３に記載のファイルシステム。
5. 前記仮想集合ファイルに対するコピーコマンドが実行された場合、前記仮想集合ファイル管理機構は、コピー元のデータブロック情報と、コピー先のデータブロック情報とを関連付けたデータブロック変換テーブルを作成し、
   前記仮想集合ファイルに記述された個々のファイルのインデックス情報のコピーを行ってから、任意のタイミングで、前記データブロック変換テーブルを参照して前記インデックス情報に格納されているデータブロックのリストの書き換えを行う請求項３に記載のファイルシステム。
6. 前記仮想集合ファイルに対するコピーコマンド実行に、前記データブロック情報の書き換えを行うか否かを選択可能であり、前記データブロック情報の書き換えが完了しているか否かを、各ファイルのインデックス情報内に記録する請求項４又は５に記載のファイルシステム。
7. 前記仮想集合ファイル管理機構は、前記仮想集合ファイルに対する削除コマンドが実行された場合、前記仮想集合ファイルのデータブロック情報とインデックス番号情報を用いて、複数ファイルのデータブロックとインデックス情報をまとめて削除することを特徴とする請求項１乃至６いずれか一に記載のファイルシステム。
8. 前記仮想集合ファイル管理機構は、グループ化するファイルの条件の指定を受け付けると、該条件を満たすファイルを探索して仮想集合ファイルを作成する動作を行う請求項１乃至７いずれか一に記載のファイルシステム。
9. 前記仮想集合ファイル管理機構は、新規ファイルが作成されると、既存の仮想集合ファイルに追加すべきか否かを確認し、追加すべきと判断した仮想集合ファイルに前記新規ファイルに関する情報を追加する動作を行う請求項１乃至８いずれか一に記載のファイルシステム。
10. 前記仮想集合ファイル管理機構は、既存の仮想集合ファイルに登録されているファイルの更新が行われると、該当する仮想集合ファイルの当該ファイルのデータブロック情報を更新する動作を行う請求項１乃至９いずれか一に記載のファイルシステム。
11. 前記仮想集合ファイルに記述されたファイルの総サイズを計算し、前記仮想集合ファイルに記述する請求項１乃至１０いずれか一に記載のファイルシステム。
12. 前記仮想集合ファイルをファイルの一覧として解釈し、実ファイルの一覧と同等に表示する機能を有する請求項１乃至１１いずれか一に記載のファイルシステム。
13. 複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルにより、該仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理する仮想集合ファイル管理機構としてコンピュータを機能させ、
    前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を前記コンピュータに実行させるプログラム。
14. 前記仮想集合ファイル管理機構として機能するコンピュータに、前記仮想集合ファイルの作成又は更新時に、前記複数のファイルのデータブロック情報の並び替えを行わせることを特徴とする請求項１３に記載のプログラム。
15. 所定の記憶装置に保存されたファイルの管理方法であって、
    コンピュータに、複数のファイルのファイルデータを格納しているデータブロックのアドレスのリスト（データブロック情報）と前記データブロック情報を格納しているインデックス情報のアドレスのリスト（インデックス番号情報）とを集めた仮想集合ファイルを作成させ、
    前記仮想集合ファイルに対して所定のファイル操作コマンドが実行された場合に、前記コンピュータに、前記仮想集合ファイルの情報を用いて、前記仮想集合ファイルに記述された複数のファイルに対して、前記コマンドに応じた一括操作を実行させ、
    前記仮想集合ファイルに記述された複数のファイルを仮想的な一つのファイルとして管理させることを特徴とするファイルの管理方法。
16. 前記コンピュータに、前記仮想集合ファイルの作成又は更新時に、前記複数のファイルのデータブロック情報の並び替えを行わせることを特徴とする請求項１５に記載のファイルの管理方法。

Images