JP3450786B2 - 異なるデータファイルを調停する方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にコンピュー
タのための分散型ファイルシステムのフィールドに関連
するもので、より詳しくは、分散形計算機システム内部
の異なる記憶場所で存在する可能性があるファイルの異
なったバージョンの調停に関するものである。

【０００２】

【従来の技術】データファイルの記憶および検索のため
に、分散型ファイルシステムを使用することがコンピュ
ータシステムにとってますます共通化されている。この
傾向は、伝統的な集中化されたファイルシステムをディ
スクに密接に連結された単一コンピュータ上で実行する
アプリケーションプログラムのみにアクセス可能な磁気
ディスクに記憶されているデータファイルに置き換える
ものである。コンピュータの機能性が増加し、それらの
コストが低下することに伴い、全体的なコンピュータシ
ステムの性能は、データファイルのコピーが複数の記憶
場所に存在できるようにすることの恩恵を受けてきた。

【０００３】これらの分散型ファイルシステムの第一世
代の例は、ローカルファイルサーバに接続されたデスク
トップのワークステーションまたはパーソナルコンピュ
ータが関与する。デスクトップコンピュータ上のファイ
ルの記憶は、デスクトップコンピュータ上のプログラム
実行の速い実施を可能にする一方、ファイルサーバ上の
これらのファイルの存在は、データファイルシェアリン
グ、すなわち企業で使用される多くの分散アプリケーシ
ョンプログラムで要求される機能が提供される。

【０００４】より最近のシステムは、ポータブルコンピ
ュータを有しているモバイルユーザや、ワークステーシ
ョンでのユーザおよび組織の中に存在する中央のデータ
リポジトリー（中央データ格納庫）との間でのデータの
同種の調整を可能にする。分散型ファイルシステムにお
いては、一般的に、ある時間でファイルの少なくとも２
つの異なるバージョンが異なる記憶場所にあり、１つの
バージョンのみがシステムの全てのユーザによって使用
されるべき最新の、すなわち正しいバージョンであり得
る。この可能性のため、ファイルシステムの一貫性を保
証するためのメカニズムが分散型ファイルシステムに使
用される。

【０００５】ファイルシステムは、ファイルの正しいバ
ージョンがアプリケーションプログラムに提供されるな
らば、システムにおける旧式すなわち正しくないバージ
ョンが存在することがあっても一貫性が保たれる。ファ
イルシステムの一貫性(coherence)を保持することへの
１つのアプローチは、直接的なユーザ制御のファイル転
送である。

【０００６】このアプローチの１つの例は、電子メール
である。他の例は、カーミット（Kermit）として知られ
ている公衆ファイル転送プロトコルとワシントン州のト
ラベリングソフトウェア社（Traveling Software, In
c.）のラップリンク（Laplink）として知られている製
品を含む。Laplinkプログラムは、主にポータブルコン
ピュータとデスクトップコンピュータまたは他のポータ
ブルコンピュータのいずれかとの間のファイルを転送す
るために使われる。これらのファイル転送手順の全て
は、ファイル転送プロセス上のコンピュータの重要な制
御をユーザに与える。

【０００７】しかし、一般的に、それらは特にファイル
システムの一貫性の問題向けに特注されたものでない。
ユーザには、ファイルのバージョン間の競合を予期し、
競合が生じる場合にそのような競合を検出し、現在用い
られていないバージョンをファイルから除去し、およ
び、ファイル更新が必要とされるシステムのポイントに
確実に適宜配布されるようにする実質的な責務が負われ
ている。

【０００８】一貫性技術のもう一つの種類は、データフ
ァイルのシャドウイングや即時の更新を用いる。そのよ
うな技術は、ネットワークファイルシステム（ＮＦＳ）
のようなシステムに使われる。これらの技術を用いてい
るシステムにおいては、ファイル更新は直接に全ての記
憶場所へ同報され、いくつかのケースにおいて、更新さ
れているファイルの使用は全てのコピーが更新されるま
で妨げられる場合もある。この保守的なアプローチは、
一貫性を保持することへの競合の可能性を除去し、主に
ユーザに対して平明（透過性のあるもの）である。しか
しながら、それは同様にシステム性能を下げ、ユーザ制
御の相対的な欠如に関連した他の問題を引き起こす傾向
がある。さらに、その技術は、より幅広いコンピュータ
システムに断続的にしか接続しないモバイルユーザには
それほど適していない。

【０００９】一貫性技術の３番目の一般的な種類は、コ
ンピュータシステム内部のデータファイルのための「特
別な記憶場所」の存在に依存する。例えば、単一のファ
イルサーバが、ファイルの正しいバージョンが得られる
ことができるシステムにおける唯一のポイントであるか
もしれない。したがって、ファイルサーバは全てのファ
イル調停（reconciliation）に関与しなければならな
い。

【００１０】よく知られた例は、ワシントン州のマイク
ロソフト社によって配布されたウインドウズ９５オペレ
ーティングシステムに含められる「ブリーフケース」と
して知られているプログラムに具体的に表現される。ブ
リーフケースは、デスクトップのパーソナルコンピュー
タとポータブルコンピュータの間のデータファイルの一
貫性を保持するために使用することができる。

【００１１】デスクトップのマシンは、主たるデータフ
ァイル記憶サイトとして取り扱われ、ポータブルコンピ
ュータはデスクトップコンピュータから得られたファイ
ルのコピーを一時的に保つ「ブリーフケース」として扱
われて、ユーザがオフィス環境に戻った時点で、コピー
すなわち更新されたバージョンがデスクトップコンピュ
ータに返送される。

【００１２】調整するために特別な記憶場所を要求する
システムは、その特別な記憶場所が壊れているかまたは
アクセス不可能である場合にファイルを更新する。ＣＯ
ＤＡとBayouのようなバージョンベクトルシステムは、
各サイトで昇順のバージョン番号を生成し、新規のバー
ジョン番号を作成または更新する各オブジェクトと関連
させることによって、特別な記憶場所を使用することを
避けている。

【００１３】ジャーナルエントリーは、更新を実行した
サイトのＩＤと更新のためのそのサイトのバージョン番
号を含む。各最新のオブジェクトは、個々のサイトのバ
ージョン番号のサイトによってインデックス付けされる
ベクトルと関連させられる。

【００１４】ベクトル比較は、３つの解のうちの１つに
結びつくことができる。すなわち、１つのベクトルの全
てのコンポーネントは他のベクトルの対応するコンポー
ネント以下、その逆、あるいはそれよりも小さいものも
大きいものもある。最後のケースが、矛盾している更新
を検出するために使用される。

【００１５】また、データファイルの一貫性問題への他
のアプローチは、１９９７年２月４日に発行された米国
特許第５,６００,８３４号（発明者：ハワード）に記載
されており、ケンブリッジ・マサチューセッツの三菱電
機情報技術センターアメリカ社に譲渡された。このファ
イル調停技術には、自動メカニズムおよびユーザ制御の
組合せを使用するものと記載されている。

【００１６】調停技術は、システム全体におけるファイ
ルの作成、変更及び削除の履歴が記録されている一組の
ジャーナルファイルを使用しており、各ジャーナルファ
イルは、特定のサイトまたは記憶場所に関係する履歴の
部分を保持する。この明細書中で使用されているよう
に、用語「サイト」は、ハードディスクかフロッピーデ
ィスクのような特定の記憶媒体の上の作業ディレクトリ
とそのサブディレクトリを意味する。

【００１７】米国特許５,６００,８３４号に記述された
調停プロセスは、明らかにユーザによって遂行されて制
御され、ユーザによって指定されたサイトに存在するフ
ァイルと現行のディレクトリのバージョンを調停するよ
う動作する。そのプロセスは、各ファイルまたはディレ
クトリの単一の最新のバージョンがあるかどうかを判定
するために、ジャーナルファイルの中のサイトディレク
トリとバージョンエントリーを使用する。もし、それが
あるならば、そのバージョンを、調停に関係する他のサ
イトへコピーする。また、プロセスは、ファイルの異な
るバージョンが共通の以前のバージョンから派生したと
思えるシステムの中に存在するとき、これらの存在が示
された競合に対しチェックする。

【００１８】一般的に、このプロセスは、関連するサイ
トでの各々のファイルの生成/変更/削除履歴を復元する
ために、各々のジャーナルにおけるバージョンエントリ
ーのシーケンスを「結合する（merging）」ことによっ
て機能する。

【００１９】日時の値は、この結合プロセスにおいて異
なったジャーナルからのイベントを順序立てて配置する
ために、ジャーナルにおける「タイムスタンプ」として
言及され使用される。

【００２０】また、このプロセスは、与えられたサイト
が調停に関連した最新の時間を識別するために使用され
る「既知のサイト」エントリーにおけるタイムスタンプ
も含める。この情報は、間違いがなければジャーナルフ
ァイルの際限のない成長を妨げるためにジャーナルファ
イルからバージョンエントリーを除去するのに時折使用
される。

【００２１】

【発明が解決しようとする課題】しかしながら、米国特
許５，６００，８３４号の調停プロセスで記述されたよ
うなタイムスタンプの使用は、異なるコンピュータの間
の日時の不完全なトラッキングのため、時折望まれてい
ない結果を引き起こす。

【００２２】例えば、いくつかの事情の下では、１つの
サイトで存在しているファイルの以前のバージョンは、
タイムスタンプが旧式のバージョンをより最近のもので
あるかのように不正に見せかけさせるので、他のサイト
で存在している正しいバージョンの上書きされるかこと
がある。

【００２３】これは、例えば、１つのコンピュータが夏
時間時刻の間調整を行って、他のコンピュータがそのよ
うな調整をまだ行っていなかったときに、起こることが
ある。同様の理由で、タイムスタンプに頼ることは、サ
イト毎の調停時刻を追跡するプロセスの中で同様に問題
を引き起こす可能性がある。

【００２４】この発明は、上述した点に鑑みてなされた
もので、特に、複数のサイトが互いに離隔して配置さ
れ、比較的に遅い長距離通信リンクを介した場合のみし
か互いに通信できない、異なる記憶サイト間に維持され
たファイルを調停して大きなファイルのセットを複写す
ることができる、異なるデータファイルを調停する改良
された方法を提供するものである。

【００２５】

【課題を解決するための手段】この発明により、分散フ
ァイルシステムにおける異なるファイル記憶サイトを調
停する改善された方法が開示される。一組のジャーナル
またはログファイルは、ファイル変更の履歴を異なるサ
イトの各々で追跡するために使用される。ジャーナルフ
ァイルは、対応するサイトの各ファイルと関連させられ
たバージョンエントリーのシーケンスを含む。

【００２６】各バージョンエントリーは、ファイルの対
応するバージョンのコンテンツを高い確率でユニークに
識別するするためにハッシュコードまたはダイジェスト
を含む。調停プロセスの間に、各ジャーナルの中のバー
ジョンエントリーから得られたハッシュコードのシーケ
ンスは、（１）調停の中で含まれたいずれかのファイル
に競合が存在するかどうか、（２）存在しないのなら
ば、ファイルのバージョンは、最新のバージョンであ
る、ということを判定するために相互に比較される。次
に、最新のバージョンは必要に応じて他のサイトにコピ
ーされ、ジャーナルはコピーしているファイルを反映す
るために更新される。

【００２７】ハッシュコードまたはダイジェストは、コ
ードが発生するファイルのコンテンツをユニークに識別
する非常に高い確率で既知のメッセージ・ダイジェスト
・プログラムに従うファイルのコンテンツから計算され
る。ファイルの異なるバージョンが異なるコンテンツを
持つので、それらは同様に異なるコードに結びつく。

【００２８】したがって、ハッシュコードは、開示され
た調停プロセスがタイムスタンプの使用から起こってい
る望まれていない上述したような結果をもたらさないよ
うに、ファイルの異なるバージョンを独立して識別す
る。

【００２９】また、この発明のプロセスにおいて、サイ
トに依存せずに独自の昇順バージョン番号を生成するこ
とは、バージョンベクトルを各々の目的のために保持す
る必要がないので、バージョンベクトルアプローチとも
異なる。

【００３０】また、この発明の改善された方法は、サイ
トの掛かり合いをファイル調停の中で追跡する。各々の
ジャーナルファイルにおける各々のバージョンエントリ
ーは、他のサイトに関連するジャーナルファイルのいず
れがエントリーのコピーを持つかを示すサイトインジケ
ーターフィールドを含む。

【００３１】バージョンエントリーが調停の間に作成さ
れると、サイトインジケータフィールドは、どのサイト
が調停に関連しているかを示す値に設定され、その結
果、バージョンエントリーのコピーを持つ。

【００３２】全てのサイトが、サイトインジケータフィ
ールドによって示されるように、バージョンエントリー
のコピーを持つとき、間違いなく、いかなる以前のバー
ジョンエントリーも削除されるようにすることが安全で
ある。

【００３３】このトラッキングプロセスがバージョンエ
ントリーを使用するので、さらにハッシュコードの独自
性を活用してタイムスタンプの使用と関連した問題を回
避することができる。

【００３４】別の態様において、サイトは、ＴＣＰ／Ｉ
Ｐプロトコルを使用して大量データを伝送するために、
ネットワークリンクによって互いに遠隔的に接続された
クライアントサイト及びサーバサイトを含む。

【００３５】

【発明の実施の形態】図１と図２は、SITE１とSITE２と
してそれぞれ参照された２つの別々のサイトに存在して
いるファイルのリスト出力を示す。これらのファイル
は、ファイル名によってリストされる。SITE１は、３つ
のユーザファイルfile１.xxx、file２.xxx及びfile３.x
xx、２つの追加のファイルfile５.xxxとfile６.xxxを含
んでいるサブディレクトリsub１.dir及びジャーナルフ
ァイルsite１.jnlを含む。「xxx」値は、ユーザデータ
ファイルとしてファイルを識別するファイル形式拡張子
を表す。

【００３６】一般に、SITE２は、SITE１に含まれなかっ
たファイルfile４.xxxを含むという点と、file３.xxxを
持たないという点を除いては、SITE１と同じファイルを
含む。SITE２のジャーナルファイルは、site２.jnlと呼
ばれる。

【００３７】図１及び図２の中で示されるユーザファイ
ル及びディレクトリファイルは、サイトSITE１及びSITE
２が属するコンピュータシステムのユーザによって作
成、リード、変更及び削除される。

【００３８】さらに、一般に、サイトSITE１及びSITE２
のファイル及びディレクトリは、互いにミラーリングさ
れている。例えば、サイトSITE１は、ユーザのワークス
テーションのハードディスク上の領域であってもよく、
サイトSITE２は、ワークステーションのファイルの共有
またはバックアップコピーを保有するのに使用されるフ
ァイルサーバ内の大容量ディスクの領域であってもよ
い。したがって、定期的に、２つのサイトでのユーザフ
ァイルとディレクトリは、両方のサイトがファイル及び
ディレクトリの最新のコピーを持つように、互いに調整
される。

【００３９】図３から図６は、ジャーナルファイルの構
造を示す。図３に示すように、ジャーナルファイルは、
ヘッダ、一つ以上のサイトエントリー及び一つ以上のバ
ージョンエントリーから成る。サイトがサブディレクト
リを持つ場合のように、複数のヘッダがあってもよい
が、サイトエントリーは、最初のヘッダラインの後にの
みある。サイトエントリーは、調停に関連している各サ
イトに存在する。

【００４０】バージョンエントリーは、サイトに存在し
た各ファイルの各バージョンのために、ジャーナルファ
イルに加えられる。バージョンエントリーは、古くなっ
たときに排除されるので、いかなる与えられた時間でも
ジャーナルファイルにおけるバージョンエントリーも各
ファイルに関連のあるバージョンの履歴だけを表す。

【００４１】ヘッダ構造は、図４に示される。履歴がジ
ャーナルファイルに現れるサイトは、<sitename>とラベ
ルされたフィールドで識別される。また、ヘッダは、サ
イトが属するコンピュータシステムのタイプを識別する
ために使用される<systype>とラベルされたフィールド
と、ジャーナルファイルを作成した調停プログラムのバ
ージョンを識別するための<programname>とラベルされ
たフィールドをも含む。

【００４２】図５に示すように、バージョンエントリー
は、いくつかのフィールドを含む。これらは次のように
記述される。

【００４３】

【表１】

【００４４】図６に示すように、サイトエントリーは、
いくつかのフィールドを含む。これらは次のように記述
される。

【００４５】

【表２】

【００４６】上記の説明に基づいて、以下は図１及び図
２に示されたサイトに関する典型的なジャーナルファイ
ルを示す。 SITE１のジャーナル $ <date> <time> SITE２ ？１ $ <date> <time> SITE１ ？２ + f１date f１time file１.xxx dt=aaaaa + f２date f２time file２.xxx dt=bbbbb + f３date f３time file３.xxx dt=ccccc + s１date s１time sub１.dir/ SITE1/sub１.dirのジャーナル ＋f５date f５time file５.xxx dt=eeeee + f６date f６time file６.xxx dt=fffff

【００４７】SITE２のジャーナル $ <date> <time> SITE２？１ $ <date> <time> SITE１？２ + f１time f１time file１.xxx dt=aaaaa + f２date f２time file２.xxx dt=bbbbb + f４date f４time file４.xxx dt=ddddd + s１date s１time sub１.dir/ SITE２/subl.dirのジャーナル ＋f５date f５time file５.xxx dt=eeeee + f６date f６time file６.xxx dt=fffff

【００４８】図７は、調停プロセスを図示する。プロセ
スは、調停に関係する相互に関連付けられた既存のジャ
ーナルファイル１０及びディレクトリ１１を読み込む。
ステップ１２で、各サイトに関連するジャーナルにおけ
るバージョンエントリーは、個々のサイトのファイル及
びディレクトリの最新のバージョンを反映するように更
新される。

【００４９】まず、調停に関係するサイトの実際のコン
テンツが、サイトディレクトリ及びサブディレクトリを
読み込むことによって判断される。新たな「＋」バージ
ョンエントリーが、（１）対応するバージョンエントリ
ーを有さない（従って新たに作成されたと推定される）
か、または（２）ジャーナルファイルのファイルまたは
ディレクトリに関する最後のバージョンエントリーに含
まれる日時とは異なった日時を有する（従って変更され
たと推測される）、ファイル及びディレクトリについて
作成される。「＋」バージョンエントリーが作成される
方法は、図８を参照して以下に詳細に説明する。

【００５０】ファイルが対応するバージョンエントリー
を有し、タイムスタンプが適合すれば、サイトに存在す
るファイルのバージョンはそのファイルに関する最後の
バージョンエントリーと一致する。この場合、新たなバ
ージョンエントリーは作成されない。このようにして、
不必要なダイジェストの再計算が避けられる。ダイジェ
ストの計算はコンピュータ集約的であるため、新たなま
たは変更されたファイルについてのみ新たなダイジェス
トを作成するというこの特徴により、調停プロセスの性
能が高まる。

【００５１】ファイルの最新「バージョン」が実際には
その削除であることがあり得る。ジャーナル全体を通し
てパスが行われ、既存のバージョンエントリーで命名さ
れた何れかのファイルまたはディレクトリがファイルシ
ステムから削除されているかどうかを判断する。かかる
ファイルの何れについても、削除されたファイルまたは
ディレクトリの名前を含む新たな「−」バージョンエン
トリーが作成され、最後に行われたアクションが対応す
るサイトでのファイルの削除であったことを示す。

【００５２】ジャーナルがステップ１２で読み込まれる
と、最新の調整に関係しているサイト及びジャーナルに
記述された他のサイトの両方を含む、既知のサイトの単
一のマスターリストに、これらのジャーナルのサイトエ
ントリーがマージされる。またマスターリストは、新た
なジャーナルで使用されるマスクビットと、各サイトに
関する最後の既知の調整の日時を含む。

【００５３】次に、以下のようにステップ１３において
サイトエントリーが更新される。まず、最新の調停に関
係する各サイトに関するエントリーが、現在時を含むよ
うに更新される。次に、古いサイト（１ヶ月など長期に
亘ってアクセスされていない）が排除される。その結果
得られる最新の調整に関係しないサイトを含むサイトの
リストは、関係するサイトに関する新たなジャーナルの
全てに最終的に含まれることになる。

【００５４】ここで、マスクビットのサイトへの割り当
ては、特定のジャーナル内でのみ意味があることに注意
すべきである。上記のようにジャーナルがマージされる
と、サイトならびにバージョンエントリーの両方におけ
るマスクビットは、バージョンとサイトとの間の関連を
維持するのに適するように再度マッピングされる。

【００５５】図示した実施の形態においては、マスクビ
ットは次のようにサイトに割り当てられる。ジャーナル
に記述された第一のサイトにはマスク値１が与えられ、
第二のサイトにはマスク２が与えられ、第三にはマスク
４が与えられ、第四にはマスク８が与えられ、以下同様
に続く。この割り当ては任意であり、これに代わる実施
の形態において他の方法で行われてもよい。サイトが放
棄された場合には、その対応するマスクビットは他のサ
イトが自由に使用できるようになる。後のサイトはでき
たギャップを自動的に埋めるように上に移動する。

【００５６】調停プロセスは次にステップ１４に進む。
まず、ジャーナルの各ファイル名に関するバージョンエ
ントリーのシーケンスが比較される。この工程は、「マ
キシマム・コモン・サブシーケンス（Maximum common s
ubsequence）」またはＭＣＳアルゴリズムとして知られ
るアルゴリズムを採用している。ＭＣＳアルゴリズム
は、各ファイル名に「共通の」バージョンエントリー、
すなわち調停しているサイトに関する全てのジャーナル
ファイルに含まれるバージョンエントリーのサブシーケ
ンスが存在すれば、かかるサブシーケンスを発見する。
この共通のサブシーケンスは、調停プロセスによる更な
るアクションの基礎を形成する。

【００５７】次のステップは、最後の共通のエントリー
の後に何れかのジャーナルファイルに現れる最後のバー
ジョンエントリーが存在すれば、かかるエントリーを識
別する。何れのジャーナルファイルも最後の共通のバー
ジョンエントリーの後にデータファイルに関するバージ
ョンエントリーを有していない場合には、ファイルの最
新のバージョンは各サイトに既に存在している。この場
合には、そのファイルに関しては更に調整アクションを
取る必要はない。

【００５８】これ以外の場合には、次のステップは競合
があるかどうかをチェックすることである。（１）調整
されるサイトのジャーナルにおけるファイル名について
共通のサブシーケンスが存在しないか、または（２）最
後の共通のバージョンエントリーの後に２つ以上のジャ
ーナルに異なったバージョンエントリーが存在する場合
に、競合が存在する。

【００５９】何れの場合においても、調停プロセスがど
のバージョンが最新であるかをハッシュコードから判断
することは不可能である。この場合に、競合するバージ
ョンの１つを独特で識別的な名前を使って名前を変更
し、競合を抹消する。どのバージョンの名前を変更する
かの選択は任意であり、選択するための１つの単純な方
法は早いタイムスタンプを有するバージョンを選ぶこと
である。この名前変更の後に、競合するバージョンの両
方が必要に応じて他のサイトに写され、ユーザは２つの
ファイルを比較して適切な修復アクションを取るように
通知される。

【００６０】所与のファイル名について競合が発見され
なければ、最後の共通のバージョンエントリーに続くバ
ージョンエントリーを有するサイトに存在するファイル
の最新バージョンは、他のサイトにコピーされる。最新
バージョンは１つのサイトにのみ存在することがしばし
ばある。しかし、コピーが行われる前に複数のサイトに
最新バージョンが存在することがあり得る。

【００６１】このような場合には、そのバージョンはそ
れが存在するサイトの何れかからコピーされて、最新バ
ージョンが存在しないサイトにのみコピーされる。コピ
ーが行われると、ファイルの最新バージョンを受け取る
サイトのジャーナルに新たな「＋」バージョンエントリ
ーが添付される。

【００６２】ファイルが２つの異なったタイプのシステ
ム間で、例えばUNIXシステムからWindowsシステムにコ
ピーされる場合がある。これらのシステムは異なった文
字を使って、テキストファイルにおけるテキストのライ
ンの末端を示す。このような場合には、エンド・オブ・
ライン文字は、コピー先のシステムとの適切な互換性を
確保するように、必要に応じてファイルコピー工程中に
変更される。以下に説明するように、テキストファイル
へのこれらの小さな変更は、独自にファイルを識別する
ハッシュコードの能力に影響せず、従ってハッシュコー
ドを変更せずにコピーできる。

【００６３】ＭＣＳにおける最新のバージョンエントリ
ーの後の最後のバージョンエントリーが、ファイルが削
除されたことを示す「−」バージョンエントリーである
場合には、ファイルがまだ存在するサイトからそのファ
イルが削除され、それに応じて「−」バージョンエント
リーがジャーナルに添付される。

【００６４】ステップ１６では、ジャーナルファイルが
無限に増大するのを防ぐために、ジャーナルは再度検査
されて旧式のバージョンエントリーを排除する。（１）
全てのジャーナルに共通の何れかのバージョンエントリ
ーより先であるか、または（２）例えば１ヶ月などの妥
当な古さよりも古い場合に、バージョンエントリーは旧
式になる。

【００６５】この後者のアクションは、通常はファイル
の最後のエントリーであって、従って、これらのファイ
ルに関する他のバージョンエントリーよりも先ではない
古い削除、すなわち「−」エントリーを扱うために行わ
れる。旧式のバージョンエントリーが排除された後に、
更新されたジャーナルが、それに続く調整に使われる更
新されたジャーナルファイル１８として書き戻される。

【００６６】前記においては、ＭＣＳにおける最後のバ
ージョンエントリーが全てのサイトがファイルの所与の
バージョンを見た最新の時点を表すため、特に重要であ
ることに注意すべきである。更に、ジャーナルにおける
最新のバージョンエントリーもまた、どのバージョンが
現在サイトに保存されているかを表すために、特に重要
である。

【００６７】従って、これらのエントリーの重みを反映
するＭＣＳアルゴリズムのバージョンが使用され、最新
及び現在存在するバージョンとの適合を優先させる。こ
の重み付けは、全てのサイトを最新のものにしようとす
る前述の調停プロセスにとっては意義のあるものであ
る。しかし、バージョンエントリーの他の重み付けも可
能であり、調停プロセスの他の実施の形態においては好
適な場合もある。

【００６８】図５に示した「＋」バージョンエントリー
の作成を図８を参照してここで説明する。バージョンエ
ントリーが作成される時点では、日付、時間、名前及び
種類のフィールドに含められる値は既知であり、従っ
て、これらは個々のフィールドに単に挿入されるだけで
ある。

【００６９】サイトインジケータは、ステップ２０に示
すように作成される。バージョンエントリーが最初に作
成されると、そのマスクは、そのバージョンが作成され
たサイトを除く全てのサイトについて設定され、その１
つのサイト以外の全てのサイトでは知られていないこと
を示す。他のサイトとのこのバージョンの調停が成功す
ると、バージョンの対応するマスクビットをリセットす
ることになり、そのバージョンが追加サイトにおいて知
られていることを示す。

【００７０】マスクは調停毎に保存される。そのマスク
ビットの全てがリセットされると、バージョンは知られ
てあらゆるところに伝えられる。バージョンがあらゆる
ところで知られると、同じファイルに関する全ての以前
のバージョンエントリーは旧式になり、安全なように排
除することができる。

【００７１】ハッシュコードまたはダイジェストはステ
ップ２２で作成される。メッセージダイジェストバージ
ョン５（ＭＤ５）として知られる手順が、ファイルの内
容を入力として使用して実行される。この入力に基づい
て、ＭＤ５は、同じファイルの前後のバージョンを含
む、全てのあり得るファイルの中でファイルを一意に識
別する非常に高い確率を有する、１６バイト（１２８ビ
ット）のダイジェストを計算する。

【００７２】ファイルを一意に識別する能力は、一部に
は、約１０⁴⁰またはほぼ１００万から１００万の累乗
（one million to the one-millionth power）である多
数の可能なコードによるものである。ハッシュコードを
作成する方法は他にもある。許容できる程度に低い率の
適合ミスを生ずるアルゴリズムを使用することが望まし
い。

【００７３】テキストファイルに関しては、エンド・オ
ブ・ライン文字はダイジェストの計算において無視され
る。この特徴により、上記のようにファイルが異なった
種類のシステム間でコピーされる時に、これらの文字を
透過性のあるように変更することが可能になる。この特
徴は最適化であり、ダイジェストの計算にこれらの文字
を含めることは代替的な実施の形態においても役立つで
あろう。

【００７４】例 ここで開示している調停プロセスとその結果を説明する
ために以下に例を示す。例１は通常で競合がない場合で
ある。例２は競合を示す。例３及び例４はサイトエント
リーの作成と旧式のバージョンエントリーの排除を例示
している。図９ないし図１１は、ぞれぞれfile1、file2
及びfile3の以下のシナリオを作り出す変更とコピーの
シーケンスを示す。垂直の矢印は変更を示し、水平の矢
印はコピーを示す。関係のない詳細を省くためにファイ
ルの拡張子は削除し、ファイルの異なったバージョンか
ら計算されるハッシュコードを５ビットの英数字を使っ
て表している。実際には、ハッシュコードは上述のよう
により長いストリングである。

【００７５】例１−競合がない場合 １．既存のジャーナルファイル（ある以前の調停か
ら）： SITE1 SITE2 + file1 jj39z + file1 jj39z + file2 r9t4w + file2 r9t4w + file3 pq9zr + file3 pq9zr

【００７６】２．以前の調停以来のサイト１でのfile2
の変更及びサイト２でのfile3の削除を示す最新のサイ
トディレクトリ： SITE1 SITE2 file1 jj39z file1 jj39z file2 kpn33 file2 r9t4w file3 pq9zr

【００７７】３．サイトの最新のコンテンツを反映した
ジャーナルの最初の更新の結果。サイト１でのfile2及
びサイト２でのfile3に関する新たなバージョンエント
リーが付加されている：

【００７８】４．マージングと競合チェックの結果。フ
ァイルの最新バージョン間の適合は、破線で示されてい
る。file2の新たなバージョン及びfile3の削除は、対応
するバージョンエントリーがこれらのファイルの最新の
共通のエントリーの後に現れているため、削除した。

【００７９】５．file2をコピーし、file3を削除し、そ
れに従ってジャーナルを更新した結果： SITE1 SITE2 + file1 jj39z + file1 jj39z + file2 r9t4w + file2 r9t4w + file2 kpn33 + file2 kpn33 + file3 pq9zr + file3 pq9zr - file3 - file3

【００８０】６．対応する更新されたサイトの内容： SITE1 SITE2 file1 jj39z file1 jj39z file2 kpn33 file2 kpn33

【００８１】７．他のサイトは存在しないものと仮定し
て、ジャーナルから古いバージョンを排除した結果： SITE1 SITE2 + file1 jj39z + file1 jj39z + file2 kpn33 + file2 kpn33 - file3 - file3

【００８２】例２−競合のある調整 上記６及び７のサイトの内容及びジャーナルに続いて、
両サイトのfile1のバージョンが不一致に更新されてい
るものとする。 ８．file1への競合のある更新の後の新たなサイトの内
容： SITE1 SITE2 file1 d9qlj file1 92w3a file2 kpn33 file2 kpn33

【００８３】９．ジャーナルを新たなサイトの内容を反
映するように更新した結果で、マージングと競合検出が
続く： SITE1 SITE2 + file1 jj39z ---- + file1 jj39z + file1 d9qlj + file1 92w3a + file2 kpn33 ---- + file2 kpn33 - file3 ---- - file3両サイトで最後の共通
のバージョンには適合しないバージョンが続くfile1に
関して競合が検出される。

【００８４】１０．競合があるバージョンの１つの名前
を変更した結果としてのサイトの内容： SITE1 SITE2 file1 d9qlj file1#1 92w3a file2 kpn33 file2 kpn33

【００８５】１１．対応する更新されたジャーナル： SITE1 SITE2 + file1 jj39z ---- + file1 jj39z + file1 d9qlj + file1#1 92w3a + file2 kpn33 ---- + file2 kpn33 - file3 ----- - file3 「file1#1」は、調整プログラムによって割り当てられ
た新たな独自のファイル名である。ここで、各サイトに
は新たなファイルがある。

【００８６】１２．新たなバージョンをコピーして両サ
イトを一致させた結果： SITE1 SITE2 file1 d9qlj file1 d9qlj file1#1 92w3a file1#1 92w3a file2 kpn33 file2 kpn33

【００８７】１３．結果として得られるジャーナル： SITE1 SITE2 + file1 jj39z + file1 jj39z + file1 d9qlj + file1 d9qlj + file1#1 92w3a +file1#1 92w3a +file2 kpn33 + file2 kpn33 - file3 - file3

【００８８】１４．他のサイトは存在しないと仮定する
と、旧式のバージョンを排除することができ、その結
果： SITE1 SITE2 + file1 d9qlj + file1 d9qlj + file1#1 92w3a + file1#1 92w3a + file2 kpn33 + file2 kpn33 - file3 - file3

【００８９】例３−サイトエントリーの作成１．サイト
SITE1とSITE2との間の上記の調整を開始点と仮定する
と、各ジャーナルファイルのサイトエントリーは以下の
とおり： site1.jnl: $ date1 time1 SITE1 ?01 $ date1 time1 SITE2 ?02 site2.jnl: $ date1 time1 SITE1 ?01 $ date1 time1 SITE2 ?02

【００９０】２．続いて、SITE1と新たなサイトSITE3と
の間で調整が行われる。新たなサイトエントリーは以下
のとおり： site1.jnl: $ date2 time2 SITE1 ?01 $ date1 time1 SITE2 ?02 $ date2 time2 SITE3 ?04 site2.jnl（変更せず） $ date1 time1 SITE1 ?01 $ date1 time1 SITE2 ?02 site3.jnl: $date2 time2 SITE1 ?01 $ date1 time1 SITE2 ?02 $ date2 time2 SITE3 ?04

【００９１】例４−サイトインジケータを管理して古い
バージョンを排除する１．例１及び例２ではSITE1及びS
ITE2のみが存在すると仮定した。仮に、例えばサイトマ
ーク?4のSITE3などの他のサイトがあるとすれば、古い
ジャーナルエントリーは排除されず、ジャーナルは継続
したであろう： SITE1(?1) SITE2(?2) SITE3(?4) + file1 jj39z + file1 jj39z + file1 jj39z + file1 d9qlj ?4 + file1 d9qlj ?4 + file1#1 92w3a ?4 + file1#1 92w3a ?4 + file2 r9t4w + file2 r9t4w + file2 r9t4w + file2 kpn33 ?4 + file2 kpn33 ?4 + file3 pq9zr + file3 pq9zr + file3 pq9zr - file3 ?4 - file3 ?4 例えばfile1(jj39z)についての旧式のエントリーは、そ
れに続くエントリー(d9qlj)が全てのサイトではまだ知
られていないため、排除することができない。

【００９２】２．ここで、SITE2とSITE3（SITE1ではな
い）との間で調整が行われた場合には、適切なファイル
はSITE3にコピーされて、それらのジャーナルはこれを
反映するように更新されるであろう： SITE1 SITE2 SITE3(?4) + file1 jj39z + file1 jj39z + file1 jj39z + file1 d9qlj ?4 + file1 d9qlj + file1 d9qlj + file1#1 92w3a ?4 + file1#1 92w3a + file1#1 92w3a + file2 r9t4w + file2 r9t4w + file2 r9t4w + file2 kpn33 ?4 + file2 kpn33 + file2 kpn33 + file3 pq9zr + file3 pq9zr + file3 pq9zr - file3 ?4 - file3 - file3

【００９３】３．旧式のエントリーは、新たなエントリ
ーが全てのサイトにあることが知られているため、SITE
2及びSITE3でジャーナルから排除することができる。 SITE1(?1) SITE2(?2) SITE3(?4) + file1 jj39z + file1 d9qlj ?4 + file1 d9qlj + file1 d9qlj + file1#1 92w3a ?4 + file1#1 92w3a + file1#1 92w3a + file2 r9t4w + file2 kpn33 ?4 + file2 kpn33 + file2 kpn33 + file3 pq9zr - file3 ?4 - file3 - file3 SITE1のジャーナルは、それが次回にSITE1またはSITE3
の何れかと調整されるときに排除されるであろう。

【００９４】様々な分散化されたファイルシステムに適
応する改良されたファイル調停プロセスを説明してき
た。開示した調停プロセスは多くの方法で変更が容易で
ある。例えば、バージョンエントリーを更新する場合、
その内容がタイムスタンプによって示されているように
変更されているかどうかに拘わらず、サイトで発見され
る全てのファイル及びディレクトリについて新たなバー
ジョンエントリーを作成することが可能である。この変
更は、コンピュータ集約的であるため、および変更され
ていないファイルについてのダイジェストの不必要な再
計算のために、性能が低下する見返りに幾分か工程を単
純にするであろう。上記のように、特定のダイジェスト
アルゴリズムは、適切な独自のダイジェストを生ずる多
くのアルゴリズムの何れであってもよい。

【００９５】また、ジャーナルファイルにおけるバージ
ョンエントリーは、バージョンエントリーのシーケンス
におけるその位置に関して異なった重み付けを受けるこ
とができる。例えば、ユーザが指定するバージョンエン
トリーには、シーケンスまたはタイムスタンプの何れか
における位置に基づいて完全に無視できるものもある。
かかるアプローチは、例えばサイトがある古い日付まで
あるいはある古い既存のバージョンまでに限って調整さ
れる場合には、役に立つであろう。

【００９６】説明したように、開示した調停プロセス
は、各サイトのファイル及びディレクトリに直接アクセ
スするためにその工程が実行されているプロセッサの能
力に依拠している。他のメカニズムを採用してファイル
操作を実行してもよい。

【００９７】上述したように、調停プロセスは、遠隔的
に動作するように適合することができる。図１２におい
て、分散型ファイルシステム１００は、クライアントサ
イトにあるクライアントシステム１１０と、サーバサイ
トにあるサーバシステム１２０とを含み、これらは互い
に通信リンク１３０によって接続されている。クライア
ント及びサーバは、リンク上のＴＣＰ／ＩＰプロトコル
を使用して、容易に利用可能な通信ネットワーク、例え
ばインターネットを介して互いに通信することが可能で
ある。

【００９８】上述したように、いずれのサイトも、互い
を反映するように意図されたファイル記憶システム１１
１及び１２１を保持している。しかし、特にサイトが互
いに離れており、サイト間に通信リンクがない、例え
ば、クライアントシステム１１０が、旅行中のユーザが
保有しているラップトップコンピュータである場合にユ
ーザがファイルを更新すると、時が経つにつれて、２つ
のサイトにあるファイルは次第に異なってくる。ある時
点で、記憶システム１１１及び１２１を調停する必要が
出てくる。特に、クライアントとサーバが離れたままで
ある間に記憶システムを調停することが望ましい。

【００９９】図１２に示すように、遠隔調停は以下のよ
うに進む。クライアント１１０のユーザは、サーバ１２
０に接続している間にクライアントシステム上の調停プ
ロセスのクライアントコピー１１２を開始する。それと
同時に、クライアントは、リンク１３０上の、ＵＮＩＸ
?rlogin?または?rsh?コマンドなどの呼び出しコマンド
invoke１３１を使用して、サーバ上の調停プロセスのサ
ーバコピー１２２を呼び出す。そうすると、調停プロセ
スの２つのコピーが協働することができる。

【０１００】プロセスの各コピー（１１１、１２１）
は、ローカル記憶システム（１１２、１２２）上のファ
イルの最新コピーを反映するように、ジャーナルのロー
カルコピー（１１４、１２４）を更新する。クライアン
トによって発せられるGETJOURNALコマンド１３２に応答
して、サーバは更新したジャーナル１３３をクライアン
トに送信する。クライアントは上述したように、ジャー
ナルを結合する（ジャーナル結合（１１５））。

【０１０１】クライアントが結合されたジャーナルを生
成した後、クライアントはGET FILEまたはPUT FILEコマ
ンド１３４を発して、クライアントとサーバの間で異な
るファイルをコピーする。これは、クライアントにおい
てファイル１１６を直接更新するとともに、サーバにお
いて遠隔ファイル操作１２６を使用して反映されたコピ
ーを更新する。更新する毎に、ＡＣＫ応答１３５による
承認が行われ、ステップが首尾よく完了したことを示
す。

【０１０２】記憶システムがファイルレベルで調停され
た後に、クライアントは、承認されうるPUTJOURNALコマ
ンド１３６を使用して、更新されて結合されたジャーナ
ルをサーバに返送する。更新かつ結合されたジャーナル
はここで、それぞれのローカル記憶システム（１１８、
１２８）に書き込まれ（新ジャーナル書き込み）、先行
のコピーを置き換えることが可能である。調停の結果は
ステップ１１９において報告することができる。

【０１０３】利点として、この遠隔調停は、ネットワー
クファイルシステムに依拠しない。その結果、調停は、
タイムスタンプ、アクセス制御、及びシンボリックリン
クなどのファイルシステムの詳細に対してより直接的な
制御を得ることができる。しかし、主な利得は、２つの
要因から導き出される性能向上である。

【０１０４】第１に、調停プロセスの最も時間のかかる
部分は、変更されたファイルについてローカルサイトを
走査するジャーナル更新プロセスである。遠隔調停にお
いて、クライアント及びサーバはこれを並列して行うこ
とができるため、結合タスクが高速化される。第２に、
より重要なこととして、サーバによる全体の更新がネッ
トワーク接続を介して通信されるコマンドではなく、ロ
ーカルファイルシステムＩ／Ｏコマンドのみを使用して
行われることがある。

【０１０５】多数の小さなメッセージではなく、変更さ
れたファイル及び更新されたジャーナルなどの比較的少
数の大きなメッセージのみがリンク１３０を介して交換
される。低レベルのプロトコル実行に関係なく、遠隔調
停プロセスではジャーナルを取り出すために１つの交
換、ジャーナルを配置するために１つの交換、及び交換
された各ファイルについて１つの交換が必要である。さ
らに、リンクは、例えば拡張可逆データ圧縮を使用して
効率的な大量転送について最適化された転送プロトコル
を使用する。

【０１０６】調停プロセスの上記説明は、個別ステップ
のシーケンス、すなわち、ジャーナルを読み出して更新
し、次にそれを結合し、次にファイルを更新し、最後に
新たなジャーナルを書き込む、として実施される。ま
た、これらのステップを、階層ファイルディレクトリの
各サブディレクトリに順次適用するか、またはファイル
ベースで適用することも可能である。利点として、調停
プロセスが中断する前に行われていた作業を後の使用の
ために保持することができる。

【０１０７】当業者には、本明細書に開示された発明の
概念から逸脱することなく、上記の方法及び装置に対す
る他の変更やそれらの変形が可能であることが明らかで
あろう。従って、この発明は、特許請求の範囲及び精神
によってのみ限定されるものと理解すべきである。

【０１０８】

【発明の効果】以上のように、この発明によれば、複数
のサイトが互いに離隔して配置され、比較的に遅い長距
離通信リンクを介した場合のみしか互いに通信できな
い、異なる記憶サイト間に維持されたファイルを調停し
て大きなファイルのセットを複写することができる、異
なるデータファイルを調停する改良された方法を提供す
ることができる。

【図面の簡単な説明】

【図１】 コンピュータシステムにおけるデータファイ
ル保存サイトのディレクトリリストである。

【図２】 コンピュータシステムにおけるデータファイ
ル保存サイトのディレクトリリストである。

【図３】 本明細書中で開示した調停プロセスにおいて
使用されるジャーナルファイルの構造図である。

【図４】 図３に示したジャーナルファイルのコンポー
ネントの構造図である。

【図５】 図３に示したジャーナルファイルのコンポー
ネントの構造図である。

【図６】 図３に示したジャーナルファイルのコンポー
ネントの構造図である。

【図７】 本明細書中で開示した調停プロセスのフロー
チャートである。

【図８】 図３のジャーナルファイルにおけるバージョ
ンエントリーが図７の調停プロセス中で作成される工程
の一部のフローチャートである。

【図９】 調停に関係するファイルに影響するアクティ
ビティを例示したタイムライン図である。

【図１０】 調停に関係するファイルに影響するアクテ
ィビティを例示したタイムライン図である。

【図１１】 調停に関係するファイルに影響するアクテ
ィビティを例示したタイムライン図である。

【図１２】 本発明による遠隔調停を使用したクライア
ントサーバシステムのブロック図である。

【符号の説明】

１００ 分散型ファイルシステム、１１０ クライアン
トシステム、１１１ファイル記憶システム、１１２ ク
ライアントコピー、１２０ サーバシステム、１２１
ファイル記憶システム、１２２ サーバコピー。

フロントページの続き (56)参考文献 特開 平11−306058（ＪＰ，Ａ) 特開2000−57032（ＪＰ，Ａ) 亀嶋他，世界規模分散ファイルシステ ムＳｋｉｎｎｙ，情報処理学会研究報 告，日本，社団法人情報処理学会，1995 年 ８月，Ｖｏｌ．95，Ｎｏ．79（95− ０Ｓ−70），ｐ．１−８ Ｄ．Ｒａｔｎｅｒ，Ｐ．Ｒｅｉｈｅ ｒ，ａｎｄ Ｇ．Ｊ．Ｐｏｐｅｋ，Ｄｙ ｎａｍｉｃ ｖｅｒｓｉｏｎ ｖｅｃｔ ｏｒ ｍａｉｎｔｅｎａｎｃｅ，Ｔｅｃ ｈｎｉｃａｌ Ｒｅｐｏｒｔ ＣＳＤ− 970022，米国，Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃａｌｉｆｏｒｎｉａ，1997年, ｐ．１−７，ＵＲＬ，ｈｔｔｐ：／／ｆ ｉｃｕｓ−ｗｗｗ．ｃｓ．ｕｃｌａ．ｅ ｄｕ／ｆｍｇ／ｓｕｍｍａｒｙ．ｈｔｍ ｌ (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 G06F 15/16 - 15/177

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 遠隔ネットワークリンクで互いに接続さ
   れたクライアントサイト及びサーバサイトに記憶される
   異なるデータファイルを調停する方法であって、 それぞれのコンテンツによりデータファイルの対応する
   バージョンを一意に識別するハッシュコードを生成する
   ステップと、 該生成されたハッシュコードをクライアントジャーナル
   ファイル及びサーバジャーナルファイルに記憶し、各ジ
   ャーナルファイルのハッシュコードは、データファイル
   の異なるバージョンが対応するサイトに記憶された順序
   を示すシーケンスで記憶される、ステップと、 クライアントサイトにより、サーバジャーナルファイル
   の複写を要求するステップと、 サーバジャーナルファイルをクライアントジャーナルフ
   ァイルと結合して、結合されたジャーナルファイルをク
   ライアントサイトに生成するステップと、 該結合されたジャーナルファイルからのハッシュコード
   のシーケンスを分析して、（１）データファイルのどの
   バージョンが現在のバージョンか、（２）現在のバージ
   ョンが記憶されているサイト、（３）現在のバージョン
   が記憶されていないサイト、を判定するステップと、 データファイルの現在のバージョンを、それが記憶され
   ているサイトからそれが記憶されていないサイトに、ネ
   ットワークリンクを介して置き換えるステップとを含む
   異なるデータファイルを調停する方法。
2. 【請求項２】 結合されたジャーナルファイルは、複写
   を反映するように更新される、請求項１記載の異なるデ
   ータファイルを調停する方法。
3. 【請求項３】 更新されたジャーナルファイルは、複写
   後に、ネットワークリンクを介してサーバサイトに送信
   される、請求項２記載の異なるデータファイルを調停す
   る方法。
4. 【請求項４】 ファイルは、ＴＣＰ／ＩＰプロトコルを
   使用してネットワークリンクを介して伝送される、請求
   項１記載の異なるデータファイルを調停する方法。
5. 【請求項５】 上記分析ステップ及び置換ステップは、
   各サイトで同時に行われる、請求項１記載の異なるデー
   タファイルを調停する方法。