(57)【要約】本発明は、ファイル変更通知のためのコンピュータープログラム製品を含む、方法及びシステムを提供する。
2005515556.tif 000002
【特許請求の範囲】
【請求項１】
変更通知を一又はそれ以上の外部アプリケーションに配信する要求を受け取るステップと、
ファイルシステム内の一又はそれ以上のファイルの検知された変更を含む記録を、変更ログから検索することと、
前記記録を前記一又はそれ以上の外部アプリケーションに配信することと、
により、前記要求に応答するステップと、
からなり、前記記録を配信することは、前記要求が受け取られるより前に検知された変更を含む記録を配信することを含む、
ことを特徴とする方法。
【請求項２】
配信不可能な記録を、前記記録が配信できるようになるまでバッファに入れるステップ、
をさらに含む請求項1記載の方法。
【請求項３】
前記外部アプリケーションに配信する前に、一又はそれ以上の前記記録を、汎用フォーマットからアプリケーション固有のフォーマットに変換するステップ、
をさらに含む請求項1記載の方法。
【請求項４】
ファイルが変更通知の対象であるか否かを判断するステップと、
変更通知の対象であるファイルに対応する前記記録のみを配信するステップと、
をさらに含む請求項1記載の方法。
【請求項５】
冗長、又は間もなく廃れるような記録を選別して除去するステップ、
をさらに含む請求項1記載の方法。
【請求項６】
前記一又はそれ以上の外部アプリケーションは、バックアップアプリケーションを含む、
請求項1記載の方法。
【請求項７】
前記ファイルシステム内の前記一又はそれ以上のファイルの変更を検知し、かつ前記変更を前記変更ログに記録するレコーダーから、前記要求を受け取るステップと、
前記要求が、前記レコーダーと独立して動作するブローカーにより受け取られ、かつ応答されるステップと、
を含む請求項1記載の方法。
【請求項８】
情報搬送体で具現化され、データ処理装置に請求項1の前記ステップを実行させることのできる命令を備えるコンピュータープログラム製品。
【請求項９】
前記命令が、請求項2から請求項7までのいずれかの前記ステップを実行する命令をさらに含む、
請求項8記載の製品。
【請求項１０】
請求項1の前記ステップを実行することのできる装置、
を備えることを特徴とするシステム。
【請求項１１】
請求項2から請求項7までのいずれかの前記ステップを実行することのできる装置、
をさらに備える請求項10記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステム及びファイル変更通知に関するものである。
【０００２】
本出願は、2002年1月15日に出願された米国特許仮出願60/349,765号に基づく優先権を主張するものであり、この出願全体が引用により本出願に組み入れられる。
【背景技術】
【０００３】
コンピューターシステム環境におけるファイルシステムのファイルは、しばしば変更されやすい。このような変更は、ファイル変更と呼ばれ、新しいファイルの作成、既存のファイルの削除、及び既存のファイルの変更を含む。しばしば、ファイルシステムの外部のアプリケーションに、ファイルシステム内のファイル変更を通知する必要がある。
【０００４】
情報技術(「IT」)のアプリケーションは、典型的には、変更されたファイルを発見するために、いわゆる「スパイダリング機構」を使用する。残念ながら、スパイダリング機構は緩慢であり、従って、ファイルが変更されたことをアプリケーションが発見するまでに数時間となり得る遅れが存在する。変更ファイルの発見の遅れは、潜伏期と呼ばれる。
【０００５】
(要約)
本発明は、ファイル変更通知のためのコンピュータープログラム製品を含む、方法及びシステムを提供する。
【０００６】
一般的には、１つの側面として、本発明によるシステムは、ファイルシステム内の一又はそれ以上のファイルの変更を検知し、その変更を変更ログに記録することができるレコーダー、及び、変更通知を一又はそれ以上の外部アプリケーションに配信する要求を受け取り、変更ログから記録を検索し、一又はそれ以上の外部アプリケーションにその記録を配信することにより、その要求に応答することのできるブローカー、を特徴とする。このレコーダーは、ブローカーが変更通知要求を受け取ったか否かに関係なく、変更を検知及び記録することができる。
【０００７】
一又はそれ以上の次の有利な特徴を含むように、本発明を実装することができる。レコーダーは、ブローカーと非同期で動作する。ブローカーは、通知要求が作成される前に検知された変更を含めて、変更を外部アプリケーションに配信する。ブローカーは、配信不可能な記録を、配信できるようになるまでバッファに入れる。レコーダーは、変更をアプリケーション非固有のフォーマットで記録し、ブローカーが、その記録を外部アプリケーションに配信する前に、一又はそれ以上の記録をアプリケーション固有のフォーマットに変換する。ブローカーは、ファイルが変更通知の対象であるか判断し、かつ変更通知の対象であるファイルに対応する記録のみを配信する。ブローカーは、冗長な記録、又は間もなく廃れてしまう記録を、選別して除去する。
【０００８】
一般的には、もう１つの側面として、方法は、一又はそれ以上の外部アプリケーションに変更通知を配信する要求を受け取るステップを含む。この方法は、変更ログから記録を検索し、その記録を一又はそれ以上の外部アプリケーションに配信することにより、要求に応答するステップを含む。記録は、ファイルシステム内の一又はそれ以上のファイルの検知された変更を含む。記録の配信には、要求が受け取られるより前に検知された変更を含む記録を配信することも含まれる。
【０００９】
一般的には、もう１つの側面として、コンピュータープログラム製品は、データ処理装置に、一又はそれ以上の外部アプリケーションに変更通知を配信する要求を受け取らせることができる。この製品は、データ処理装置に、変更ログから記録を検索し、一又はそれ以上の外部アプリケーションにその記録を配信することにより、その要求に応答させることができる。この記録は、ファイルシステム内の一又はそれ以上のファイルの検知された変更を含む。記録の配信には、要求が受け取られる前に検知された変更を含む記録の配信も含まれる。この製品は、情報搬送体で具現化される。
【００１０】
一又はそれ以上の次の利点を実現するように、本発明を実装することができる。本発明によるシステムは、ファイル変更の能動的な通知を提供する。すなわち、このシステムは促す動作を必要としない。このシステムは、例えばバックアップ及びサーチエンジン索引のような、クーロンジョブ又はバッチ動作と時々呼ばれる、定期的にスケジュールされたメンテナンス動作に置き換わるものである。このシステムは、リソースを均衡化させ、かつシステムの個人的な保守の必要性を減らす。このシステムは、段階的なバックアップ及びサーチエンジンの更新といったような動作について、短い潜伏期を提供する。変更されたファイルを探すのにすべてのファイルをスキャンする必要が全くないので、システムリソースの負荷を軽減することができる。このシステムは、プラットフォーム及びアプリケーションに対して独立であり、ファイルを保存し、又はファイル又はディレクトリをスキャンする全てのファイル形式及び全てのアプリケーションに対して、変更を行うように働く。システムは、適応性のあるように負荷を管理し、かつ負荷管理のための変更可能なポリシーを含む。システムは帯域外で動作し、このシステムによって監視されるファイルシステムのコンピューティングリソースを消費しない。帯域外とは、ファイルの読み取り又は書き込み動作と共に連続的に起こるものではない処理を指す。このシステムは、拡張可能である。このシステムは、監視されているファイルシステムのログファイルを利用することができる。従って、データのログを取るための新たなプロトコルを作成する必要は全くない。
【００１１】
本発明の一又はそれ以上の実施の詳細を、添付の図面、及び下の詳細な説明で示す。本発明の他の機能、側面、及び利点は、詳細な説明、図面、及び特許請求の範囲から明らかであろう。
【００１２】
(詳細な説明)
変更のためにファイル及びディレクトリをスキャンするどのアプリケーションも、本発明によるファイル変更通知システムの恩恵を受けることができる。このようなアプリケーションの2つの例は、サーチエンジンアプリケーション、及びテープバックアップアプリケーションであり、これらを以下に説明する。
【００１３】
サーチエンジンアプリケーションの例
VerityK2エンタープライズ製品のようなサーチエンジンは、ユーザーが、任意の所定のシステムに格納されているドキュメントのフル機能のキーワード検索を実行することを可能にする。ドキュメントは、任意の一般的なドキュメントフォーマット(例えば、テキスト、マイクロソフトワード又はエクセル、及びアドビPDF)とすることができる。検索を容易にするために、ドキュメントの索引を作成することができる。ドキュメントが何の言葉を含んでいるか、及びそれらの言葉が何のファイルから生じたか、についてのデータを含むファイルで満たされたディレクトリツリーとして、索引を実施することができる。どのドキュメントも、ドキュメントが変更されるたびに索引付けされなければならない。
【００１４】
従来のシステムでは、サーチエンジンは、ファイルがいつ索引付けされる必要があるかわからない。ある外部プロセスが、サーチエンジンが処理するためのファイルのリストを生成しなければならない。多くのファイルを含む大きなディレクトリツリーでは、ファイル/ディレクトリスパイダー(又は「クローラー」)、又はただ単に「スパイダー」と呼ばれるプログラムを、ファイルの索引データが最新であるか確認するために、各ファイルを索引と照合及び比較するのに使用しなければならない。ファイルの索引データが古い場合には、そのファイルは索引付けを予定される。スパイダープログラムは、変更されたファイルを索引と同期させるため夜間ベースで通常実行される、緩慢でコストのかかるプロセスである。結果として、ファイル変更は、24時間以内の使用(検索のような)では確認されない。この潜伏期が、検索技術の一般的に容認されている限界である。
【００１５】
本発明によるシステムは、上述の潜伏期問題を解決する。ファイルがディスクにセーブされるとき、システムは、索引作成器に変更通知メッセージを送る。この行為の結果として、ファイルが1分未満の時間でのサーチエンジンにより利用可能になる。この索引はまた自己管理型であり、もはや終夜のスパイダープロセスを必要としない。
【００１６】
夜間のテープバックアップアプリケーションの例
夜間の段階的なバックアップは、IT設備全体にわたって行われる。通常の段階的なバックアップ動作においては、所定のファイルシステム内の現在のファイルのプロパティが調べられ、既存のファイルのバックアップバージョンのプロパティと比較される。現在のファイルのプロパティが、現在のファイルがそのファイルのバックアップされたバージョンよりも新しいことを示す場合には、現在のファイルがバックアップされる。夜間のバックアップが実行されるとき、ファイルが変更される時とファイルがバックアップされる時との間に潜伏期が存在する。この潜伏期は、24時間という長さになることがある。さらに、全てのファイルが同じ連続動作の中で調べられ、かつバックアップされるので、バックアップ時間の間のネットワーク及びシステムの性能は、大幅に下がることになる。
【００１７】
本発明によるシステムでは、ユーザーによって変更されるファイルを、ファイルがセーブされた瞬間から数秒以内に、バックアップすることができる。通知を受けて、バックアッププログラムは、ファイルをバックアップする。結果として、短いバックアップの潜伏期が実現され、これは、作業のロスを引き起こす何らかのシステム障害の可能性を減らす。さらに、システムリソースの作業負荷が1日を通して均一に均衡化され、これは、バックアップ動作のシステム性能への影響を減らし、かつ変更されていないファイルのクローリングの作業を取り除く。
【００１８】
図1は、ファイルシステム内のファイルのファイル変更の通知を、外部アプリケーション106a及び106bに提供する通知システム100を示している。サーチエンジンの索引作成器は、外部アプリケーションの例である。外部アプリケーション106a及び106bは、システム100により提供される通知を消費する。
【００１９】
通知システム100は、ファイルシステム内部で生じるファイル変更の通知を記録するレコーダーモジュール102、及びファイル変更通知を要求した一又はそれ以上の外部アプリケーションにその通知を配信するブローカーモジュール104、を含む。
【００２０】
変更通知を生成しなければならないファイルシステムイベントを検知する際のファイルシステムのコンポーネントとして作動するように、レコーダー102を実装することができる。これは、ファイルシステムの設計、及びファイルシステムと他のシステムコンポーネントとの間に存在するインターフェースに応じて、様々な方法で行うことができる。例えば、ファイルシステムコードを変更することにより、又はレコーダー機能を、レイヤーとしてオペレーティングシステムとファイルシステムとの間に挿入することによりレコーダーを実装することができる。
【００２１】
ファイル変更通知の記録は、システム起動とすることができる。言い換えると、外部アプリケーションからファイル変更通知の要求を受け取るより前でさえ、レコーダー102は、ファイル変更通知を記録し始めることができる。
【００２２】
通知は、ファイルシステムのある特定のディレクトリ内だけでなく、ファイルシステム内のどんな場所に生じたファイル変更にも関係させることができる。しかしながら、システムはまた、いくらかのファイルに対応する通知のみというような、ある一定の通知のみを外部アプリケーションに配信するように構成することもできる。一つの実施形態では、ファイルに関連するパラメータが、そのファイルが変更通知の対象であるか否かを示す。代わりに、システムは、あらかじめ定められたポリシー(例えば、ディスクのある特定のパーティションに置かれたファイルのみが変更通知の対象である、と指定するポリシー)に基づいて、適格性を判断するように構成することができる。
【００２３】
ファイルシステムの性能への影響を減らすため、記録される情報は最小限にすることができる。例えば、変更の原因又は理由を記録する必要はない。また、各変更ファイルごとに連続したファイル名又はファイルIDを記録する必要もない。この変更通知は、アプリケーション固有でないシンプルかつ汎用的なフォーマットで記録することができる。
【００２４】
ブローカー104は、記録された変更通知を検索し、その通知を外部アプリケーションに配信するように構成することができる。ブローカーが汎用的な通知を検索するとき、ブローカーは、アプリケーション固有の情報を付加するか、さもなければその通知を索引作成器アプリケーションのためのキーのようなアプリケーション固有のフォーマットに変換することができる。
【００２５】
通知の配信は、冗長な、間もなく廃れるであろう、又は処理するのにコストのかかりすぎるファイル変更を選別して除去することを含むことができる。この機能は、さらに、以下の適応性のある負荷管理の説明で説明する。
【００２６】
一又はそれ以上の外部アプリケーション106がもはや作動しなくなった時でさえ、ブローカー104は動作し続けることができる。例えば、外部アプリケーションが終了してしまったため、ある特定の外部アプリケーション106への配信が失敗した場合、ブローカー104は、その外部アプリケーションが再び起動するまで、配信不可能な通知を格納することができる。
【００２７】
通知の記録及び配信は、ファイルサーバーの性能に殆ど又は全く影響を与えないようにするため、他のファイルサーバー動作の帯域外で生じるようにすることができる。例えば、ファイル変更は、即座にディスクに書き込むことができ、ファイル変更の通知が実行されている間でも、遅らせる必要はない。記録及び配信はまた、互いの帯域外で生じることができる。レコーダーモジュール102は、ブローカーモジュール104が実行中であるか否かに関係なく、通知のログを取り続けることができる。
【００２８】
増大する要求に応じて、通知システム100は、望まれる潜伏期及び性能を与えるために、リソース(ハードウェア及び/又はソフトウェア)を拡張することができる。例えば、複数のブローカーモジュール104は、複数の外部アプリケーションをサポートするため、並列に動作することができる。通知は、すべてのファイル形式(例えば、テキストファイル、マイクロソフトオフィスファイル、アドビPDFファイル、及びHTTP/HTMLファイル)に適用することができ、これにはカスタマイズされたファイル形式(例えば、ニュースフィード、及び財務データストリーム)も含まれる。
【００２９】
このファイルシステムは、任意の従来のファイルシステムとすることができ、これには例えば、ウィンドウズ及びUNIXオペレーティングシステムで一般に使用されるファイルシステムも含まれる。一般的に、通知システムは、例えばNFS(ネットワークファイルシステム)又はCIFS(汎用インターネットファイルシステム)プロトコルをサポートするものを含む、リモートファイルシステムのアクセスを提供する任意のコンピューティングシステム上で動作することができる。通知システム100は、任意の上述のファイルシステム又はオペレーティングシステムに移植することのできる非独自のシステムである。
【００３０】
このファイルシステムは、どのような形ででも実施することができる。例えば、それは1つのコンピューター上に常駐され、そのコンピューターのオペレーティングシステムと一体化して実施することができる。それは、専用のハードウェア上で実施することもできる。それは、複数のコンピューター全体にわたって分散されることもできる。或いは、並列I/Oネットワークファイルサーバーアーキテクチャについての米国特許5,163,131号で説明するように、特殊目的のハードウェア上で実施することもできる。
【００３１】
通知システム100内のデータの流れの一例をここで説明する。レコーダー102は、ファイルシステム内のファイルに影響を及ぼす行為に従って、変更通知(「CNs」)を生成する。これらは、キュー、この例ではブローカー104が読み取る変更通知ログ(「CN Log」)204にジャーナルされる。CNは、ブローカーがそれらを確認するまで、キュー内に保持される。本明細書の他のところで説明するように、ブローカーは、ファイルシステムについての様々な情報を維持し、かつ、この情報及び入ってくるCNを使用して、ファイルシステムの変更を通知される外部アプリケーションに特有のキーを生成する。キーは、それらが仕向けられる特定のアプリケーションためにフォーマットされた変更通知である。システムからの変更情報の遺失、又は通信障害を避けるため、ブローカーは、対応するキーが全ての受け取りのアプリケーションによって確認されるまで、そのCNを保持する。
【００３２】
レコーダー102は、ファイルシステム内の如何なるところで生じるファイル変更も検知することができる。ファイルシステム内で生じるどのファイル変更についても、レコーダー102は、CNログ204にファイル変更通知を記録する。CNログ204はキューイングバッファとして実装することができ、これは一つの実施形態では、ファイルシステムの所定のパーティションのルートに置かれた一又はそれ以上のログファイルの形をとる。どの変更通知も構造化されたデータとすることができ、これには、ファイル識別子(「FileID」)、及びイベント(作成、変更、及び削除のような)が含まれる。CNログ204の全てのログファイルは、ログをとられているファイルシステムのルートの下、例えばROOT/axcnlog.dというディレクトリ、に置くことができる。axcnlog.dディレクトリ及びその中の全てのログファイルは、ルートにより所有されることができる。ログファイルは、リトルエンディアン及び4バイトオフセットのデータで書き込まれることができる。ログのために一連の通常ファイルを使用するとき、クライアントは、NFS(ネットワークファイルシステム)及びCIFS(汎用インターネットファイル)のような既存のファイルアクセスプロトコルを使って、ログにアクセスすることができる。ブローカー104は、その通知ファイルを削除することができる、又は処理においてうまく受け取られたことを示す通知と同様なファイル動作を実行することができる。
【００３３】
下の表1は、CNログ204の構造の例を示している。CNログ204のログファイルは、例えばログファイル自身のパーティション内、又は一定長のファイルのプールとして、あらかじめ割り当てられた空き領域を占めることができる。一つの実施形態では、ログファイルは、プールから決して削除されることはなく、ただ単に、必要なときに新しいデータをそれらの中に書き込むだけである。
【００３４】
typedef enum{
CNLOG_EOF=0,  /*cnログファイルの終端のマーク*/
CNLOG_ROOT=1,  /*ルート情報、ファイルシステムを実施した時の第一のエントリ*/
CNLOG_SETATTR=2,
CNLOG_WRITE=3,
CNLOG_CREATE=4,
CNLOG_MKDIR=5,
CNLOG_SYMLINK=6,
CNLOG_MKNOD=7,
CNLOG_REMOVE=8,
CNLOG_RMDIR=9,
CNLOG_RENAME=10,
CNLOG_LINK=11,
CNLOG_COMMIT=12,
CNLOG_SETSD=13,  /*ACL変更*/
CNLOG_MAXOP=14,  /*最も高いopコード+1を示す標識*/
}cnlog_opcode_t;
typedef struct{
unit32_t  uid;  /*実効ユーザーid*/
unit32_t  gid;  /*実効グループid*/
unit32_t  ruid;  /*真のユーザーid*/
unit32_t  rgid;  /*真のグループid*/
}cnlog_cred_t;
typedef struct{
unit32_t  magic;
cnlog_opcode_t  opcode;
unit32_t  fsid[2];
cnlog_cred_t  cred;
time_t  logtime;
}cnlog_cmnhdr_t;
typedef struct{
cnlog_int64_t  inode;
cnlog_int64_t  gen_no;
}cnlog_fid_t;
typrdef struct{
unit32_t  type;
unit32_t  mode;
unit32_t  nlink;
unit32  uid;
unit32_t  gid;
cnlog_int64_t  size;
cnlog_int64_t  nblocks;
time_t  atime;
time_t  mtime;
time_t  ctime;
time_t  crtime;  /*生成時間*/
unit32_t  smbattr;  /*smb拡張ファイルの属性*/
}cnlog_vattr_t;
/*以下の構造体は、FSでcnログファイルに書き込まれるであろう*/
typedef struct{
cnlog_cmnhdr_t  hdr;
cnlog_fid_t  fileid;
cnlog_int64_t  offset;
unit32_t  len;
unit32_t  ioflag;
cnlog_vattr_t  attrs;
}cnlog_write_t;
typedef struct{
cnlog_cmnhdr_t  hdr;
cnlog_fid_t  parent_dir_id;
cnlog_vattr_t  parent_dir_attrs;
cnlog_fid_t  fileid;
cnlog_vattr_t  vattr;
cnlog_string_t  name;
}cnlog_create_t;
typedef struct{
cnlog_cmnhdr_t  hdr;
cnlog_fid_t  parent_dir_id;
cnlog_vattr_t  parent_dir_attrs;
cnlog_string_t  name;
}cnlog_remove_t;
表1
【００３５】
一つの実施形態では、レコーダー102は、CNをディスクに書き込む前に、4kのバッファ内にCNを格納する。そのかわりに、ファイルシステムの性能への影響を減らすために、複数の4kのバッファを使用することができる。1/4秒ごとにバッファ内にCNが存在する場合、又は1/4秒より前にバッファが一杯になる場合には、バッファ内のCNはファイルに書き込まれ、バッファはクリアされる。バッファが全くCNを含まないとき、レコーダー102は、CNログ204に書き込まない。システム100は、キューに入れられた待ち状態の通知のある最小数を補償するのに充分に確保されたディスク領域を使用するように、又はキューに入れられた待ち状態の通知をファイルシステム自身で格納するように、構成することができる。キューに入れられた待ち状態の通知を格納するための領域を使い果たしてしまうことに対する挙動は、以下に説明するように構成することができる。
【００３６】
待ち状態の通知が全く存在しないとき、全てのトランザクションを新しいログファイルに即座に書き込むことにより、潜伏期を減らすことができる。待ち状態の通知が存在するとき、通知をバッファに入れ、通知のバッチを含むログファイルを書くことにより、スループットを増大することができる。
【００３７】
一つの実施形態では、書き込まれる第一のログファイルはcnlog.0である。それに続く書き込みの度に、接尾の数が増える(例えば、cnlog.1、cnlog.2、等々)。例えば65535のような、ログファイルのあらかじめ定められた最大数を書き込んだ後は、システム100は、ファイルログの番号付けをリセットし、cnlog.0に戻す。レコーダー102は、待ち状態のcnlog.*のラッピング及びオーバーランに対する異なる挙動のために構成することができる。このような挙動の一例は、万一オーバーフローの場合には最も古い配信されていない通知が失われるように、待ち状態の通知を上書きする。このような挙動のもう1つの例は、ファイルシステムのディスクスペースを使い果たすまで、サブファイル構造の中に流出する。第三の可能性は、ブローカー104がさらに待ち状態の通知を受け取るまで、ファイルシステムの変更を抑える、又は阻止することである。
【００３８】
図2に示すように、ブローカー104は、名称検索エンジン302、データベースアプリケーションプログラミングインターフェース(「DB API」)304、パス名データベース(「DB」)306、キュー308、及び一又はそれ以上のアプリケーションバッファ310a及び310bを含むことができ、これらは全て同じプロセス領域内にある。
【００３９】
名称検索エンジン302は、状態を格納し、かつ変更されたファイルの身元を解明するためにこの状態を使用するための機構である。この機構は、レコーダー102がログエントリに格納する必要のある情報量を減らすことができ、さらに、万一ログエントリが不十分な情報を含む場合には、ファイルの身元を定めることができる。
【００４０】
パス名DB306は、ファイルシステムについての構造化情報を格納する。パス名DB306は、ファイルID(例えば、NFSファイルハンドル)をファイルのフルパス名に変換するのに使用することができる。システム100により監視されるどのファイルも、パス名DB306内に対応するパス名を持ち、パス名DB306内に格納されるパス名は、ファイルシステムのルートに相対したものである。パス名DB306は、任意の従来のDBとすることができ(例えば、カリフォルニア,レッドウッドショアーズのオラクル社、カリフォルニア,ダブリンのサイベース社、又はスウェーデンのMySQL AB、で製造されるもの)、かつ、ブローカー104のローカル又は外部であるとすることができる。下の表2は、パス名DBにアクセスするのに使用されるモジュールの署名の例を示している。
【００４１】
1. void DBinit():
データベースを初期化する。起動時に、ブローカーにより1度呼ばれる。
2. void DBclose():
データベースをクローズする。exit時に、ブローカーから呼ばれる。
3. int DBfetch(cnlog_key_t *key,  cnlog_dbrec_t **data):
提出された「キー」に対応する「データ」をフェッチする。DBfetchAPIコールは、データベースがエントリを見つけることができない場合には、エラー(<0)を返す。成功した場合には、0を返す。
4. int DBstore(cnlog_key_t *key,  cnlog_dbrec_t **data):
提出されたデータを、キーと共にデータベースの中に格納する。失敗の場合にはエラー(<0)、成功の場合には0を返す。
5. int DBdelete(clong_key_t *key):
キー及びそれに関連するデータを、データベースから削除する。失敗の場合にはエラー(<0)、成功の場合には0を返す。
6. cnlog_key_t* DBfirstkey()  &cnlog_key_t* DBnextkey()
順次的な手法でデータベースをスキャンするためのルーチン。
表2
【００４２】
DB API304は、パス名DB306に、定義されたインターフェースを提供するソフトウェアラッパーである。DB API304は、DbPut()コール及びDbGet()コールを含む。DbPut()は、文字列キー、及びレコードとして格納される文字列値の固定サイズの配列を受け入れる。DbGet()は、文字列キーを受け入れ、前にDbPut()で格納されたレコードを表す文字列値の配列を返す。オプションで、DB API304はまた、DbRecordFree()をサポートすることもでき、これは、前にDbGet()で割り当てられた配列ポインターを受け入れ、関連するメモリを開放する。
【００４３】
キュー308は、ブローカーモジュール104内部のバッファである。名称検索エンジン302は、一般的なフォーマット(すなわち、いずれか特定のアプリケーションに固有でない)でCNエントリを格納するキュー308に、処理されたCNエントリを送る。
【００４４】
キュー308内の一又はそれ以上のアプリケーションバッファ310a及び310bは、アプリケーション固有のフォーマット(「キー」)に変換されたCNを格納する。下の表3は、キーの構造体の例を示している。
【００４５】
tpedef struct_CNFSTRANS{
union{
cnlog_create_t  cncreate;  /*ファイル(又はディレクトリ)作成行為を通知する*/
cnlog_remove_t  cnremove;  /*ファイル(又はディレクトリ)消去を通知する*/
cnlog_write_t  cnwrite;  /*ファイル書き込み又は変更行為を通知する*/
}transinfo;
unit16_t  fullnamesize;
}CNFSTRANSREC, *CNFSREANS;
表3
【００４６】
キーは、キーのオフセット及び長さのようなメタデータ情報を含むことができる。オフセット情報は、ファイルのどの部分が変更によって影響を受け得るかを、システム100が判断することを可能にする。通知が格納される時、実際の文字列はこの構造体の最後に付けられるので、フルパス名のバイト数は、fullnamesizeメンバーに格納される。下の表4は、索引付けアプリケーションのために構成されるキーの構造体の例を示している。
【００４７】
typedef struct_IDXKEY{
short  operation;  /*索引作成器の動作(何らかのenum)*/
short  szfullpath;  /*nullを含む索引作成器キーのサイズ*/
int  offsethi;  /*書き込み時にファイルが更新される場合の最大オフセット*/
int  offsetlo;  /*書き込み時にファイルが更新される場合の最小オフセット*/
int  lengthhi;  -書き込み時のファイル内の更新の最大長
int  lengthlo;  -書き込み時のファイル内の更新の最小長
char  fullpathname;
}IDXKEYREC, *IDXKEY;
表4
【００４８】
どのアプリケーションバッファも、CNログファイルと同じ手法で作成される一連のトランザクションファイルとして実装することができる。どのトランザクションファイルの中身も、フルパス名及びアプリケーションが実行する動作を含む。整数は、文字列として表現された数ではなく、スカラーとして書き込むことができる。
【００４９】
動作中に、ブローカー104、具体的には名称検索エンジン302は、NFS又はCIFSのような他のファイルアクセスプロトコルを通して、ファイルシステムにアクセスする。名称検索エンジン302は、継続的に新しいログファイルを調べ、かつファイルcnlog.0の存在を探すことにより起動する。一つの実施形態は、ファイルが見つかるまでファイルの存在を調べるために、Stat関数コールを使用する。Stat()関数コールは、特定のパスで指定されたファイルについての情報を得るC言語の関数コールである。指定されたファイルの読み取り、書き込み、或いは実行のパーミッションは、Stat()関数コールを実行するのに要求されないが、しかしそのファイルに至るパス名に列記される全てのディレクトリが探索可能でなければならない。全くファイルが見つからない場合には、名称検索エンジン302は1/4秒待ち、再び調べる。エンジンがcnlog.Nファイルを見つけた場合には、名称検索エンジンはそのファイルを処理するが、これにはCNエントリーをそのファイルからキュー308に移すことが含まれる。処理した後、ブローカー104はそのファイルを削除し、エンジンが探す次のログファイルの番号を増やし、次のファイルがあるか調べ続ける。
【００５０】
CNエントリーが、外部アプリケーションが変更されたファイルを識別する、又はその中身を判断するのに不十分な情報を含む場合には、名称検索エンジン302は、パス名DB306内のフルパス名を探すためにCN情報を使うことにより、ファイルの身元を解明することができる。何らかの理由で、パス名をパス名DB306から解明することができない場合には、レコーダー102上で動作しているソフトウェアによりパス名が解明され、以下に説明するように、パス名DB306がその結果に更新される。
【００５１】
名称検索エンジン302は、その構成からFSマウントポイントを探し、かつパス名DB306のFSパス名をそのFSマウントポイントの後ろに付けることにより、フルパス名を作成する。
【００５２】
万一パス名DBが破損した、又は通知のために利用できない場合には、名称検索エンジン302は、ファイルシステムから直接必要な情報を得るために代替の検索機構を使用する。代替の検索機構は、次のように実装することができる。ブローカーが、そのパス名DB内にエントリーを持たない記録(書き込み/作成)を得るとき、ブローカーはこの記録を受け取り、それを代替の検索機構に渡す。代替の検索機構は、属性と共に完全なパス情報を得るためにファイルシステムにコンタクトする。代替の検索機構は、パス名DBをその完全なパス情報に更新する。代替の検索機構は、殆どどこでも動作するソフトウェアとして実装することができる。一つの実施形態では、代替の検索機構は、NFS及びCIFSより柔軟な通信を可能にするソケットを用いて、ホストマシン上で動作する。代替の検索機構が、現在のFS内でパス名を解明することができない場合には、通知は異常終了し、このような場合、エラーイベントをログに取ることができ、かつオプションで、一又はそれ以上の外部アプリケーションにそれを報告することができる。
【００５３】
CNエントリーを処理した後、名称検索エンジンは、ブローカーを呼び出し、何の動作が生じたかを識別するフルパス名及びopコードを最小限に含むトランザクション通知の詳細を伝える構造に、それを渡す。名称検索エンジン302が、トランザクションに関連する全てのパス名を検査した後、ブローカー104は、その構築されたポリシーから、どの通知を外部アプリケーションに配信しなければならないかを判断する。
【００５４】
一旦ブローカー104が通知を配信する責任を負ったら、ブローカー104は、CNログでトランザクションはもはや必要でないという信号を送る。一つの実施形態では、この信号送信は、パス名DB306が(NFSを通して)cnlog.*ファイルを削除することにより遂行される。全ての加入アプリケーションへの配信が成功するまで、待ち状態の通知のトランザクションはCNログ内に残り得る、又はブローカー104でローカルにキューに入れられ得る。具体的には、一旦通知がログから受け取られたことをマークされると、ブローカー104は、そのアプリケーションのための待ち状態のトランザクションを識別する各外部アプリケーションに対して、ローカルバッファを保持することができる。プロシージャ−は、成功又は失敗を返す。成功のリターンと同時に、名称検索エンジン302は、完了通知の報告、又はログを取ることができる。失敗と同時に、名称検索エンジン302は、試みられる再配信のため、トランザクションを送信されないままファイルシステム上に残す、又はトランザクションをローカルにキューに入れる、のいずれかにより、その通知を格納する。
【００５５】
ブローカー104は、名称検索エンジン302によって呼ばれると同時に、キュー308からの通知を読み取り、その通知をキーに変換し、個別のアプリケーション106a、106bに対するアプリケーションバッファ310a、310b内にキーを格納する。一つの実施形態では、第一のキーは、ファイル拡張番号0で格納される。それに続く書き込みの度に、ファイルの拡張番号を1ずつ増加する。
【００５６】
別々のスレッドで、ブローカー104は、アプリケーションバッファからキーのトランザクションファイルを読み取り、そのアプリケーションへの二方向ソケット接続でそのキーを送ることができる。ブローカー104は、1/4秒のタイムアウトに基づいて、又はバッファが満たされた場合にはすぐに、バッファをフラッシュすることができる。ファイルが受け取られたことを示すアプリケーションからの返答を受け取ると同時に、ブローカーはそのトランザクションファイルを削除する。
【００５７】
スループットを高めるため、ブローカー104は、終了したと個々にマークする必要なく、通知のブロックを送ることができる。一つの実施形態では、ブローカー104は、もう一つのプロセス(「読み取り器」)が継続的に応答を読み取り、外部アプリケーションによって受け取られたと通知にマークする間、一プロセス(「送信器」)を継続的に通知を送ることに割り当てることができる。読み取り器が、いくらかの通知が再送されることを示す応答を受け取る場合には、読み取り器は、その要求を送信器のワークフローの中に挿入し、かつ送信器は、この特別な要求を送るため、その通常の作業を中断する。読み取り器はまた、最下位の送信されない通知及び最上位の通知の経過を追い、応答が異常状態に達することを許さない。さらなる効率化のため、外部アプリケーションは、read()へのシステムコールの数を減らすために、一度により大きいブロックを要求することができる。その上、外部アプリケーションからの応答は、ただ１つのトランザクションファイルではなく、トランザクションファイルのバッチを参照することができる。このバッチ実施形態では、ブローカーは、全ての通知の並びを追い、かつ順々にその通知を配信することができる。
【００５８】
クライアント外のファイルの安全確保/持続性
アプリケーションが終了してしまった又は応答していない場合には、ブローカー104は、アプリケーションに通知を配信することができない。しかしながら、ブローカー104は、キューイング機構308内に配信不可能な通知を付加することにより、通知を蓄積し続けることができる。一旦、そのアプリケーションが再び動作すると、ブローカー104は、通常のようにキーを配信し続ける前に、それらの通知を配信するであろう。この手法で、アプリケーションがなくても、通知システムは持続する。
【００５９】
負荷管理/配信ポリシー
激しい使用環境では、ブローカー104は、過負荷状態となり得る。ブローカー104は、どの通知を処理すべきか、及びどの通知をただ単に無視又は削除すべきか、を判断するためのポリシーベースの管理レイヤーを含むことができる。ポリシーは、冗長、すぐに廃れてしまう、又は処理するのにコストのかかり過ぎる通知の処理を阻止することができる。例えば、テンポラリファイルの作成、更新、削除の連続のような必須でない作業を避けるため、ブローカー104は、それらをアプリケーションに送り出す前に、一連のバッファを調べることができる。具体的には、ブローカーは、如何なる削除動作についてもバッファをスキャンし、同じキー上に任意の他の動作が在る点までスキャンし、見つかった場合にはそれらのバッファエントリを削除することができる。1つのファイルの連続したブロックへの複数の書き込みは、合体して、変更データ全範囲に及ぶ１つの書き込み通知になる。
【００６０】
もう1つの例は、非常に頻繁に、おそらく毎秒又はそれ以上、特定のファイルが変更される状況を含む。おそらくこのファイルは、一度に1行ずつ追加されるログファイルである。この状況に対処するために、ブローカー104は、ファイル名、及び関連のある最新の更新時刻のキャッシュを維持することができる。ブローカー104は通知を受け取るたびに、このファイルにおける過去の変更の頻度についてキャッシュを調べることができる。変更が速すぎる場合には、1分間に2度の変更にするようにさらに言い、次にそのファイルに対する待ち状態の変更要求を削除する。一旦そのファイルが「落ち着く」と、ブローカー104はその最後の要求を処理する。変更の頻度(その割合が急速に変更するファイルを定義する)のスレッショルドは、ファイルシステムの機能に依って、設定可能とすることができる。
【００６１】
復元/再同期
万一、外部アプリケーションがファイルシステムと同期が取れなくなる場合には、ブローカー104は、ファイルシステム内の各ファイルについて作成イベントを生成することができ、従って外部データベースを再作成するという効果を持つ。この完全な同期機能は、必要なときに手動で及び/又は自動的に、起動することができる。
【００６２】
万一、何かのアプリケーションがクラッシュする場合には、そのアプリケーションは、再起動と同時に、ブローカー104への通信接続を再確立し、ブローカー104が通知の送信を再開すべき、又はアプリケーションがブローカーに最後に中断したところからトランザクションの送信を再開させることを選択できるトランザクションを確立するために、識別シーケンス番号を送る。
【００６３】
以下は、システム100のアプリケーションを説明する。ブローカー104は、一又はそれ以上の検索エンジンの索引作成器と接続できる。各索引作成器は、ソケットで１つずつトランザクション通知を受け取り、バックグラウンドでそれらを正しい連続した順番でVDK(Verity開発キット、K2デベロッパーとしても知られている)に提出する「ソケットサーバー」とすることができる。VDKは、プログラマーがVerityの検索技術を自分自身のプログラム/製品に組み入れることを可能にするC言語で書かれるAPIライブラリである。collsvcプロセスは、コレクションを提供する。親プロセスは、ソケットサーバー及びcollsvcアプリケーションの双方を起動させる。この実施形態は、索引作成器が全く「手出しをしない」ことを可能にする。通知システムは、完全に索引作成器を維持することができる。さらに、通知システムは、数時間又は数日ではなくほんの数秒という非常に短い潜伏期で、検索に利用可能なファイルを提供することができる。
【００６４】
ブローカー104は、ファイル変更についてクライアントアプリケーションに通知することができ、かつ、クライアントアプリケーションは、コマンドラインのファイル名入力を受け入れるウィルススキャンソフトウェアを呼び出すことができる。ファイルシステムは、そのファイルがスキャンされるまで、変更されたファイルへのアクセスを妨げることができる。
【００６５】
通知システム100は、CGI(共通ゲートウェイインターフェース)又はJavaスクリプトを処理することができ、従って、ユーザーが自分自身の能動的通知スクリプトを作成することが可能となる。能動的通知スクリプトは、ファイルを検査及び送るためのユーザー定義のロジックを含むことができる。例えば、能動的通知スクリプトは、ニュースのストリーミング、又は財務データを提供するためのロジックを含むことができる。その処理は、複数のフィルターがストリームを伝って通知を渡す場合に、「ストリームセグメント」によって生じることができ、どのストリームセグメントも、それが望むように通知を処理する、又は通知をストリームに付加することを決めることができる。
【００６６】
通知システム100は、構造化されていないコンテンツドキュメント、XMLタグ抽出、マイクロソフトオフィスのプロパティシート、ファイル/サブディレクトリ名、ユーザーレベルの基本設定、及び管理者の基本設定、に基づくコンテンツ管理機能を提供することができる。例えば、あるファイルは、ファイルが変更される度にそのファイルのバックアップを作成すべきであることを示すXMLタグを含むことができる。このファイルが変更したことを通知システムが検知するとき、自動的にファイルのバックアップをとることができる。
【００６７】
本発明は、デジタル電子回路で、又はコンピュータハードウェア、ファームウェア、ソフトウェアで、又はそれらの組み合わせで実施することができる。本発明は、コンピュータープログラム製品、すなわち、例えばマシン読み取り可能なストレージデバイス又は実行における伝播信号で具現化されるコンピュータープログラムのような情報搬送体、又は例えばプログラム可能なプロセッサ、コンピューター又は複数のコンピューターのようなデータ処理装置の動作を制御するためのコンピュータープログラム、として実施することができる。コンピュータープログラムは、コンパイルされる、又はインタプリタされる言語を含む任意の形のプログラム言語で書くことができ、独立型プログラムとして、又はモジュール、コンポーネント、サブルーチンとして、又はコンピューティング環境での使用に適した他の装置を含む任意の形で採用することができる。コンピュータープログラムは、1つのサイトの１つのコンピューター上又は複数のコンピューター上で実行させる、又は複数のサイトにわたって配信するために、及び通信ネットワークで相互接続させるために、採用することができる。
【００６８】
本発明の方法のステップは、入力データの操作及び出力の生成によって本発明の機能を実施するために、コンピュータープログラムを実行する一又はそれ以上のプログラム可能なプロセッサにより、実施することができる。方法のステップはまた、特殊目的のロジック回路、例えばFPGA(プログラム可能なゲートアレイ)又はASIC(特定用途向け集積回路)により実施することができ、及び、本発明の装置は、その特殊目的のロジック回路として実装することができる。
【００６９】
コンピュータプログラムの実行に適したプロセッサは、例として、汎用目的及び特殊目的双方のマイクロプロセッサ、及び任意の種類のデジタルコンピューターの任意の一又はそれ以上のプロセッサを含む。一般的には、プロセッサは、読み取り専用メモリ、又は読み書き可能メモリ、又は両方から、命令及びデータを受け取るであろう。コンピューターの必須構成要素は、命令を実行するためのプロセッサ、及び、命令及びデータを格納するための一又はそれ以上のメモリデバイスである。一般的に、コンピューターはまた、例えば磁気ディスク、光磁気ディスク、又は光ディスクのようなデータを格納するための一又はそれ以上の大容量ストレージデバイスを含む、又は、それらからデータを受け取るように、又はそれらにデータを送るように、又はその双方のように、それらに結合されるであろう。コンピュータープログラムの命令及びデータを具現化するのに適した情報搬送体は、あらゆる形の不揮発性メモリを含み、これには例として、例えばEPROM、EEPROM、及びフラッシュメモリデバイスのような半導体メモリデバイス、内蔵ハードディスク、及び外付けディスクのような磁気ディスク、光磁気ディスク、及びCD-ROM及びDVD-ROMディスクを含む。プロセッサ及びメモリは、特殊目的のロジック回路により補われる、又は特殊目的のロジック回路に搭載される。
【００７０】
ユーザーとの対話を提供するために、本発明は、ユーザーに情報を表示するためのCRT(ブラウン管)又はLCD(液晶ディスプレイ)モニターのようなディスプレイデバイス、及びキーボード、及びそれによってユーザーがコンピューターに入力を提供できるマウス又はトラックボールのようなポインティングデバイス、を持つコンピューター上で実施することができる。同様に、他の種類のデバイスも、ユーザーとの対話を提供するのに使用することができる。例えば、ユーザーに提供されるフィードバックは、視覚フィードバック、聴覚フィードバック、又は触覚フィードバックのような任意の形の感覚フィードバックとすることができ、ユーザーからの入力は、音響、音声、又は触感の入力を含む任意の形で受け取られることができる。
【００７１】
本発明は、例えばデータサーバーのようなバックエンドコンポーネント、又は例えばアプリケーションサーバーのようなミドルウェアコンポーネント、又は例えばユーザーがそれを通して本発明の実装と対話できるようなGUI又はウェブブラウザを持つクライアントコンピューターのようなフロントエンドコンポーネント、又はこのようなバックエンド、ミドルウェア、又はフロントエンドのコンポーネントの任意の組み合わせを含むコンピューティングシステムで実施することができる。システムのコンポーネントは、例えば通信ネットワークのようなデジタルデータ通信の任意の形態又は媒体により、相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)、広域ネットワーク(「WAN」)、及びインターネットを含む。
【００７２】
コンピューティングシステムは、クライアント及びサーバーを含むことができる。クライアント及びサーバーは、一般的には互いに離れており、かつ典型的には通信ネットワークを通して相互作用する。クライアントとサーバーの関係は、それぞれのコンピューター上で動作し、かつ互いにクライアント−サーバー関係を持つコンピュータープログラムによって生じる。
【００７３】
本発明の多数の実施を説明した。しかしながら、本発明の技術的範囲からはずれることなく、様々な変更がなされ得ることを理解するであろう。例えば、名称検索機構は、CNエントリがCNログ204からキュー308の中にコピーされるような実行中に生じる、と説明された。しかしながら、名称検索機構は、そのかわりに、例えば通知がキュー308から読み出されているような異なる段階で生じることもできる。レコーダーは、コンピューティング環境内で複数のファイルシステムが実施される場合、複数のファイルシステムの各々に実装することができる。ブローカーは各レコーダーについて実装することができる、又は１つのブローカーが複数のレコーダーの応対をすることができる。
【図面の簡単な説明】
【００７４】
【図１】本発明による通知システムを示している。
【図２】本発明によるブローカーを示している。
【００７５】
異なる図面における同じ参照記号は、同じ要素を示している。
【図１】
2005515556.tif 000003
【図２】
2005515556.tif 000004
【手続補正書】
【提出日】平成16年11月29日(2004.11.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
変更通知を一又はそれ以上の外部アプリケーションに配信する要求を受け取るステップと、
ファイルシステム内の一又はそれ以上のファイルへの検出された変更を含む記録を変更ログから検索すること、及び
前記一又はそれ以上の外部アプリケーションに前記記録を配信すること、
により、前記要求に応答するステップ、
を含み、前記記録を配信するステップは、前記要求を受け取るより前に検出された変更を含む記録を配信することを含む、ことを特徴とする方法。
【請求項２】
配信不可能な記録を、前記記録が配信できるようになるまでバッファリングするステップ、
をさらに備える請求項1記載の方法。
【請求項３】
一又はそれ以上の前記記録を、前記外部アプリケーションに配信する前に、汎用フォーマットからアプリケーション固有のフォーマットに変換するステップ、
をさらに備える請求項1記載の方法。
【請求項４】
ファイルが通知変更の対象であるかどうかを判断するステップ、及び
変更通知の対象であるファイルに対応する前記記録のみを配信するステップ、
をさらに備える請求項1記載の方法。
【請求項５】
冗長、又は間もなく陳腐化する記録を選別して除去するステップ、
をさらに備える請求項1記載の方法。
【請求項６】
前記一又はそれ以上の外部アプリケーションが、バックアップアプリケーションを含む、
請求項1記載の方法。
【請求項７】
前記要求が、前記ファイルシステム内の前記一又はそれ以上のファイルへの変更を検出しかつ前記変更を前記変更ログに記録するレコーダー、から受け取られ、
前記要求が、前記レコーダーと独立して動作するブローカーによって受け取られ、かつ応答される、
請求項1記載の方法。
【請求項８】
情報搬送体内に具現的に実施され、データ処理装置に請求項1記載のステップを実行させることができる命令を備える、
コンピュータープログラム製品。
【請求項９】
前記命令が、請求項2から請求項7までのいずれかに記載の前記ステップを実行する命令をさらに備える、
請求項8記載の製品。
【請求項１０】
請求項1記載の前記ステップを実行することができる装置、
を備えることを特徴とするシステム。
【請求項１１】
請求項2から請求項7までのいずれかに記載の前記ステップを実行することができる装置、
をさらに備える請求項10記載のシステム。
【国際調査報告】
2005515556.tif 000005