JPH07319750A - 分散ファイルシステムのキャッシュ管理方法 - Google Patents

Abstract

(57)【要約】 【目的】キャッシュの最新性を効率的に保証できる分散
ファイルシステムのキャッシュ管理方法を提供する。 【構成】クライアントは、ブロック単位にファイルをキ
ャッシングし(４０４)、キャッシングしたブロックの状
態を第一の状態とする（４１６）。他のクライアントに
よってファイルが更新された場合、更新されたファイル
に属するブロックの状態を第二の状態に変更する（４０
６）。第二の状態にあるブロックをアクセスする（４１
８）際には、ファイルサーバにそのブロックの最新性を
問い合わせ（４０８）、最新でない場合は、そのブロッ
クを再キャッシング（４１）する。 【効果】第一の状態にあるブロックの最新性は常に保証
されるので、アクセスする前にブロックの最新性をファ
イルサーバに問い合わせる必要がない。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ファイルサーバが保管
するファイルをクライアントにキャッシングする分散フ
ァイルシステムにおけるキャッシュ管理方法に関する。

【０００２】

【従来の技術】多くの分散ファイルシステムでは、ファ
イルサーバが保管するファイルをクライアントにキャッ
シングすることでファイルアクセスを高速化している。
クライアントは、アクセスするファイルを予め主記憶や
ディスク装置にキャッシングしておき、キャッシュに存
在するファイルのコピーにアクセスすることで、ファイ
ルアクセスを高速化する。しかし、ファイルをキャッシ
ングした後に、他のクライアントがファイルを更新する
と、キャッシュの内容が古くなる。従って、このような
状況に備えて、キャッシュの最新性を保証する機能が必
要である。

【０００３】本発明に近い従来技術として、アンドリュ
ー（Andrew）分散ファイルシステムがある。Andrewで
は、ユーザやアプリケーションプログラム（ＡＰ）がフ
ァイルアクセスを要求すると、クライアントは、アクセ
スするファイル全体をローカルディスクにキャッシング
し、キャッシュに存在するファイルのコピーにアクセス
する。アクセス終了後も、ファイルのコピーをローカル
ディスクに残すことで、２回目以降のアクセスを高速化
する。

【０００４】ファイルサーバは、各ファイルに対して、
そのファイルをキャッシングしているクライアントの集
合を記録している。ファイルが更新された場合、ファイ
ルサーバは、そのファイルをキャッシングしている各ク
ライアントにキャッシュの無効化を通知する。通知を受
けたクライアントは、キャッシュを無効化し、次にアク
セスする際に最新のファイルを再キャッシングする。

【０００５】キャッシュの最新性は常に保証されるの
で、クライアントは、キャッシュにアクセスする前にキ
ャッシュの最新性をファイルサーバに問い合わせる必要
がない。従って、Andrewのキャッシュ管理方法は、ファ
イルアクセスの応答性向上や、ネットワークやファイル
サーバの負荷軽減に有効である。

【０００６】本発明に近いもう一つの従来技術として、
デコラム(DEcorum）分散ファイルシステムがある。DEco
rum では、クライアントは、ファイルを固定長ブロック
単位に分割してキャッシングする。ファイルサーバは、
クライアントがキャッシングしているブロックを記録し
ており、ファイルが更新された場合、更新された範囲の
ブロックの無効化をクライアントに通知する。

【０００７】Andrewについては、ジェイ エイチ ハワ
ード エトアル“スケール アンドパーフォーマンス
インナ ディストリビューテッド ファイル システ
ム”(J.H.Howard et al.,“Scale and Performance in
a Distributed File System", ACM Transactions on Co
mputer Systems Vol.6, NO.1, pp.55−81(1988))に記載
されている。DEcorum については、エム エル カザー
エトアル“デコラムファイル システム アーキテク
チュアル オーバービュー”（M.L.Kazar etal.,“DEco
rum File System Architectural Overview”．USENIX
ConferenceProceedings, pp.151−164 (1990 Summer)に
記載されている。

【０００８】

【発明が解決しようとする課題】Andrewでは、ファイル
全体をキャッシングするので、クライアントのキャッシ
ュサイズより大きなファイルはキャッシングできない。
また、ファイルの一部分だけが更新された場合でも、フ
ァイル全体を無効化するので、クライアントは、次にア
クセスする際に、更新された部分だけでなくファイル全
体を再キャッシングする必要がある。

【０００９】DEcorum では、ファイルを固定長ブロック
単位に分割してキャッシングできる。しかし、ファイル
サーバは、クライアントのキャッシング状態を、ファイ
ル単位ではなくブロック単位に記録する必要がある。こ
の結果、ファイルのブロック数や、クライアントの個数
が多くなると、ファイルサーバが記録すべき情報量が大
きくなる。

【００１０】本発明の目的は、ファイルの一部分だけを
キャッシングでき、キャッシュの最新性を効率的に保証
できる分散ファイルシステムのキャッシュ管理方法を提
供することにある。

【００１１】

【課題を解決するための手段】本発明によれば、ファイ
ルサーバは、一つのファイルを複数のブロックに分割
し、クライアントは、ブロック単位にファイルをキャッ
シングする。

【００１２】クライアントは、キャッシングしている各
ブロックの状態を、ブロックが最新であることを表す第
一の状態と、ブロックの最新性が疑わしいことを表す第
二の状態とに分類する。ファイルサーバは、各ファイル
Ｆに対して、ファイルＦに属するブロックをキャッシン
グしており、かつキャッシングしているブロックのうち
少なくとも一つは第一の状態であるクライアントの集合
ＣＬ（Ｆ）を記録している。

【００１３】クライアントは、アクセスするブロックが
キャッシュに存在しない場合は、ファイルサーバからそ
のブロックをキャッシングし、ブロックの状態を第一の
状態とする。アクセスするブロックがキャッシュに存在
するが、ブロックの状態が第二の状態である場合は、フ
ァイルサーバに対してブロックの最新性を問い合わせ、
最新であることが判明した時は、ブロックの状態を第一
の状態に変更し、最新でないことが判明した場合は、ブ
ロックを再キャッシングし、再キャッシングしたブロッ
クの状態を第一の状態とする。

【００１４】あるクライアントがファイルＦを更新した
時に、ファイルサーバは、前記クライアント集合ＣＬ
（Ｆ）に含まれる各クライアントに対して、ファイルＦ
が更新されたことを通知する。通知を受けたクライアン
トは、ファイルＦに属するブロックの状態を第二の状態
に変更する。

【００１５】

【作用】クライアント１は、ファイルＦに属するブロッ
クをキャッシングする時に、キャッシングしたブロック
の状態を第一の状態とする。ファイルサーバが記録する
クライアント集合ＣＬ（Ｆ）は、クライアント１を含む
ので、ファイルＦが更新された時に、クライアント１
は、ファイルＦに属するブロックの状態を第二の状態に
変更することができる。これにより、第一の状態にある
ブロックの最新性は常に保証されるので、クライアント
１は、キャッシュに存在する第一の状態にあるブロック
にアクセスする前に、その最新性をファイルサーバに問
い合わせる必要がない。

【００１６】クライアント１は、ファイルＦが更新され
た時に、キャッシュに存在するファイルＦに属するブロ
ックを第二の状態に変更する。そして、次にアクセスす
る際に、ブロックの最新性をファイルサーバに問い合わ
せる。これにより、ファイルＦが更新された時に、ファ
イルＦ全体を無効化する必要がない。更新されたブロッ
クだけを再キャッシングすることができる。

【００１７】ファイルサーバは、各ファイルＦに対し
て、クライアント集合ＣＬ（Ｆ）を記録する。従って、
ファイルサーバが記録すべき情報量は、Andrewと同等で
あり、クライアントのキャッシング状態をブロック単位
に記録するDEcorum に比べて少量である。

【００１８】この三つの効果により、ファイルの一部分
だけをキャッシングでき、キャッシュの最新性を効率的
に保証できる分散ファイルシステムのキャッシュ管理方
法を提供できる。

【００１９】

【実施例】図２は、本発明を実施した分散ファイルシス
テムのブロック図を示している。ネットワーク３００
に、ファイルサーバ２００と、ｎ台のクライアント１０
０が接続している。例えば、ファイルサーバ２００には
高性能ワークステーションを、クライアント１００には
パーソナルコンピュータを利用する。

【００２０】ファイルサーバ２００は、ファイルＡ，Ｂ
をはじめとする多数のファイルをディスク装置２５０に
保管する。ファイルサーバ２００は、ファイルを固定長
（例えば、１００ＫＢ）のブロックに分割する。各ブロ
ックに対してバージョン番号を付加し、ブロックを更新
する度に、そのブロックのバージョン番号をインクリメ
ントする。

【００２１】クライアント１００は、ブロック単位にフ
ァイルをキャッシングし、ディスク装置１５０に保管す
る。そして、キャッシングした各ブロックに対して、キ
ャッシングした時点のバージョン番号とキャッシュ状態
とを対応づける。各ブロックのキャッシュ状態は、ブロ
ックが最新であることを表す第一の状態と、ブロックの
最新性が疑わしいことを表す第二の状態とに分類され
る。

【００２２】ファイルサーバ２００は、キャッシング状
態記録テーブル２１０を主記憶上に保持している。キャ
ッシング状態記録テーブル２１０は、図３に示すよう
に、ファイル名欄２１１とクライアント集合欄２１２か
らなり、各ファイルＦに対して、以下の条件を満たすク
ライアントの集合ＣＬ（Ｆ）を記録する。

【００２３】ファイルＦのブロックをキャッシングして
おり、キャッシングしているファイルＦのブロックのう
ち少なくとも一つは第一の状態にあるクライアントであ
る。

【００２４】例えば、クライアント１は、ファイルＢの
ブロック２〜４をキャッシングしており、ブロック２は
第一の状態にある。従って、クライアント１は、ファイ
ルＢのクライアント集合ＣＬ（Ｂ）に登録されている。

【００２５】以下、図１と図４ないし図７に示すフロー
チャートを用いて、本実施例のキャッシュ管理方法を詳
細に説明する。

【００２６】図１の（ａ）に示すフローチャートは、ク
ライアント１００がファイルＦにアクセスする時の処理
手順を示している。まず、ユーザ或いはアプリケーショ
ンプログラムが指定したアクセス範囲から、実際にアク
セスするブロックの番号ｎを決定する（ステップ４０
２）。そして、ファイルＦのブロックｎがキャッシュに
存在するかチェックする（ステップ４０４）。キャッシ
ュに存在しない場合は、ファイルＦの第ｎブロックをキ
ャッシングし（ステップ４１４）、キャッシングしたブ
ロックの状態を第一の状態に設定（ステップ４１６）し
た後で、ブロックにアクセスする（ステップ４１８）。

【００２７】アクセスするブロックがキャッシュに存在
する場合は、ブロックの状態を調査する（ステップ４０
６）。ブロックが第一の状態である場合は、キャッシュ
中のブロックにアクセスする（ステップ４１８）。

【００２８】アクセスするブロックが第二の状態である
場合は、ブロックの最新性をファイルサーバ２００に問
い合わせる（ステップ４０８）。ブロックが最新である
場合は、ブロックの状態を第一の状態に設定し（ステッ
プ４１６）、ブロックにアクセスする（ステップ４１
８）。

【００２９】ブロックが最新でない場合は、ブロックを
無効化し（ステップ４１２）、再キャッシングする（ス
テップ４１４）。再キャッシングしたブロックの状態を
第一の状態に設定し（ステップ４１６）、ブロックにア
クセスする(ステップ４１８)。

【００３０】図４に示すフローチャートを用いて、ブロ
ックのキャッシング処理（ステップ４１４）を詳細に説
明する。まず、クライアント１００は、ファイルＦのブ
ロックｎの転送をファイルサーバに要求する（ステップ
４２４）。要求を受信したファイルサーバ２００は、フ
ァイルＦのクライアント集合ＣＬ（Ｆ）に、クライアン
トのホスト名を登録し（ステップ４２８）、ファイルＦ
のブロックｎを、現在のバージョン番号と共に、クライ
アントに転送する（ステップ４３０）。クライアント１
００は、ファイルサーバ２００から得たブロックを、バ
ージョン番号と共にディスク装置１５０に保管する（ス
テップ４２６）。

【００３１】図５に示すフローチャートを用いて、ファ
イルＦの第ｎブロックの最新性をファイルサーバ２００
に問い合わせる処理（ステップ４０８）を詳細に説明す
る。まず、クライアント１００は、ディスク装置１５０
に保管されているブロックのバージョン番号Ｘを得る
（ステップ４３２）。次に、ファイルサーバ２００に、
ファイル名Ｆ，ブロック番号ｎ，バージョン番号Ｘを送
信して(ステップ４３４)、判定結果を受信する（ステッ
プ４３６）。

【００３２】ファイルサーバ２００は、ブロックの現在
のバージョン番号Ｙを得る（ステップ４３８）。そし
て、ＸとＹを比較することで、クライアントがキャッシ
ングしているブロックの最新性を判定する（ステップ４
４０）。ＸとＹが等しい場合は、ファイルＦのクライア
ント集合ＣＬ（Ｆ）に、クライアント１００のホスト名
を登録し（ステップ４４２）、クライアント１００に、
ブロックが最新であることを通知する（ステップ４４
４）。ＸとＹが異なる場合は、クライアント１００に、
ブロックが最新でないことを通知する（ステップ４４
６）。

【００３３】図１の（ｂ）と図６に示すフローチャート
を用いて、ファイルＦが更新された時にファイルサーバ
２００が行う処理を説明する。ファイルサーバ２００
は、更新されたブロックのバージョン番号をインクリメ
ントする（ステップ４５０）。次に、キャッシング状態
記録テーブル２１０に登録されているファイルＦのクラ
イアント集合ＣＬ（Ｆ）を得て、ＣＬ（Ｆ）に含まれる
各クライアント１００に対して、ファイルＦが更新され
たことを通知する（ステップ４５２）。最後に、ファイ
ルＦのクライアント集合ＣＬ（Ｆ）を空にする（ステッ
プ４５４）。

【００３４】ファイルサーバ２００からファイルＦの更
新を通知されたクライアント１００は、ディスク装置１
５０にキャッシングされているファイルＦのブロックを
第二の状態に変更する（ステップ４２０）。

【００３５】クライアント１００は、ブロック単位にフ
ァイルをキャッシングし、キャッシングしたブロックの
状態を第一の状態とする（ステップ４１６）。他のクラ
イアント１００によってファイルが更新された場合、更
新されたファイルに属するブロックの状態を第二の状態
に変更する（ステップ４２０）。従って、第一の状態に
あるブロックの最新性は常に保証される。

【００３６】クライアント１００は、第一の状態にある
ブロックにアクセスする前に、その最新性をファイルサ
ーバ２００に問い合わせる必要がない。従って、本発明
は、ファイルアクセスの応答性向上や、ネットワーク３
００やファイルサーバ２００の負荷軽減に有効である。

【００３７】第二の状態にあるブロックにアクセスする
際に、クライアント１００は、ブロックの最新性をファ
イルサーバ２００に問い合わせる（ステップ４０８）。
そして、最新でない場合だけ、ブロックを再キャッシン
グする（ステップ４１４）。従って、キャッシングして
いるファイルが更新された場合でも、クライアント１０
０は、ファイル全体を無効化しない。更新されたブロッ
クだけを再キャッシングするので効率的である。

【００３８】クライアント１００は、キャッシングした
ファイルをディスク装置１５０に保管するので、シャッ
トダウンした後もキャッシュの内容は保存される。再立
ち上げ時にキャッシュを再利用することで、ファイルア
クセスの応答性を向上することができる。しかし、シャ
ットダウンしている間に、キャッシングしているファイ
ルが更新される可能性がある。従って、第一の状態にあ
るブロックの最新性は保証できない。

【００３９】図７に示すフローチャートを用いて、クラ
イアント１００がシャットダウンする時に行う処理を説
明する。クライアント１００は、ディスク装置１５０に
保管されているすべてのブロックを第二の状態に設定
（ステップ４５６）してから、シャットダウン手続きを
実行する（ステップ４５８）。

【００４０】クライアント１００は、ディスク装置１５
０に保存されていたキャッシュにアクセスする前に、キ
ャッシュの最新性をファイルサーバ２００に問い合わせ
る（図１のステップ４０８）。これにより、古いブロッ
クをアクセスすることを防止できる。

【００４１】

【発明の効果】本発明によれば、クライアントは、ブロ
ック単位にファイルをキャッシングし、キャッシングし
たブロックの状態を第一の状態とする。第一の状態にあ
るブロックの最新性は常に保証されるので、アクセスす
る前にブロックの最新性をファイルサーバに問い合わせ
る必要がない。

【００４２】他のクライアントによってファイルが更新
された場合、更新されたファイルに属するブロックの状
態を第二の状態に変更する。第二の状態にあるブロック
をアクセスする際には、ファイルサーバにそのブロック
の最新性を問い合わせ、最新でない場合は、そのブロッ
クを再キャッシングする。従って、ファイルが更新され
た場合でも、更新されたブロックだけを再キャッシング
する。

【００４３】これにより、ファイルの一部分だけをキャ
ッシングでき、キャッシュの最新性を効率的に保証でき
る分散ファイルシステムのキャッシュ管理方法を提供で
きる。

【図面の簡単な説明】

【図１】クライアントで行われるキャッシュ管理方法を
示すフローチャート。

【図２】本発明を適用した分散ファイルシステムのブロ
ック図。

【図３】キャッシング状態記録テーブルの構成を示す説
明図。

【図４】キャッシング処理を示すフローチャート。

【図５】ブロックの最新性を判定する方法を示すフロー
チャート。

【図６】ファイルが更新された時にファイルサーバが実
行する処理を示すフローチャート。

【図７】クライアント１００のシャットダウン処理を示
すフローチャート。

【符号の説明】

１００…クライアント、１５０…ディスク装置、２００
…ファイルサーバ、２１０…キャッシング状態記録テー
ブル、２５０…ディスク装置、３００…ネットワーク。

フロントページの続き (72)発明者 庄司 直史 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 小林 敦 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内

Claims (4)

【特許請求の範囲】
1. 【請求項１】複数のファイルを保管するファイルサーバ
   と、前記ファイルに遠隔アクセスするクライアントがネ
   ットワークで接続した構成を持ち、前記ファイルサーバ
   は、一つのファイルを複数のブロックに分割し、前記ク
   ライアントは、ブロック単位に前記ファイルをキャッシ
   ングする分散ファイルシステムに適用するキャッシュ管
   理方法において、 前記クライアントは、キャッシングしている前記各ブロ
   ックの状態を、ブロックが最新であることを表す第一の
   状態と、前記ブロックの最新性が疑わしいことを表す第
   二の状態とに分類し、 アクセスするブロックがキャッシュに存在しない場合
   は、前記ファイルサーバから前記ブロックをキャッシン
   グして前記第一の状態とし、アクセスするブロックが前
   記キャッシュに存在するが、前記ブロックの状態が前記
   第二の状態である場合は、前記ファイルサーバに対して
   前記ブロックの最新性を問い合わせ、最新であることが
   判明した時は、前記第一の状態に変更し、最新でないこ
   とが判明した場合は、再キャッシングして前記第一の状
   態とし、 他のクライアントによってファイルが更新された場合
   は、更新されたファイルに属するブロックの状態を前記
   第二の状態に変更することを特徴とする分散ファイルシ
   ステムのキャッシュ管理方法。
2. 【請求項２】請求項１において、前記ファイルサーバ
   は、各ファイルに対して、前記ファイルに属するブロッ
   クをキャッシングしており、キャッシングしているブロ
   ックのうち少なくとも一つは前記第一の状態である前記
   クライアントの集合を記録しており、あるクライアント
   がファイルを更新した時に、前記ファイルサーバは、前
   記集合に含まれる前記各クライアントに対して、ファイ
   ルが更新されたことを通知し、通知を受けた前記クライ
   アントは、更新されたファイルに属するブロックの状態
   を前記第二の状態に変更する分散ファイルシステムのキ
   ャッシュ管理方法。
3. 【請求項３】請求項１において、前記ファイルサーバ
   は、各ブロックに対してバージョン番号を付け、前記ブ
   ロックを更新する度に前記バージョン番号を更新し、前
   記クライアントは、前記キャッシュに存在する前記各ブ
   ロックに対して、前記ブロックを前記ファイルサーバか
   らキャッシングした時点のバージョン番号を対応づけ、
   前記第二の状態にあるブロックの最新性を前記ファイル
   サーバに問い合わせる際に、前記クライアントは、前記
   ブロックのバージョン番号を前記ファイルサーバに送信
   し、前記ファイルサーバは、現在のバージョンと比較す
   ることでブロックの最新性を判断する分散ファイルシス
   テムのキャッシュ管理方法。
4. 【請求項４】請求項１において、不揮発性記憶装置内に
   前記キャッシュを確保し、前記クライアントがシャット
   ダウンした後も前記キャッシュの内容を保存する分散フ
   ァイルシステムに適用し、前記クライアントは、シャッ
   トダウンする際に、前記キャッシュに存在するすべての
   ブロックの状態を第二の状態に変更する分散ファイルシ
   ステムのキャッシュ管理方法。