JP5395532B2 - クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム - Google Patents
クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム Download PDFInfo
- Publication number
- JP5395532B2 JP5395532B2 JP2009147852A JP2009147852A JP5395532B2 JP 5395532 B2 JP5395532 B2 JP 5395532B2 JP 2009147852 A JP2009147852 A JP 2009147852A JP 2009147852 A JP2009147852 A JP 2009147852A JP 5395532 B2 JP5395532 B2 JP 5395532B2
- Authority
- JP
- Japan
- Prior art keywords
- handle
- file
- parent
- event
- child
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
例えば、非特許文献1に記載のクライアント/サーバ型の分散ファイルシステムにおいて、各クライアントは、サーバからファイルの内容を一度でも読み込むと、そのファイルの内容をキャッシュする。一般的に、キャッシュは、キャッシュコヒーレンシ(Cache Coherency)が課題となる。つまり、サーバ側でファイルの内容の更新が要求された際に、そのファイルの内容をキャッシュしている各クライアントがそれぞれ保持している情報の均一性を保つことが課題となる。
本発明の実施形態に係るコンピュータシステム1のハードウェア構成を図1に示す。
本実施形態では、クライアント/サーバ型(以下、C/S型という)のコンピュータシステム1は、オペレーティングシステム(OS:Operating System)等により構築された、LAN(Local Area Network)上での分散コンピュータシステムとして構成した。図1に示すように、コンピュータシステム1は、ネットワークNを介して通信可能に接続された、サーバコンピュータ(サーバ装置)2と、クライアントコンピュータ(クライアント装置)3とを備えている。ここで、サーバコンピュータ2と、クライアントコンピュータ3の台数は任意である。
クライアントコンピュータ3の永続性記憶装置7は、クライアント側データ10と、親子ハンドル管理プログラム15と、ロック制御管理プログラム16と、イベント通知制御プログラム17と、キャッシュ情報登録プログラム18とを記憶している。
なお、各データおよびプログラムの詳細については後記する。
コンピュータシステム1において、クライアントコンピュータ3が、中央のサーバコンピュータ2で管理するファイルやディレクトリを示す資源を操作するためのキーとしてのハンドルを管理することを前提としている。前記のハードウェア構成と図2に示す論理構成を前提として、コンピュータシステムにおける前提条件と、ハンドルを含む用語の定義を以下に記述する。
ハンドルとは、ある管理された領域の外側から、内側のオブジェクトを操作するためのキーとなるデータ、ポインタ、インスタンスである。例えば、Windows(登録商標)システムでは、OSによって管理された領域中の資源を、OS上で実行されているプログラムから操作する際に、ハンドルを用いる。例えば、ハンドルを用いてファイル、プロセス、スレッド、デバイスなどを操作することができる。Windowsシステムでは、ハンドルは32ビットの整数により表現される。本実施形態では、それのメタファーとして、ハンドルという用語を用いる。ここでは、親ハンドルや子ハンドルと区別せずに総称してハンドルと呼ぶこととする。ハンドルを用いる、前記したある管理された領域とは、サーバによって管理されたファイルシステムの領域であり、ファイルシステムを管理するのはサーバである。また、クライアントアプリケーション31(図2参照)は、ハンドルを通じてサーバ上のファイルを操作する。本実施形態のコンピュータシステム1では、ハンドルは、クライアントコンピュータ3中のメモリ上に構築された構造体を指すポインタであり、メモリ領域上にはハンドルやファイルに関連する情報(サーバ情報、ファイル名)が格納されている。
ファイルおよびディレクトリに関しては、一般的なOSにおけるファイルシステムと同様の概念である。このうち、ファイルに対しては、作成、削除、読込、書込(更新)、ロック取得、ロック解除(ロック解放)のオペレーションが可能である。同様に、ディレクトリに対しては、作成、削除、一覧表示のオペレーションが可能である。以下、ファイルとディレクトリを総称する場合にノードと呼ぶことにする。
コンピュータシステム1の論理構成を図2に示す。
C/S型ファイルシステムにおけるサーバとは、複数のファイルおよびディレクトリを特定する名前空間を持ち、バイト配列を記録するファイルと、より下位のファイルおよびディレクトリを管理するディレクトリとに対して、オペレーションおよびサービスを、ハンドルを用いてネットワークを通じて提供するプログラムによって動作しているプロセスを示す。ここで、サービスとは、イベント監視やイベント通知を指す。なお、同様に、オペレーションおよびサービスを、ネットワークを通じて提供するコンピュータがサーバコンピュータ2である。図2に示すサーバ(サーバプログラム)21は、プログラムによって動作しているプロセスに当たる。なお、サーバ21は、バックエンドデータベース22に、ファイルシステムとして複数のファイルおよびディレクトリを特定する名前空間25を持っている。
C/S型ファイルシステムにおけるクライアントとは、ネットワークを隔てたサーバ内のファイルシステムについてサーバにより提供される各種サービスを利用して、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするプログラムにより動作しているプロセスを指す。同様に、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするコンピュータがクライアントコンピュータ3である。図2に示すクライアントコンピュータ3は、プログラムによって動作しているプロセスとして、クライアントアプリケーション(アプリケーション部)31と、クライアントライブラリ(ライブラリ部)32とを備えている。クライアントアプリケーション31はサーバ21上の各種サービスを利用する。クライアントライブラリ32は、クライアントアプリケーション31からの操作を受け付け、サーバ21との通信を媒介する。
セッションとは、クライアントライブラリ32とサーバ21との通信の単位であり、クライアントコンピュータ3上に1つまたは複数起動されているプロセスと、サーバ21との通信を区切る単位である。
サーバ21が冗長化されており、故障によりフェイルオーバした場合、セッションおよび永続化されていたファイルシステムの内容は、フェイルオーバ後のサーバにも引き継がれる。このような場合、セッションが切れるのは、次の3つのケースのみである。
(1)クライアントがセッションを切った場合
(2)サーバとクライアント間のネットワークが一定時間以上不通となった場合
(3)サーバが多重故障した場合
1つのクライアントは、論理的に異なる複数のサーバのそれぞれに対して、最大で1つのセッションを生成することができる。
ここで、クライアントアプリケーション31とクライアントライブラリ32は、1対1のセットの構成をとって、このセットがクライアントコンピュータ2内に複数あってもよく、複数のクライアントアプリケーション31と1つのクライアントライブラリ32とが対応付けられている構成(N対1)であってもよい。
なお、以下では、簡便のため、1対1のセットの構成をとって、クライアント(クライアント装置)として説明する。単にクライアント(クライアント装置)あるいはクライアント毎(クライアント装置毎)と表現するときには、クライアントアプリケーション31あるいはクライアントアプリケーション31毎であることを表すこととする。
クライアントとサーバの間でセッションが張られている場合に限り、クライアントは、
サーバ上の“ファイルおよびディレクトリ”をオープンし、サーバによって管理されている領域にあるファイルを操作することができる。すなわち、ハンドルとは、サーバによって管理されている領域(ファイルシステム)上にある資源(ファイルおよびディレクトリ)に対する操作を行うために、サーバがクライアントに提供するキーである。また、ハンドルとは、クライアントが操作する資源をサーバに指示するために、サーバがクライアントに提供するキーでもある。親子ハンドルについては後記する。
図2に示すクライアントアプリケーション31は、ハンドルを通じて、“ファイルおよびディレクトリ”に対して、作成、削除、イベント監視要求およびその応答の受付、の各オペレーションを実行できる。
また、クライアントアプリケーション31は、ファイルに対してのみ、書込、読込、ロック取得、ロック解除、の各オペレーションを実行できる。
さらに、クライアントアプリケーション31は、ディレクトリに対してのみ、下位ファイルおよびディレクトリの一覧表示のオペレーションを実行できる。
図2に示すクライアントアプリケーション31は、ハンドルを用いて、“ファイルおよびディレクトリ”に対するロックを取得することができる。ロックとは、ファイルに対するアクセスを排他する手段である。ここでは、ハンドルを用いて、例えばあるファイルへアクセスする際に、同じファイルに別ハンドルを用いアクセスすることを排他するような場合を、“ハンドルがロックを取得している”と表現する。ロックを取得している子ハンドルは、ロックを取得していない子ハンドルと明確に区別される。
クライアントアプリケーション31は、クライアントライブラリ32に対して、ロック取得依頼(ロック取得依頼メッセージ)を作成する。ロック取得依頼は、セッションにおいてサーバ側に記憶されたファイルシステム62で管理されたファイルまたはディレクトリに対するロックを子ハンドルが取得することを要求するものである。
なお、アクセスを排他する手段とは、物理的な構成ではなく情報であり、例えば、排他する権利や権限を有していることを示す識別情報や証明書を含むことができる。
アドバイザリロックは、ファイルに対するロックの取得だけを排他する。アドバイザリロックを用いてファイルへアクセスする場合は、ファイルに対する処理をアプリケーション同士の紳士協定によって排他する。
マンダトリロックは、ファイルに対する特定のオペレーションを禁止し、ロックを取得しているハンドルだけが特定のオペレーションを実行することができる。
アドバイザリロックとマンダトリロックとを比較した場合、一般的にはアドバイザリロックの方が軽量で計算コストが少ないという性質がある。一方、マンダトリロックは、安全性が高いが、計算コストも高いという性質がある。
排他ロックとは、1つのハンドルに対してのみ取得できるものである。すなわち、ある“ファイルおよびディレクトリ”に対する排他ロックを取得しているハンドルは、常に1個または0個である。
共有ロックとは、複数のハンドルにより共有することができるロックである。すなわち、共有ロックが既に取得されている“ファイルおよびディレクトリ”に対しては、排他ロックを取得することができない。
イベントとは、サーバの状態に変化が起きた際に、その変化それ自体を指す。イベントには、変化の種別が識別されるコード、内容およびタイミングの情報を含む。
サーバは、“ファイルおよびディレクトリ”の状態に変化が起きた際に、イベントをクライアントに対して通知することができる。なお、イベントは、ファイルおよびディレクトリの少なくとも1つの状態の変化を示す。
また、図2に示すクライアントライブラリ32は、サーバ上のファイルの変化を検知してクライアントアプリケーション31に対してイベントを通知することができる。
ここでは、“ファイルおよびディレクトリ”に関するイベントのことをノードイベントと呼ぶ。本実施形態では、例えば合計8種類のノードイベントを想定している。
(1)ハンドル無効化(ノード削除等によりノードにアクセスできなくなった)
(2)マスタのフェイルオーバ(マスタ(サーバ)がフェイルオーバし、一部のイベント通知が欠送した可能性がある)
なお、フェイルオーバ(Fail-over)は、例えば、優先順位の高い回線に異常が発生したときに、メッセージトラフィックが次に優先順位の高い回線に途切れることなく送信されることを示す。
ファイルイベントには、例えば次の4種類がある。
(3)コンテンツ更新(ファイルの内容の更新が行われた)
(4)メタ情報更新(ファイル属性の更新が行われた)
(5)ロック取得(ロックの取得に成功した)
(6)ロック解除(ファイルがロックされていない状態になった)
ディレクトリイベントには、例えば次の2種類がある。
(7)ノード作成(ディレクトリ下にノードが作成された)
(8)ノード削除(ディレクトリ下のノードが削除された)
図2に示すサーバ21およびクライアントライブラリ32では、イベントをマスク値によって管理する。
本実施形態では、上記の通り、例えば(1)〜(8)の8種類のイベントがある。それぞれのイベントについては、「要通知」、「通知不要」の2通りの登録状態がある。これに対して、本実施形態では8ビットのそれぞれの桁にイベントを割り付け、あるイベントに対して、それに対応するビットが「0」であれば「通知不要」、「1」であれば「要通知」として管理することとした。なお、ビットの0,1の集合をリスナと呼び、ビットの0,1を適宜入れ替えることで、リスナのオンオフを切り替える。なお、図4には、6種類のイベントに対応した例を示した。
<3−1>個数および管理の関係
ハンドルは、親ハンドルと子ハンドルから構成される。同一セッション内においては、オープンされているファイルにつき、親ハンドルは必ず1つ確保される。
子ハンドルは、図2に示すクライアントアプリケーション31がオープン操作を実行した回数だけ、クライアント側で確保される。クライアントから、“ロック要求”が発生するまで、サーバ側では、子ハンドルは管理しない。
親ハンドルとは、図2に示すクライアントライブラリ32が、サーバ21に対する処理を要求する際に用いるハンドルである。
サーバ21は、親ハンドルを用いて、クライアントを識別すると共に、要求されているものがファイルなのかディレクトリなのかを識別する。
図2に示すクライアントライブラリ32は、子ハンドルを用いたクライアントアプリケーション31からの要求に応じて、サーバ21に対する処理を要求する。なお、親ハンドルは、クライアントアプリケーション31毎に作成される。
子ハンドルとは、図2に示すクライアントアプリケーション31が、サーバ21に対する処理をクライアントライブラリ32に要求する際に用いるハンドルである。
従って、クライアントアプリケーション31は、子ハンドルの単位で、ファイルシステムに対する処理を要求する。
本実施形態で定義する子ハンドルは、従来技術で定義されるところの“ハンドル”やファイルディスクリプタに相当する。すなわち、図2に示すクライアントアプリケーション31は、“ファイルおよびディレクトリ”のオープンに対して、必ず別々のハンドルが提供される。
<4−1>ハンドル作成およびハンドル削除
本節では、ハンドルのライフサイクルおよび具体的なデータ構造について説明する。
ここでは、場合分けとして、親ハンドルと子ハンドルそれぞれについて(2通り)、クライアント側のハンドルかサーバ側のハンドルか(2通り)、ハンドルの生成のタイミングおよび破壊のタイミング(2通り)の組み合わせに関して、8通りのケースについて説明する。
クライアント側で親ハンドルが生成されるタイミングは、図2に示すクライアントアプリケーション31が、クライアントライブラリ32にパス指定で、ノードオープンを最初に要求した際のみである。
サーバ側で親ハンドルが生成されるタイミングは、図2に示すクライアントライブラリ32が、ネットワーク通信を経て、オープンを要求したときのみである。
(1)セッションが切断した場合
(2)該当するノードが削除された場合
(3)親ハンドル用のメモリ領域が不足しており、かつ、クローズ済みのハンドルが存在する場合
(1)ハンドルを持っているセッションが切断した場合
(2)該当するノードが削除された場合
(3)クライアントから明示的にクローズを要求された場合
クライアント側で子ハンドルが生成されるタイミングは、図2に示すクライアントアプリケーション31が、クライアントライブラリ32にパス指定で、ノードオープンを要求した際である。
サーバ側で子ハンドルが生成されるタイミングは、図2に示すクライアントアプリケーション31が、明示的にロック取得を要求した場合のみである。
サーバ側で子ハンドルが削除されるタイミングは、図2に示すクライアントアプリケーション31がロックの解除およびロック待ちの解除を要求し、成功した場合、および、セッションが切断した場合である。ただし、上記の解除のオペレーションは失敗しない前提であり、セッションがなくなれば、サーバ側では自動的に解除する。
クライアント側の親ハンドルで管理される情報は、サーバと共通のハンドルID、ノードパスおよび子ハンドルのリスト、後記するイベントマスクの値であり、ファイルの場合には、さらに、ファイルの内容のキャッシュが管理される。
クライアント側の子ハンドルで管理される情報は、同じ親ハンドルを持つ子ハンドルを区別できる子ハンドルID、ロック取得状態、イベントマスクの値である。
親ハンドルについては、サーバ側では、キャッシュを除きクライアントと同様の情報を管理する。
サーバ側では、あるファイルに対して、次の5つの情報を保持する。
(1)ファイルをオープンしているハンドル全て
(2)ファイルに対するイベントを監視しているハンドル全て
(3)ファイルの内容をキャッシュしているハンドル全て
(4)ファイルに対するロック取得済みハンドル
(5)ファイルに対するロック待ち行列のリスト
≪書込みの集約および読込みの集約≫
本実施形態では、非特許文献1の方法と同様に、ファイルの内容を一度でも読み込んだクライアントは、図2に示すクライアントライブラリ32内にてファイルの内容をキャッシュする。ただし、本実施形態では、1つのクライアントプロセス内での同じファイルに対するキャッシュは、親ハンドルに対応づけて管理する。これにより、重複している一次記憶領域(メモリ)を低減し、ファイルの内容を転送する通信量および通信回数を節約することができる。すなわち、例えば図2に示す片方の子ハンドル34により、一度読み込まれたファイルの内容は、同じクライアントが保持している別の子ハンドル34による読み込みの際でも、キャッシュを保持することができる(図10参照)。
<6−1>イベント監視の登録および集約
図2に示すクライアントアプリケーション31は、クライアントライブラリ32にイベント監視要求を行う際、イベント種別およびイベント通知時の処理(コールバック処理)を登録する。ここで、クライアントアプリケーション31は、イベント監視要求を行うときに、クライアントライブラリ32に対して、イベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼(イベント監視登録依頼メッセージ)を作成する。クライアントアプリケーション31は、イベント監視登録依頼を作成する際に、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値とを示すコールバック処理の情報をクライアントライブラリ32に登録する。
クライアントライブラリ32は、イベント種別に対応する子ハンドルの真偽値記憶領域を更新し、一時記憶領域(メモリ)にコールバック処理を記憶する。ここで、クライアントライブラリ32の親子ハンドル管理手段131は、ハンドルリスト52において、イベント監視登録依頼で用いられる子ハンドルに対して、コールバック処理の情報であるイベント毎のマスク値の集合をイベントマスクとして付与して記憶する。
次に、クライアントライブラリ32は、親ハンドルとサーバとに登録するイベントマスク値を計算する。
あるハンドルの親ハンドルをP、子ハンドル集合を
とする。このハンドルが登録している、あるイベント種別eiについて、サーバに登録されるリスナの真偽値Lp(ei)は、論理和を用いて、式(1)によって定義される。
これを受信したサーバは、
の値を登録する(図5、図11参照)。なお、iの最大値「8」は一例であって、イベント種別eiは、8種類に限定されるものではない。
あるハンドルがイベント監視を登録している“ファイルおよびディレクトリ”において、イベントが発生した場合に、イベント通知が、クライアント側の子ハンドルに届くまでを説明する。
サーバ内で、イベントが発生した場合、サーバプログラム21は、該当するイベントを監視している親ハンドル(クライアントアプリケーション31に相当する)を列挙し、それらのハンドルを所有しているクライアント(クライアントアプリケーション31に相当する)に対して、ネットワークを通してイベント通知を行う。クライアントライブラリ32は、イベント通知をサーバより受信した後、イベント種別eiを判定し、
が真である子ハンドルCjにのみ、イベントを通知し、指定する領域に保存されているコールバック処理を実行する(図6、図12参照)。これによって、1つのクライアント(クライアントアプリケーション31に相当する)における、子ハンドルに対するイベント関連の処理を集約することができ、本来は子ハンドルの個数分だけ必要であった通信を、ただ一度だけの通信で完了することができる。
(第1実施形態)
<7−1>具体的な構成
図1〜図4を参照して、第1実施形態のコンピュータシステム1におけるサーバコンピュータ2およびクライアントコンピュータ3の詳細な構成を説明する。
≪サーバ側≫
図1を参照して、サーバコンピュータ2の永続性記憶装置7に格納された情報について説明する。
ファイルデータ8は、読込み/書込み対象のファイルの内容を示すデータである。
サーバ側データ9は、図3(b)に示すように、ハンドルリスト61と、ファイルシステム62と、セッションリスト63と、ロック取得リスト64とを備えている。
ハンドルリスト61には、親ハンドルと、監視対象のイベントの情報が記述される。その詳細は後記する。
ファイルシステム62には、ファイルデータ8の名前空間におけるファイルおよびディレクトリが記述されている。
セッションリスト63には、サーバに接続されているクライアントの管理情報(イベント通知先等)が記述されている。
ロック取得リスト64には、ロック取得状態の情報や子ハンドルの情報が記述されている。
サーバコンピュータ2において、永続性記憶装置7に格納されたハンドル管理プログラム11、ロック管理プログラム12、キャッシュ管理プログラム13、イベント管理プログラム14を、CPU4が読み込んで、メモリ5に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図4(b)に示すサーバ21内のハンドル管理部121、ロック管理部122、キャッシュ管理部123、イベント管理部124として動作する。これらハンドル管理部121、ロック管理部122、キャッシュ管理部123、イベント管理部124の動作については後記する。
また、同様に、セッション管理部126は、サーバとクライアントとのセッションを管理するものである。
図1を参照してクライアントコンピュータ3の永続性記憶装置7に格納された情報について説明する。
クライアント側データ10は、図3(a)に示すように、キャッシュリスト51と、ハンドルリスト52とを備えている。
キャッシュリスト51には、キャッシュ情報が記述されている。
ハンドルリスト52には、親ハンドルの識別情報と子ハンドルのの識別情報とが関連付けられて記述される。その詳細は後記する。
クライアントコンピュータ3において、永続性記憶装置7に格納された親子ハンドル管理プログラム15、ロック制御管理プログラム16、イベント通知制御プログラム17、キャッシュ情報登録プログラム18をCPU4が読み込んで、メモリ5に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図4(a)に示すクライアントライブラリ32内の親子ハンドル管理部131、ロック制御部132、イベント通知制御部133、キャッシュ情報登録部134として動作する。これら親子ハンドル管理部131、ロック制御部132、イベント通知制御部133、キャッシュ情報登録部134の動作については後記する。
コンピュータシステム1で利用されるハンドルリストのデータ構造の一例を図4に示す。図4(a)にはクライアント側のハンドルリスト52、図4(b)にはサーバ側のハンドルリスト61を対比してそれぞれ示している。
図5(a)に示すイベントマスク501は、前記した式(1)において、サーバに登録されるリスナの真偽値Lp(ei)の集合を模式的に示したものである。ここでは、一例として、8種類のイベント種別として、ハンドル無効化e1と、マスタフェイルオーバe2と、コンテンツ更新e3と、メタ情報更新e4と、ロック取得e5と、ロック解除e6と、ノード作成e7と、ノード削除e8とを想定した。なお、ノード種別の数は、任意である。
図6(a)に、図5(b)に示した親ハンドルのマスク値(イベントマスク504)を示す。また、図6(b)に、図5(b)に示した子ハンドル1および子ハンドル2のマスク値(イベントマスク502,503)を示す。
図6(a)および図6(b)に示す例において、図4(b)に示すサーバ21内のイベント管理部124による動作と、図4(a)に示すクライアントライブラリ32内のイベント通知制御部133による動作とを、次の4つのケースについて説明する。
この場合には、図6(a)に示した親ハンドルのマスク値(イベントマスク504)において、ハンドル無効化e1の値は、「0」、つまり、フラグが偽であるため、イベント管理部124は、イベントの発生を親ハンドル(クライアントアプリケーション31に相当する:以下同様)に通知しない。したがって、サーバからクライアントへのイベント通知はない。
この場合には、図6(a)に示した親ハンドルのマスク値(イベントマスク504)において、マスタフェイルオーバe2の値は、「1」、つまり、フラグが真であるため、イベント管理部124は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。
この場合、クライアント側のイベント通知制御部133は、図6(b)に示した子ハンドル1のマスク値(イベントマスク502)において、マスタフェイルオーバe2の値が、「1」、つまり、フラグが真であると判定し、子ハンドル1(クライアントアプリケーション31の集約した処理のうちの1つに相当する:以下同様)のみに通知する。
この場合には、図6(a)に示した親ハンドルのマスク値(イベントマスク504)において、コンテンツ更新e3の値は、符号601で示すように「1」であるため、イベント管理部124は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。この場合、クライアント側のイベント通知制御部133は、図6(b)に示した子ハンドル1のマスク値(イベントマスク502)において、コンテンツ更新e3の値が、符号602で示すように「0」であると判定し、一方、子ハンドル2のマスク値(イベントマスク503)において、コンテンツ更新e3の値が、符号603で示すように「1」であると判定するので、子ハンドル2のみに通知する。つまり、イベント通知制御部133は、親ハンドルと、子ハンドルの該当するマスク値の論理積が真である場合に、その子ハンドルにイベント通知を行う。
この場合には、図6(a)に示した親ハンドルのマスク値(イベントマスク504)において、ロック取得e5の値は「1」であるため、イベント管理部124は、イベントの発生を親ハンドルに通知する。この場合、クライアント側のイベント通知制御部133は、図6(b)に示した子ハンドル1,2のマスク値(イベントマスク502,503)の双方において、ロック取得e5の値が「1」であるので、子ハンドル1,2の双方に通知する。以下、同様に振り分けることができる。
次に、コンピュータシステム1の動作について、図7乃至図12を参照(適宜図1乃至図6参照)して説明する。
<7−2−1>ハンドル作成処理
図7に示すハンドル作成処理は、図4(a)に示すクライアントライブラリ32内の親子ハンドル管理部131の動作と、図4(b)に示すサーバ21内のハンドル管理部121の動作により行われる。
(a)フラグにおいて、ファイル作成オプションがONの場合
(a1)ファイルがあっても成功
(a2)ファイルがなければ作成し、オープンは成功
(b)フラグにおいて、ファイル作成オプションがOFFの場合
(b1)ファイルがあれば成功
(b2)ファイルがなければ失敗
図8に示すロック取得処理および子ハンドル登録処理は、図4(a)に示すクライアントライブラリ32内のロック制御部132の動作と、図4(b)に示すサーバ21内のロック管理部122の動作により行われる。
図8に示すように、クライアント側において、クライアントライブラリ32は、クライアントアプリケーション31から、ロック取得依頼を受領する(ステップS21)。このとき、クライアントアプリケーション31から、子ハンドルを受領する。クライアントライブラリ32は、受領した子ハンドルが有効か否かを判別する(ステップS22)。なお、受領した子ハンドルの子ハンドルIDが登録されている場合に当該子ハンドルを有効であると判定することができる。
また、前記したステップS22において、クライアントアプリケーション31から受領した子ハンドルが無効である場合(ステップS22:No)、クライアントライブラリ32は、クライアントアプリケーション31に、ロック取得の失敗を通知する(ステップS32)。
図9に示すロック解除処理および子ハンドル登録削除処理は、図4(a)に示すクライアントライブラリ32内のロック制御部132の動作と、図4(b)に示すサーバ21内のロック管理部122の動作により行われる。
図9に示すように、クライアント側において、クライアントライブラリ32は、クライアントアプリケーション31から、ロック解除依頼を受領する(ステップS41)。このとき、クライアントアプリケーション31から、子ハンドルを受領する。クライアントライブラリ32は、受領した子ハンドルが有効か否かを判別する(ステップS42)。受領した子ハンドルが有効である場合(ステップS42:Yes)、続けて、クライアントライブラリ32は、子ハンドルが、既にロック取得しているハンドル、または、現在ロック待ちのハンドルであるか否かを判別する(ステップS43)。子ハンドルが既にロック取得しているハンドル、または、現在ロック待ちのハンドルである場合(ステップS43:Yes)、クライアントライブラリ32は、親ハンドルIDと当該子ハンドルIDとを、ロック解除依頼と共にサーバ側に送信する(ステップS44)。
一方、ステップS45において、ロック解除依頼と共に受信した当該子ハンドルが、当当該クライアントによってロック待ちのファイルのものである場合(ステップS45:No)、サーバ21は、受信した子ハンドルを、ロック待ち行列27(図2参照)のロック待ち領域から削除し(ステップS47)、ロック解除依頼応答をクライアント側に返信する。
図10に示すファイル読込処理およびキャッシュ作成処理は、図4(a)に示すクライアントライブラリ32内のキャッシュ情報登録部134の動作と、図4(b)に示すサーバ21内のキャッシュ管理部123の動作により行われる。
図10に示すように、クライアント側において、クライアントライブラリ32は、クライアントアプリケーション31から、ファイル内容取得依頼を受領する(ステップS61)。このとき、クライアントアプリケーション31から、子ハンドルを受領する。クライアントライブラリ32は、受領した子ハンドルが有効か否かを判別する(ステップS62)。受領した子ハンドルが有効である場合(ステップS62:Yes)、続けて、クライアントライブラリ32は、ハンドルリスト52(図4参照)の親ハンドル領域80にキャッシュが存在するか否かを判別する(ステップS63)。親ハンドル領域80(図4参照)に、“キャッシュ保持”を示すキャッシュ状態が記録されていない場合(ステップS63:No)、クライアントライブラリ32は、親ハンドルIDを、ファイル内容取得依頼と共にサーバ側に送信する(ステップS64)。
図11に示すノードイベント監視登録処理は、図4(a)に示すクライアントライブラリ32内のイベント通知制御部133の動作と、図4(b)に示すサーバ21内のイベント管理部124の動作により行われる。
図11に示すように、クライアント側において、クライアントライブラリ32は、クライアントアプリケーション31から、イベント監視登録依頼を受領する(ステップS81)。このとき、クライアントアプリケーション31から、子ハンドルを受領する。クライアントライブラリ32は、受領した子ハンドルが有効か否かを判別する(ステップS82)。受領した子ハンドルが有効である場合(ステップS82:Yes)、続けて、クライアントライブラリ32は、当該子ハンドルのイベントマスク値と、現在の親ハンドルのイベントマスク値との論理和を計算する(ステップS83)。
一方、イベント監視対象のファイルが存在しない場合(ステップS86:No)、サーバ21は、イベント監視登録が失敗したことを示す応答をクライアント側に返信する。
図12に示すイベント通知処理は、図4(a)に示すクライアントライブラリ32内のイベント通知制御部133の動作と、図4(b)に示すサーバ21内のイベント管理部124の動作により行われる。
図12に示すように、サーバコンピュータ2において、ファイルシステム62で管理しているファイルやディレクトリの状態が変化すると、サーバ21は、当該ハンドル(監視ハンドル)に対してイベント発生を検知する(ステップS101)。例えば、図7に示したように、サーバ側において、ハンドル作成時に、サーバ21がファイルを作成し、作成したファイルの親ディレクトリを監視しているハンドル(子ハンドル)がある場合(ステップS12:Yes)、図7および図12の符号「A」で示すように、ステップS101に進む。そして、サーバ21は、ハンドルリスト61(図4参照)から、発生したイベントの通知を受けるように(監視するように)登録されているリスナの情報を抽出し、抽出したリスナ一覧をメモリ5に複製して親ハンドルリストを取得する(ステップS102)。
第1実施形態のコンピュータシステム1は、ベストモードの構成で説明したが、本発明はこれに限定されず、ロック機能を備えずに構成することも可能である。この場合には、図4(a)に示すクライアントライブラリ32内のロック制御部132や、図4(b)に示すサーバ21内のロック管理部122を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
本発明は、イベント監視およびイベント通知機能を備えずに構成することも可能である。この場合には、図4(a)に示すクライアントライブラリ32内のイベント通知制御部133と、図4(b)に示すサーバ21内のイベント管理部124を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
本発明は、キャッシュ機能を備えずに構成することも可能である。この場合には、図4(a)に示すクライアントライブラリ32内のキャッシュ情報登録部134と、図4(b)に示すサーバ21内のキャッシュ管理部123を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
なお、上記ロック機能、イベント監視およびイベント通知機能、キャッシュ機能のうちの任意の2つ以上を備えずに、さらに簡易なコンピュータシステムを構成することも可能である。
2 サーバコンピュータ(サーバ装置)
3(3a,3b) クライアントコンピュータ(クライアント装置)
4 CPU
5 メモリ
6 ネットワークI/F(ネットワークインタフェース)
7 永続性記憶装置
8 ファイルデータ
9 サーバ側データ
10 クライアント側データ
11 ハンドル管理プログラム
12 ロック管理プログラム
13 キャッシュ管理プログラム
14 イベント管理プログラム
15 親子ハンドル管理プログラム
16 ロック制御管理プログラム
17 イベント通知制御プログラム
18 キャッシュ情報登録プログラム
21 サーバ(サーバプログラム)
22 バックエンドデータベース(データベース)
31 クライアントアプリケーション(アプリケーション部)
32 クライアントライブラリ(ライブラリ部)
51 キャッシュリスト
52 ハンドルリスト(クライアント側ハンドルリスト)
61 ハンドルリスト(サーバ側ハンドルリスト)
62 ファイルシステム
63 セッションリスト
64 ロック取得リスト
121 ハンドル管理部(ハンドル管理手段)
122 ロック管理部(ロック管理手段)
123 キャッシュ管理部(キャッシュ管理手段)
124 イベント管理部(イベント管理手段)
125 ファイルシステム管理部
126 セッション管理部
131 親子ハンドル管理部(親子ハンドル管理手段)
132 ロック制御部(ロック制御管理手段)
133 イベント通知制御部(イベント通知制御手段)
134 キャッシュ情報登録部(キャッシュ情報登録手段)
N ネットワーク
Claims (14)
- ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備えるコンピュータシステムにおける前記クライアント装置であって、
前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、
前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部と、を有し、
前記アプリケーション部は、前記ライブラリ部に対して、前記ファイルシステム上のファイルまたはディレクトリの操作に対応するハンドルの作成を要求するハンドル作成依頼を作成し、
前記ライブラリ部は、
前記アプリケーション部から1回目の前記ハンドル作成依頼を受領したときに、前記サーバ装置とのセッションを通じて、前記ハンドルとして前記ファイルシステム上のファイルまたはディレクトリを特定し操作できる親ハンドルを前記サーバ装置から取得し、前記親ハンドルに従属して前記セッションにおいて有効な子ハンドルを生成し、生成した前記子ハンドルを前記アプリケーション部に返却し、前記セッション中に前記アプリケーション部から前記ファイルと同一のファイルに対して、2回目以降のハンドル作成依頼を受領したときに、前記同一のファイルに対応して前記親ハンドルに関連付けて新たに生成した子ハンドルを返却し、前記親ハンドルの識別情報と生成した前記子ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておく親子ハンドル管理手段を備えることを特徴とするクライアント装置。 - 前記アプリケーション部は、前記ライブラリ部に対して、前記サーバ装置の前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル内容取得依頼を作成し、
前記ライブラリ部は、
前記アプリケーション部から前記子ハンドルを用いた1回目の前記ファイル内容取得依頼を受領したときに、前記親ハンドルと共に前記ファイル取得依頼を前記サーバ装置に送信することで、前記サーバ装置から前記ファイルの内容を取得し、取得した前記ファイルの内容を前記親ハンドルに関連付けて記憶手段にキャッシュ情報として登録し、前記セッション中に前記アプリケーション部から、前記1回目のファイル取得依頼と同一のファイルに対して、取得した前記ファイルの内容に関連付けた前記親ハンドルに従属する子ハンドルを用いた2回目以降のファイル内容取得依頼を受領したときに、登録されている前記キャッシュ情報を返却するキャッシュ情報登録手段をさらに備えることを特徴とする請求項1に記載のクライアント装置。 - 前記アプリケーション部は、前記サーバ装置で管理するファイルおよびディレクトリの少なくとも1つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼を子ハンドル毎に作成する際に、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報を前記ライブラリ部に登録し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記ハンドルリストにおいて、前記イベント監視登録依頼で用いられる子ハンドル毎に前記コールバック処理の情報を記憶し、
前記ライブラリ部は、
前記アプリケーション部から、前記イベント監視登録依頼を前記子ハンドルと共に受領したときに、前記子ハンドル毎に記憶されている前記コールバック処理の情報を集約して前記親ハンドルの識別情報および当該イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記集約したコールバック処理の情報を前記イベント発生通知として受信したときに、受信した前記コールバック処理の情報における集約を解除することで、当該イベント発生通知に該当する子ハンドルを探索し、前記探索された子ハンドルに付与されているイベント発生通知時の処理を実行するイベント通知制御手段をさらに備える、
ことを特徴とする請求項1または請求項2に記載のクライアント装置。 - 前記アプリケーション部は、前記コールバック処理の情報として、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値を前記ライブラリ部に登録し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記子ハンドルに対して、前記コールバック処理の情報であるイベント毎の前記マスク値の集合をイベントマスクとして付与して記憶し、
前記ライブラリ部のイベント通知制御手段は、
前記イベント監視登録依頼と共に受領した前記子ハンドルのイベントマスク値と、前記親ハンドルのイベントマスク値との論理和を計算することで前記コールバック処理の情報を集約し、この計算結果で前記親ハンドルのイベントマスク値を更新し、前記更新により生成された新イベントマスクの登録依頼を、前記イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記イベント発生通知として前記新イベントマスクを受信したときに、前記ハンドルリストに記載された前記子ハンドルのイベントマスク値と前記受信した新イベントマスクのマスク値との論理積を計算することで、受信した前記新イベントマスクにおける前記子ハンドルのイベントマスク値の集約を解除することを特徴とする請求項3に記載のクライアント装置。 - 前記アプリケーション部は、前記ライブラリ部に対して、前記セッションにおいて前記サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得することを要求するロック取得依頼を作成し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記ハンドルリストにて前記子ハンドルのロック取得状況の情報を前記子ハンドルに関連付けて記憶し、
前記ライブラリ部は、
前記アプリケーション部から、前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロック取得依頼を前記子ハンドルと共に受領したときに、前記受領した子ハンドルのロック取得状況の情報が前記ハンドルリストに記憶されている場合に当該ロック取得状況の情報を返却し、一方、記憶されていない場合に、当該子ハンドルの前記ロック取得依頼を前記親ハンドルの識別情報と共に前記サーバ装置に送信し、前記サーバ装置から、サーバ側にて当該子ハンドルのロック取得状況の情報が登録されたことを示す応答を受信したときに、受信した前記応答で示されるロック取得状況の情報を、当該子ハンドルのロック取得状況の情報として前記ハンドルリストに登録するロック制御管理手段をさらに備える、
ことを特徴とする請求項1乃至請求項4のいずれか一項に記載のクライアント装置。 - ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、親ハンドルに従属する子ハンドルを用いて操作するアプリケーション部を備えるクライアント装置とを備えるコンピュータシステムにおける前記サーバ装置であって、
前記クライアント装置とのセッションにより、前記アプリケーション部から、前記ファイルシステム上のファイルまたはディレクトリの操作に対応する前記親ハンドルの作成を要求するハンドル作成依頼を受信し、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却し、当該クライアント装置のアプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておくハンドル管理手段を備えることを特徴とするサーバ装置。 - 前記セッションにより、前記アプリケーション部から、前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル取得依頼を、当該アプリケーション部と前記ファイルに対応した前記親ハンドルと共に受信し、当該ファイルの内容を当該クライアント装置に返却し、前記ハンドルリストにて、返却した前記ファイルの内容が当該クライアント装置にキャッシュされていることを示すキャッシュ状態情報を、前記受信した親ハンドルの識別情報と関連付けて登録するキャッシュ管理手段をさらに備えることを特徴とする請求項6に記載のサーバ装置。
- 前記セッションにより、前記アプリケーション部から、当該サーバ装置で管理するファイルおよびディレクトリの少なくとも1つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼および前記親ハンドルの識別情報を、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報と共に受信したときに、前記ハンドルリストにて、受信した前記コールバック処理の情報を前記親ハンドルの識別情報と関連付けて登録し、
前記イベントが発生したことを検知したときに、当該発生したイベントを通知するために登録されている前記親ハンドルを前記ハンドルリストからすべて抽出し、抽出された前記親ハンドルに基づいて、該当するクライアント装置のアプリケーション部に対してセッションを通じて、当該親ハンドルに関連付けて登録されている前記コールバック処理の情報を送信するイベント管理手段をさらに備える、
ことを特徴とする請求項6または請求項7に記載のサーバ装置。 - 前記イベント管理手段は、
前記コールバック処理の情報として、イベント発生通知時の処理の有無を管理するイベント毎のマスク値の集合であるイベントマスクを前記親ハンドルの識別情報と共に受信したときに、前記ハンドルリストにて、前記受信したイベントマスクを前記親ハンドルの識別情報と関連付けて登録し、
前記イベントが発生したことを検知したときに、前記コールバック処理の情報として、前記親ハンドルの識別情報に関連付けて登録されているイベントマスクを送信することを特徴とする請求項8に記載のサーバ装置。 - 前記記憶手段は、前記親ハンドルに従属して前記クライアント装置で生成され前記セッションにおいて有効な子ハンドルの識別情報と、前記セッションにおいて当該サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得していることを表す情報との対応関係を示すロック取得リストをさらに記憶し、
前記セッションにより、前記アプリケーション部から、当該アプリケーション部に対応した前記親ハンドルと前記子ハンドルと共に、当該子ハンドルが前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロックを取得することを要求するロック取得依頼を受信したときに、受信した前記ロック取得依頼にて対象とするファイルまたはディレクトリが別のクライアント装置によってロック取得済みであることを表す情報が前記ロック取得リストに記憶されているか否かを判別し、
当該情報が前記ロック取得リストに記憶されている場合には、前記別のクライアント装置によるロックが解除されるまで、受信した前記子ハンドルをロック待ち行列の記憶手段に登録して管理し、一方、当該情報が前記ロック取得リストに記憶されていない場合には、受信した前記子ハンドルを前記ロック取得リストに登録し、前記判別の結果に応じて、受信した前記子ハンドルのロック取得状況の情報を前記クライアント装置のアプリケーション部に返却するロック管理手段をさらに備える、
ことを特徴とする請求項6乃至請求項9のいずれか一項に記載のサーバ装置。 - 請求項1に記載のクライアント装置と、請求項6に記載のサーバ装置とを備えることを特徴とするコンピュータシステム。
- ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備え、前記クライアント装置が、前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部とを有しているコンピュータシステムにおいて前記ファイルシステムにアクセスするファイルシステムアクセス方法であって、
前記クライアント装置の前記ライブラリ部は、
前記アプリケーション部による前記ファイルシステム上のファイルまたはディレクトリの操作に対応する子ハンドルを生成する際に、当該ファイルに対する1以上の前記子ハンドルを集約した親ハンドルがクライアント側ハンドルリストに登録されているか否かを判別する親ハンドル登録判別ステップと、
前記親ハンドルが登録されていない場合に、前記親ハンドルの作成を要求するハンドル作成依頼を前記サーバ装置に送信するハンドル作成依頼送信ステップとを実行し、
前記サーバ装置は、
前記ハンドル作成依頼に基づいて、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却すると共に、当該クライアント装置の前記アプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたサーバ側ハンドルリストを生成し、記憶手段に格納する親ハンドル生成ステップを実行し、
前記クライアント装置の前記ライブラリ部は、
前記サーバ装置から受信した親ハンドルの識別情報を前記クライアント側ハンドルリストに記憶する親ハンドル情報格納ステップと、
前記親ハンドル登録判別ステップにて前記親ハンドルが登録されている場合、または、前記親ハンドル情報格納ステップにて前記親ハンドルの識別情報を記憶した場合に、当該親ハンドルに従属する子ハンドルを生成し、生成した前記子ハンドルの識別情報と当該親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納する子ハンドル生成ステップとを実行する、
ことを特徴とするファイルシステムアクセス方法。 - 請求項1乃至請求項5のいずれか一項に記載のクライアント装置を構成する各手段としてコンピュータを機能させるためのクライアントプログラム。
- 請求項6乃至請求項10のいずれか一項に記載のサーバ装置を構成する各手段としてコンピュータを機能させるためのサーバプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009147852A JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009147852A JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2011003147A JP2011003147A (ja) | 2011-01-06 |
JP5395532B2 true JP5395532B2 (ja) | 2014-01-22 |
Family
ID=43561030
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009147852A Expired - Fee Related JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5395532B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20210015387A (ko) * | 2019-08-02 | 2021-02-10 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2507235B2 (ja) * | 1994-06-24 | 1996-06-12 | インターナショナル・ビジネス・マシーンズ・コーポレイション | クライアント・サ―バ・コンピュ―タ・システム、及びそのクライアント・コンピュ―タ、サ―バ・コンピュ―タ、並びにオブジェクト更新方法 |
JP2000137689A (ja) * | 1998-11-04 | 2000-05-16 | Hitachi Ltd | 共用データキャッシュ処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
JP2003233520A (ja) * | 2002-02-07 | 2003-08-22 | Fujitsu Ltd | ネットワーク上のファイル資源のためのファイル制御装置 |
US7624126B2 (en) * | 2003-06-25 | 2009-11-24 | Microsoft Corporation | Registering for and retrieving database table change information that can be used to invalidate cache entries |
JP4175379B2 (ja) * | 2006-04-25 | 2008-11-05 | 日本電気株式会社 | ファイル共有方法およびファイル共有システム |
-
2009
- 2009-06-22 JP JP2009147852A patent/JP5395532B2/ja not_active Expired - Fee Related
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20210015387A (ko) * | 2019-08-02 | 2021-02-10 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
KR102593008B1 (ko) * | 2019-08-02 | 2023-10-23 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
Also Published As
Publication number | Publication date |
---|---|
JP2011003147A (ja) | 2011-01-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11641397B2 (en) | File service using a shared file access-rest interface | |
US10534681B2 (en) | Clustered filesystems for mix of trusted and untrusted nodes | |
US9558194B1 (en) | Scalable object store | |
JP5695324B2 (ja) | スプリットブレイン状況におけるメジャーグループを決定するための方法、システム、及びコンピュータ読み取り可能な記録媒体 | |
US9275058B2 (en) | Relocation of metadata server with outstanding DMAPI requests | |
US9367346B2 (en) | Accelerating distributed transactions on key-value stores through dynamic lock localization | |
JP3197789B2 (ja) | 分散ファイル・システム内にあるディレクトリの操作を要求する方法およびシステム | |
US9171019B1 (en) | Distributed lock service with external lock information database | |
WO2018059032A1 (zh) | 一种虚拟节点的数据迁移方法和虚拟节点 | |
US20030028514A1 (en) | Extended attribute caching in clustered filesystem | |
US7366742B1 (en) | System and method for distributed discovery and management of frozen images in a storage environment | |
JP5541149B2 (ja) | スナップショット採取プログラム、サーバおよびスナップショット採取方法 | |
US20100162035A1 (en) | Multipurpose Storage System Based Upon a Distributed Hashing Mechanism with Transactional Support and Failover Capability | |
CN107710164B (zh) | 作为一种服务的灾难恢复 | |
JP7389793B2 (ja) | 分散型異種ストレージシステムにおけるデータ一貫性のリアルタイムチェックのための方法、デバイス、およびシステム | |
JP6475304B2 (ja) | トランザクション処理方法および装置 | |
US20150213011A1 (en) | Method and system for handling lock state information at storage system nodes | |
US8788474B2 (en) | Inode event notification for cluster file systems | |
US10558373B1 (en) | Scalable index store | |
JP4356018B2 (ja) | ストレージ・エリア・ネットワーク上の非同期メッセージング | |
JP5395532B2 (ja) | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム | |
JP6697101B2 (ja) | 情報処理システム | |
JP6044363B2 (ja) | コンピュータ、nasアクセス方法およびnasアクセスプログラム | |
Zhou et al. | A Tamper-Resistant and Decentralized Service for Cloud Storage Based on Layered Blockchain |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20110819 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110920 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20130201 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20131002 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20131015 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131018 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5395532 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
LAPS | Cancellation because of no payment of annual fees |