JPWO2009145274A1 - ネットワークブートシステム - Google Patents

Abstract

ネットワークブートシステムにおいて、クライアント端末に仮想ディスクの改訂を検知させ、リードキャッシュドライバの動作を決定する。クライアント端末は物理的な記憶装置を備える。クライアント端末上で動作するオペレーティングシステムは、クライアント端末のローカルバスに対するアクセスをネットワークに対するアクセスに変換するためのフィルタドライバ４６と、記憶装置を駆動するためのリードキャッシュドライバ５０を備え、ブートサーバから読み出されたデータを読み出しキャッシュするリードキャッシュ機構を備える。仮想ディスク２２ａのデータとリードキャッシュデータのリビジョンとを比較し、その結果に基づいてリードキャッシュドライバの動作を決定する。

Description

本発明は、ネットワークを介してオペレーティングシステムを起動するネットワークブートシステムに関するものである。

近年、ネットワークを介してオペレーティングシステム（以下、「ＯＳ」という。）を起動するシステム（以下、「ネットワークブートシステム」という。）が注目されている。このシステムは、少なくとも１台のネットワークブートサーバ（Ｉ／Ｏサーバ）と複数台のクライアント端末とがネットワークを介して接続されたものである。システム構成にはいくつかの種類があるが、最も一般的な構成は、クライアント端末で動作するＯＳやアプリケーションソフトなどの全てのプログラム及びデータをサーバ側の記憶装置（ハードディスク等）にイメージデータ（仮想ディスク）として保存し、クライアント端末を起動するとネットワークを介してクライアント端末上にＯＳが読み込まれるというものである。

特許文献１には、ネットワークブートシステムにおいて、エンドユーザが使用するＰＣ（クライアント端末）に仮想マシンを利用したシステムが開示されている。

ネットワークブートシステムは、クライアント端末上で動作するオペレーティングシステムを提供するネットワークブートサーバと、クライアント端末とがネットワークを介して接続され、クライアント端末は、少なくともオペレーティングシステム起動中に必要なデータを一時的に保存することができる物理メモリと、前記ネットワークを介してサーバにアクセスするためのネットワークインターフェースとを備えていると共に、オペレーティングシステムは、ネットワークインターフェースを駆動するためのネットワークドライバと、クライアント端末のローカルバスに対するアクセスをネットワークに対するアクセスに変換するためのフィルタドライバ等を備えている。

ネットワークブートシステムはネットワークを介してＯＳを含むディスクイメージを複数のクライアント端末で共有する仕組みを持つことによって、クライアント端末がディスクレスすなわちハードディスクを持つ必要が無くなり、クライアント端末のＯＳを含む全てのデータをサーバ側で集中管理することができる利点がある。そのため、多くのクライアント端末が稼働するシステムに適している。

また、ＯＳやアプリケーションソフトを各クライアント端末側のＣＰＵと物理メモリで実行するため、クライアント端末の性能を最大限に発揮してサーバの負荷を最小限に抑えられる利点もある。
特開２００７−３２３３５４

本件発明者たちは、クライアント端末側の物理的な記憶装置の一部に、読み出し専用のキャッシュ（以下、「リードキャッシュ機構」という。）を備えた構成を含む新たなネットワークブートシステムを提案している。このシステムでは、クライアント端末側がネットワークを介してネットワークブートサーバから読み出したクライアント端末のＯＳ起動用の仮想ディスクのデータをクライアント端末側のキャッシュ領域にコピーして、未だ書き込みが行われていないデータのみを、リードキャッシュデータとして利用する、「読み出しに特化したキャッシュシステム」を備えることを特徴とするものである。このシステムによれば、１回目の起動時に読み出した仮想ディスクのデータをローカルディスクにキャッシュすることでクライアント端末の２回目以降の起動処理の際にサーバへのネットワークアクセスが殆ど発生しなくなるため、一台のサーバに接続できるクライアント端末を従来よりも飛躍的に増大することができる等の利点がある。

ところが、上記のネットワークブートシステムは、クライアント端末側が読み出す仮想ディスクのデータは常に同じであることが基本的な前提であり、クライアント端末側において、仮想ディスクのデータが改訂されたことを検知する仕組みも明らかではなかった。仮想ディスクのデータが改訂された場合、リードキャッシュデータをそのまま利用するとデータの不整合が起こりクライアント端末の起動に障害を来すおそれがある。しかしながら、仮想ディスク全体のデータをネットワークを介してリードキャッシュデータと比較することは極めて非効率的である。

本発明は、上記に鑑みてなされたものであり、リードキャッシュデータを保持するクライアント端末を含むネットワークブートシステムにおいて、仮想ディスクのデータが改訂された場合に、クライアント端末側がその改訂情報を効率よく検知する新たな仕組みを提供すること等を主たる技術的課題とする。

本発明に係るネットワークブートシステムは、クライアント端末上で動作するオペレーティングシステムを含むディスクイメージを仮想ディスクとして提供するネットワークブートサーバと、物理的な記憶装置を備えたクライアント端末とがネットワークを介して接続され、
前記クライアント端末は、前記オペレーティングシステム起動中に必要なデータを一時的に保存することができる物理メモリと、前記ネットワークを介して前記サーバにアクセスするためのネットワークインターフェースとを備えていると共に、
前記オペレーティングシステムは、
前記クライアント端末のローカルバスに対するアクセスを前記ネットワークに対するアクセスに変換するためのフィルタドライバと、前記記憶装置を駆動するためのリードキャッシュドライバを備えており、
前記リードキャッシュドライバが、前記フィルタドライバによって前記ネットワークブートサーバから読み出されたデータを前記記憶装置に読み出しキャッシュするリードキャッシュ機構を備えたネットワークブートシステムであって、
前記リードキャッシュ機構は、前記サーバから受け取ったデータを保持するための読み出しキャッシュ領域と共に前記物理メモリに保持されている前記リードキャッシュドライバが前記サーバから読み出されたデータが書き込み済であるか否かを判別するための管理フラグの少なくとも一部を書き戻すためのキャッシュ管理領域を備え、
前記仮想ディスクのデータのリビジョンを記憶する第１の記憶手段と、前記読み出しキャッシュされたリードキャッシュデータのリビジョンを記憶する第２の記憶手段と、前記第１及び第２のリビジョンを比較する手段と、前記比較結果に基づいて前記リードキャッシュドライバの動作を決定する決定手段とを具備することを特徴とする。

このシステムでは、仮想ディスクのデータのリビジョンとリードキャッシュデータのリビジョンとを比較することで、仮想ディスクのデータとリードキャッシュデータとを全セクタに亘って照合することなく、内容の同一性を判断することができ、これによりリードキャッシュデータに保存されているキャッシュデータを利用してよいか否かを決定することができる。もし、リビジョンが一致しているときはリードキャッシュデータをそのまま利用することができ、リビジョンが一致していないときはリードキャッシュデータをそのままでは利用できないことが分かる。もしそのまま利用すると、仮想ディスクのデータが改訂されているにもかかわらず、リードキャッシュされている改訂前のデータを読み込むことになり、改訂が反映されないからである。このため、クライアント端末の動作が不安定になったり、最悪の場合起動できなくなったりすることが懸念される。

なお、リードキャッシュデータをそのままでは利用できない場合、最も安全な方法は、リードキャッシュドライバが全てのリードキャッシュデータを破棄することである。この場合、データの不整合の問題は生じなくなる利点があるが、反面、改訂されていないセクタ内のデータまで破棄してしまうため、再度ネットワークを介して読み込みを行わなければならず、ネットワークの負荷が増大する原因となる欠点もある。

上記ネットワークブートシステムにおいて、前記第１のリビジョンは、前記仮想ディスクの一部として又は前記仮想ディスクに関連づけられて保持されることが好ましい。起動時にアクセスでき、しかも仮想ディスクへの書き込み作業時に記録を残せる場所である必要があるからである。なお、「関連づけられて」とは、クライアント端末が起動時に仮想ディスクを介してアクセスできることを意味する。

上記ネットワークブートシステムにおいて、前記第２のリビジョンは、前記記憶装置の一部に保持されることが好ましい。「前記記憶装置」とは、クライアント端末が備える物理的な記憶装置のことであり、具体的にはローカルディスク等を指す。なお、第２のリビジョンは、リードキャッシュデータのリビジョンであるから、ローカルディスク内のいずれかの領域、例えばキャッシュ管理領域（Ｐ３）に保存することができる。

上記ネットワークブートシステムは、前記クライアント端末からの書き込み情報をキャッシュするための書き込みライトキャッシュ領域をさらに具備すると共に、
前記仮想ディスクの一部に、少なくとも１ビットのフラグ保存領域を具備してもよい。クライアント端末は起動時にこの２つのフラグ管理領域の少なくともいずれか一方に必ずように動作させることで、仮想ディスクのデータに変更が加えられたか否かを調べることができるためである。

上記ネットワークブートシステムにおいて、複数のクライアント端末でサーバ上の仮想ディスクを共有して使用するシェアーモードモードで前記クライアント端末を起動したときは、前記ライトキャッシュ領域に設けたフラグ管理領域に１を書き込み、サーバ上の仮想ディスクにクライアントが直接書き込みすることができるプライベートモードで前記クライアント端末を起動したときは、前記仮想ディスクの保存領域に設けたフラグ管理領域に１を書き込み、
前記クライアント端末は、起動時に前記仮想ディスクの保存領域に設けたフラグ管理領域の記憶された値に基づいて、前記読み出しキャッシュ機構を起動又は停止させるように構成してもよい。このようにすると、フラグ管理領域に書き込まれた情報をＯＳが再起動後も保持するため、再起動時に仮想ディスクの一部に設けたフラグ管理領域に記憶されている管理フラグの値を調べるだけで、仮想ディスクに書き込みが行われ、その後更新作業が終了している否かが、分かるからである。

上記ネットワークブートシステムにおいて、前記第１のリビジョンのうち、異なる２つのリビジョン間で前記仮想ディスク内のどの領域のデータが変更されたかを示す変更領域マップを、前記変更領域マップを改訂前のリビジョンにおけるリードキャッシュデータの状態を表すキャッシュ管理テーブルに適用することによって、改訂後のキャッシュ管理テーブルを生成することが好ましい。変更領域マップとは、リビジョン間で仮想ディスクのデータのうちどの領域のデータが改訂されたかを記録して関連づける改訂履歴の管理情報であり、１ビットの情報（０又は１）で表される。セクタ単位で変更の有無を記録したもので、「変更有り」であるセクタに対応するリードキャッシュデータのキャッシュ管理テーブルに０を書き込んだときは、そのセクタにリードキャッシュされているデータを破棄して再度仮想ディスクから読み出しを行う。一方、「変更無し」であるセクタに対応するリードキャッシュデータのキャッシュ管理テーブルは、リードキャッシュデータを破棄せず利用することができるため、破棄する必要がない。このように、変更領域マップをキャッシュ管理テーブルに適用すると、仮想ディスクのデータが改訂された場合でも、破棄するデータを最小限に抑えることが出来る。

上記ネットワークブートシステムにおいて、前記変更領域マップは前記仮想ディスクの一部に記憶されていることが好ましい。変更領域マップの保存場所は特に制限がないが、リードキャッシュデータを有する全てのクライアント端末が仮想ディスクのデータの変更情報を知る必要があるため、仮想ディスクの一部に設けることが合理的だからである。

上記ネットワークブートシステムにおいて、前記第１のリビジョンのうち、連続するリビジョン間の変更領域マップの論理和を求めることにより、集約された連続する変更領域マップを生成する変更領域マップ集約手段を具備することが好ましい。変更領域マップは０と１からなるビット列であって、変更されたセクタに対応するビットに１を割り当てれば、論理和を求めることにより容易に集約することができるからである。

本発明では、仮想ディスクのデータが変更された場合でも仮想ディスクのリビジョンとリードキャッシュデータのリビジョンとを比較することにより、仮想ディスク全体を検査しなくても内容の同一性を判断することができる。

さらに、クライアント端末のリードキャッシュデータの状態を管理する「キャッシュ管理テーブル」に仮想ディスクの改訂情報を示す「変更領域マップ」を適用する構成を備えている場合には、リードキャッシュデータを破棄するセクタを最小限にすることができる。そのため、仮想ディスクのデータが変更された場合でも、ネットワークの負荷を抑えてデータ変更後の仮想ディスクのデータをクライアント端末上の読み出しキャッシュに反映させ、クライアント端末上で利用することができる。

本明細書における用語の解釈は以下の通りとする。ただし、ここで定義しないものについては適宜文中において指摘する。なお、ここでの定義は実施形態（実施例）に限定されない。

・「サーバ」とは、クライアント端末上で動作するオペレーティングシステムを提供する少なくとも１台のコンピュータを指すものとする。サーバはクライアント端末が使用するＯＳ、アプリケーションソフトその他のデータを含む仮想ディスクをイメージデータとして保存しているが、イメージデータはネットワーク上にあるファイルサーバ等、他のサーバの物理ディスク内に実体がある場合を含む。
・「仮想ディスク」とは、クライアント端末上のＯＳからネットワークを介して見えるディスクイメージ（これを「ｖＤｉｓｋ」と表記する場合がある。）を指し、その実体はネットワークを介して接続される物理ディスクに保存されているデータの一部を指すものである。
・「ローカル」とは、ＬＡＮなどの外部ネットワークを介さずクライアント端末の内部バスに接続されたデバイスを意味する。
・「物理ディスク」とは、ローカルバスに接続された実体を伴うハードディスクその他の記憶手段を指し、「ローカルディスク」という場合もある。但し、ＯＳが認識できるかぎりハードディスクの種類（例えば、ＳＣＳＩディスクやＩＤＥディスクやＳＡＴＡなど）は問わない。また、ディスク状であるかを問題とせず、例えば半導体メモリその他ハードディスクに代替する実現可能な記憶手段を全て含むものとする。
・「ユーザデータなど」というときは、ユーザがクライアント端末を操作することによってクライアント端末のＯＳ又はそのＯＳ上で動作するアプリケーションソフトが保存する全てのデータをいうものとする。
・特に明示せず単に「ＯＳ」という場合は、クライアント端末で動作するＯＳを意味するものとする。また、「ＯＳ側からの書き込み（又は読み出し）要求信号」という場合も、ＯＳ側で動作するアプリケーションソフトがフィルタドライバに向けて発する要求信号を含むものとする。

（ネットワークブートシステムの基本原理）
ここで、一般的なネットワークブートシステムの基本原理について簡単に説明する。図１２（ａ）及び図１２（ｂ）は、コンピュータシステムにおけるディスクアクセスの関係を説明するための図である。

図１２（ａ）は、一般的なコンピュータシステムがローカルディスクにデータの読み出し及び書き込みを行う仕組みを説明した図である。クライアント端末上のＯＳ又はアプリケーションソフト１０１がローカルディスク１０３に対して読み出し及び書き込み要求信号を送るとディスクドライバ１０２がこの要求信号に応じてローカルディスク１０３に対するデータの読み出し及び書き込みを制御する。

図１２（ｂ）は、ネットワークブートシステムが仮想ディスク（ｖＤｉｓｋ）にデータの読み出し及び書き込みを行う仕組みを説明した図である。ＯＳ又はアプリケーションソフト１０４が仮想ディスク１０５に対して読み出し及び書き込み要求信号を送るとディスクドライバの代わりにフィルタドライバ１０６が最初にこの要求信号を受け取り、これをネットワークドライバ１０７に転送し、図示しないネットワークインターフェースを介してネットワーク越しのサーバ等に実体があるディスクイメージ（仮想ディスク１０５）に対するデータの読み出し及び書き込みを制御する。

このように、各クライアント端末のフィルタドライバ１０６がローカルディスクへのアクセスをネットワークアクセスに変換することにより、クライアント端末のＣＰＵは、ローカルディスクにアクセスすることに代えて、ネットワークを介して接続されるサーバ上のディスクイメージにアクセスする。

ここで、「フィルタドライバ」とは、クライアント端末側のＯＳで動作するデバイスドライバの一種であり、その後段にネットワークドライバが設けられる。ネットワークドライバはネットワークインターフェース（イーサーネットカード等）を介してサーバ側の仮想ディスク（ｖＤｉｓｋ）と通信し、受け取ったディスクアクセスのための要求信号に基づいてデータの授受を行う。すなわち、仮想ディスクが読み出し要求信号を受けた場合はクライアント端末側にデータを返し、書き込み要求信号を受けた場合は仮想ディスクに対してデータの書き込みを行う。

（第１の実施形態）−リビジョン管理−
以下、本発明にネットワークブートシステムの第１の実施態様について図面を参照して詳述する。なお、［１］〜［４］では、本発明が前提とするリードキャッシュ機構を備えたネットワークブートシステムの一実施態様を例示し、［５］では、このようなシステムを前提としたリビジョン管理（改訂情報の管理方法）について説明する。

［１］システムの全体構成
図１（ａ）及び図１（ｂ）は、第１の実施形態のネットワークブートシステムの基本構成を説明するための概念図である。図１（ａ）に示すように、このシステムは少なくとも１台のサーバ（ネットワークブートサーバ）１０と、複数台のクライアント端末２０（２０ａ，２０ｂ，・・・）とがネットワークを介して接続されている。また、図１（ｂ）に示すように、サーバ１０は物理ディスク（例えばハードディスク）１１を備えている。そのほか、サーバ１０は図示しないＣＰＵやメモリなどサーバとしての基本的な構成を備えている。さらに、あるクライアント端末２０ａ、２０ｂは、ローカルディスク２１ａを備えている。但し、システム全体の中の一部に「ローカルディスクを持たないクライアント端末」が含まれていても構わない。

サーバ１０の物理ディスク１１には、各クライアント端末２０（２０ａ，２０ｂ，・・・）が最初の起動時に読み込む共通のＯＳのディスクイメージ（ｖＤｉｓｋ）２２ａが保存されている。すなわち、このシステムでは、サーバ１０の物理ディスク１１に保存されているＯＳのディスクイメージを複数のクライアント端末が共有することを前提としている。

なお、物理ディスク１１内の異なる領域に、第１のＯＳ、第２のＯＳ、第３のＯＳ、・・・というように、種類の異なる複数のＯＳイメージを保存しておき、クライアント端末側において、起動時にどのＯＳを起動するかを選択するような構成としてもよい。但し、説明を簡単にするため、複数のＯＳを選択的に起動させる態様については第４の実施形態で詳述することとする。

図２は、このシステムにおけるディスクアクセスの関係を説明した図である。上述の通りこのシステムのクライアント端末はローカルディスク２１ａと仮想ディスク２２ａを持つ。このため、基本的な動作としては、ローカルディスク２１ａへのアクセスはディスクドライバによって図示しない内部バス（例えば、ＳＣＳＩバス或いはＩＤＥバス等）を経由して行われるのに対し、仮想ディスク２２ａへのアクセスはフィルタドライバ４６及びネットワークドライバ４８を介してネットワークを介して行われる。すなわち、サーバ上のディスクイメージはネットワークを介してクライアント端末上のＯＳにマウントされ、クライアント端末上からは仮想ディスク２２ａがネットワークを介して接続されているように見える（図１（ｂ）参照）。

このシステムは、フィルタドライバ４６の前段に、読み出し専用の「リードキャッシュドライバ５０」を備えていることが前提となる。リードキャッシュドライバ５０はローカルディスク２１ａにおける特定のパーティションに割り当てられた読み出しキャッシュ領域（後述の図３（ａ）におけるパーティションＰ２）に対するデータのアクセス（書き込み及び読み出し）を行う。リードキャッシュドライバ５０はフィルタドライバ４６によってサーバから読み出されたデータをローカルディスク内にコピーして読み出しキャッシュさせる働きをする。

但し、サーバ上からネットワークを介してすでに読み出されたデータであっても、その後一度でも書き込みが行われたことのあるセクタのデータについては、データの内容が書き換えられているため、利用しない。これを実現するため、クライアント端末はキャッシュ管理テーブルと呼ばれる２ビットのフラグ）をセクタ毎に保持するが、この仕組みについては［４］システムの動作で詳述する。

［２］クライアント端末側ディスク構成
図３（ａ）及び図３（ｂ）は、クライアント端末側のディスク構成を例示した図である。この図に示すように、クライアント端末は、ローカルディスク２１ａと仮想ディスク（ｖＤｉｓｋ）２２ａとから構成される。

上述の通り、仮想ディスクは、クライアント端末からみるとネットワーク越しに見える論理ドライブ（ＯＳによってはこれを「ネットワークドライブ」という場合もある）と扱われ、ＯＳのシステムやユーザデータなどをまるでユーザのローカルディスクに保存するかのごとく、ネットワークを介してサーバ側のディスクイメージに保存することができる。一方、クライアント端末がもつ物理的なハードディスク（これを「ローカルディスク」とよぶ。）は内部バスに直接接続されている。

（１）物理ディスクの構成
図３（ａ）は物理ディスクの構成を説明するための図である。物理ディスクは、クライアント端末側に直接接続されたローカルディスクであって、この実施形態においては、少なくとも３つの領域（パーティション）に分けられている。

図３（ｃ）は、第１のパーティションＰ１に割り当てる機能の一例を説明するための図であり、以下の（ｉ）〜（ｉｉｉ）の各説明に対応するものである。なお、第１のパーティションＰ１はクライアント端末側のＯＳにとって論理ドライブ或いはファイルやディレクトリとして認識されるのに対して、第２及び第３のパーティション（Ｐ２及びＰ３）は論理ドライブ或いはファイルやディレクトリといったアプリケーションのレベルで認識されるものではなく、ローカルディスク内のセクタ或いはクラスタといった物理的なレベルで認識されるものにとどまる。

（ｉ）第１のパーティションＰ１
物理ディスクの第１のパーティションＰ１には、必要に応じて、クライアント端末側ＯＳの「スワップ領域」や、「書き込みキャッシュ」や「クライアント端末側で動作するアプリケーションソフトのワークエリア」などを割り当てることができる。なお、第１のパーティションＰ１は、本発明（第１の実施形態）においては必須のものではないが、これを設けるといずれもクライアント端末の処理能力が向上する利点がある。

ａ．スワップ領域
「スワップ」とはクライアント端末の物理メモリの不足分を補うためにローカルハードディスクの一部をメモリのように使用するＯＳの機能の一つである。スワップ動作とは、ハードディスク内に「スワップ領域」を用意して、メモリ容量が不足してきたら使われていないメモリ領域の内容を一時的にハードディスクに退避させ、必要に応じてメモリに書き戻す動作のことを言う。そうした機能を用いて確保された実際のメモリ容量以上のメモリ領域を「仮想メモリ」という。クライアント端末がディスクレスの場合、クライアント端末側にスワップ領域を設けることができないため、メモリからあふれたデータは全てサーバ側のスワップ領域に送られることになり、サーバのリソースを消費すると共にネットワークの負荷がかかる原因ともなっていた。しかし、本発明に係るネットワークブートシステムのクライアント端末はローカルディスクを備えているため、物理領域の一部にスワップ領域を確保できることとなる。このようにネットワークを介してサーバ側でスワップ動作することを回避できる利点は大きい。

ｂ．書き込みキャッシュ
クライアント端末側のＯＳ等４０から書き込み要求信号がフィルタドライバ４６に送られた場合、その書き込みデータをローカルディスクの物理領域にキャッシュする、いわゆる「書き込みキャッシュ」として用いることができる。なお、「書き込みキャッシュ」は「読み出しキャッシュ」としても用いることができる（但し、「読み出しキャッシュ」として読み出されるキャッシュデータには、ユーザデータなどの書込みが行われた後のデータが含まれる。）。これにより、クライアント端末の更新情報（ユーザデータなど）をクライアント端末側に保存できるため、ネットワーク負荷を軽減する利点がある。

ｃ．アプリケーションソフトのワークエリア
クライアント端末側で動作するアプリケーションソフトのワークエリアを割り当てるこ
とにより、ネットワーク負荷を軽減する利点がある。

（ｉｉ）第２のパーティションＰ２
物理ディスクの第２のパーティションＰ２には、「読み出しキャッシュ」動作をさせるための専用領域（「読み出しキャッシュ領域」）が割り当てられる。この領域には書き込みが行われた後のデータを一切保存しない。この意味において「（ｉ）ｂ．書き込みキャッシュ」において説明したものとは技術的意義が全く異なるものである。

第２のパーティションＰ２に保存されるリードキャッシュデータは、ネットワークを介して読み出されたデータのコピー全てを利用せず、一度も書き込みが行われていないセクタ内のデータのみを利用する。また、仮想ディスクに保存されているデータが変更された場合には、データの不整合が生じうる危険性があるため、リードキャッシュデータはリードキャッシュしたディスクイメージのリビジョン（これを「リードキャッシュデータのリビジョン」という。）を第２のパーティション内に保持する。

この動作を簡単に説明すると、あるリードキャッシュ領域内に保持されている、ある特定のセクタ内におけるリードキャッシュデータの有無（「有」又は「無」）と、当該セクタに書き込み済であるか否か（「書き込み済」又は「未書き込み」）という４通りの状態（２ビットのフラグ）をセクタ毎に保持することで、「リードキャッシュデータ有り」かつ「未書き込み」の場合にのみリードキャッシュデータを利用し、その他の場合には、リードキャッシュデータを利用しないように動作させる。

このような意味において、なお、本明細書における上記「読み出しキャッシュ機構」は、「書き込みキャッシュ」を含まない概念である。但し、別途書き込み状態をも保持する「読み出し及び書き込みキャッシュ」を、上記「読み出しキャッシュ」とは異なる領域に有していることは差し支えない。上述のように、「読み出し及び書き込みキャッシュ」をクライアント端末側のローカルディスク内に設けるとネットワーク負荷が軽減する。また、各クライアント端末ごとの書き込み情報をサーバ上に保存してもよい。

（ｉｉｉ）第３のパーティションＰ３
クライアント端末側の物理ディスクは、読み出しキャッシュ領域（Ｐ２）を有すると共に、「キャッシュ管理領域（Ｐ３）」を有する。リードキャッシュドライバは、キャッシュ管理領域を物理メモリ内の非ページ領域（スワップされない領域）に確保された「キャッシュ管理テーブル」へと読み込み、定期的に、「キャッシュ管理テーブル」をキャッシュ管理領域へと書き戻す。キャッシュ管理領域は、「仮想ディスクのどのセクタにあるデータがキャッシュされているか」という情報と、「そのセクタには、書き込みが行われたか」という情報とをセクタ単位で保存することによって、読み出しキャッシュにデータが存在していても、そのセクタに書き込みが行われていれば読み出しキャッシュの対象から除外して、再度読み出しキャッシュを利用せずにデータの読み出しを行う。このような仕組みによって、書き込みが行われていないデータのみを読み出しキャッシュの対象としながらＯＳの再起動後もクライアント端末側のローカルディスク内にキャッシュデータを保存する。

（２）仮想ディスクの構成
図３（ｂ）は、仮想ディスクの構成を示した図である。仮想ディスクはクライアント端末上のＯＳから認識されるものであるが、その実体はネットワーク上のサーバのハードディスクの一部であって、この実施形態においては、全体が少なくとも２つの領域（パーティション）に分けられている。第１のパーティション（これを「Ｖ１」という。）は、クライアント端末側のＯＳによって認識される論理ドライブ（例えば、「Ｃドライブ」）となるが、第２のパーティション（これを「Ｖ２」という。）は、クライアント端末側のＯＳによって認識されない領域となる。第２のパーティションＶ２には、仮想ディスクの改訂情報（後述の「［４］リビジョンの管理」で説明するリビジョンなど）が記憶され、ディスクイメージの改訂ごとにサーバ側のプログラムによって改訂情報などが書き込まれる。

なお、各クライアント端末はイメージデータ単位で仮想ディスクとしてマウントするため、仮想ディスクの実体であるネットワーク上のいずれかの物理ディスク内に複数のＯＳイメージを保持し、クライアント端末側において起動時にＯＳを選択したり、一つのクライアント端末で異なる動作環境を使い分けて使用させたりすることもできる。

なお、改訂情報は極めてデータ量が小さいため、第２のパーティションＶ２の容量は、第１のパーティションＶ１の容量と比べて極めて小さくて良い。例えば、第１のパーティションが１５〜３０ＧＢであるとき、第２のパーティションは１０ＭＢ程度確保すれば十分である。

以上をまとめると、この実施態様においてクライアント端末のユーザがＯＳ上でその存在を確認できるのは、仮想ディスクの第１のパーティションＶ１に対応する論理ドライブ（例えば、Ｃドライブ）と、物理ディスクの第１のパーティションＰ１に対応する一部の論理ドライブとなる。

［４］システムの動作
（１）「リードキャッシュドライバ」の基本動作
はじめに、「リードキャッシュドライバ」の基本動作について説明する。図２において、「クライアントＯＳ（アプリケーション）」４０を起点として、ローカルディスク２１ａ及び仮想ディスク２２ａに向かう実線矢印は、読み出し又は書き込み要求信号（リクエスト信号）を意味している。この信号を受けた後、デバイスドライバはそれぞれのディスクと通信してデータの授受を行う。要求信号に隣接した一点鎖線の両矢印はデータ授受を表している。例えば、読み出し要求信号であればその後ディスク側からデータが読み出されてＯＳ側に送出され、逆に書き込み要求信号であればその後ＯＳ側からディスク側にデータが送出されディスクに書き込まれる。

リードキャッシュドライバとは、ローカルディスクの読み出しキャッシュ領域（Ｐ２）に対して「読み出しキャッシュ」を行うためのプログラムであって、その動作は以下の通りである。

（ｉ）読み出し要求信号の処理
クライアント端末側のＯＳ（又はアプリケーションソフト）４０が「読み出し要求信号」を送出した場合、リードキャッシュドライバ５０はフィルタドライバ４６よりも先にこの「読み出し要求信号」を受け取ることになる。この場合は、「キャッシュ管理テーブル」を用いて物理ディスクの第２のパーティションＰ２に割り当てられている「読み出しキャッシュ領域」に記憶されているデータが存在しているか否か及び存在している場合はそのデータが書き込み済であるかどうかを判断し、もし読み込み済みで、かつ、書き込み済みでない場合には、直ちにその読み出しキャッシュデータをＯＳに返す。しかし、読み出しキャッシュデータが書き込み済である場合又は読み出しキャッシュデータが存在しない場合には、リードキャッシュドライバ５０は受け取った「読み出し要求信号」をそのまま後段のフィルタドライバ４６に送る。なお、フィルタドライバ４６が「読み出し要求信号」を受け取った場合は通常通りネットワークドライバ４８を介してサーバ側からデータの読み出しを行う。

（ｉｉ）読み出しキャッシュデータの更新
上記（ｉ）の場合、最終的にはサーバ側から読み出したデータがフィルタドライバ４６及びリードキャッシュドライバ５０をこの順序で通過してＯＳ側４０に送出されることになる。その際、リードキャッシュドライバ５０は物理ディスクの第２のパーティションＰ２に割り当てられている「読み出しキャッシュ領域」にフィルタドライバ４６が読み取ったデータをコピーすると共に、物理メモリ上のキャッシュ管理テーブルのフラグを変更して読み出しキャッシュデータが読み出し済の状態であることを記憶する。

（ｉｉｉ）書き込み要求信号の処理
クライアント端末のＯＳ（又はアプリケーションソフト）４０が「書き込み要求信号」を送出した場合、リードキャッシュドライバ５０はフィルタドライバ４６よりも先にこの「書き込み要求信号」を受け取る。しかし、「書き込み要求信号」をリードキャッシュドライバ５０が受け取った場合には、リードキャッシュドライバは特に何もせずにこの「書き込み要求信号」をそのまま後段のフィルタドライバ４６に送る。なお、フィルタドライバ４６が「書き込み要求信号」を受け取った場合は通常通りネットワークドライバ４８を介してサーバ側の所定の書き込み領域にデータの書き込みを行う。

（２）「キャッシュ管理テーブル」の仕組み
図１３（ａ）は、「キャッシュ管理テーブル」を示している。キャッシュ管理テーブルは、ローカルディスク（物理ディスク）の読み取り単位ごとに２ビットの管理フラグを割り当て、以下に説明する２つの値（状態）を保持する。また、この管理フラグは物理メモリ上の非ページ領域（スワップ領域に退避されない領域）に確保する。

（ｉ）管理フラグ
「キャッシュ管理テーブル」は２つの管理フラグを用いて読み出しキャッシュデータの状態を記憶する。これらのフラグの初期状態はいずれも０とする。
ａ．読み出し管理フラグ（０又は１）
ｂ．書き込み管理フラグ（０又は１）

（ｉｉ）読み出しキャッシュデータが無い状態において、ＯＳからの読み出し信号に対する応答としてフィルタドライバが受け取ったデータをコピーした場合、読み出し済であることを記憶するため、読み出し管理フラグのデータを０から１に変更する。すなわち、読み出し管理フラグが１であれば、読み出しキャッシュデータが存在することを表す。しかし、これだけでは、読み出しキャッシュデータがその後書き込みが行われて内容が更新されたかどうかを判別することができない。

（ｉｉｉ）上述の通りフィルタドライバがＯＳから「書き込み要求信号」を受け取った場合には、リードキャッシュドライバは特に何もせずフィルタドライバにデータを送り、ネットワークインターフェースを介してサーバ側の仮想ディスクに書き込みを行う。この時、書き込み管理フラグの状態を０から１に変更する。すなわち、読み出し管理フラグが１であっても、書き込み管理フラグが１であるときは、その後に書き込み処理が行われているため読み出しキャッシュデータの内容が初期の状態から変更されているので、そのセクタに対する読み出し要求信号に対しては、以後読み出しキャッシュデータを一切利用してはならないことを意味する。書き込み管理フラグが１となった後は、クライアント端末側のＯＳをシャットダウンするときまでその状態が保持される。換言すれば、「書き込み要求信号」を一度でも受け取ったかどうかを調べることにより、「あるセクタ内のデータが書き込み済であるかどうか」を判別することができる。

図１３（ｂ）は、キャッシュ管理テーブルの状態とその動作をまとめた一覧表を示す図である。状態Ｉは、読み出しキャッシュデータが存在しない場合であるから、データの読み出しについてはフィルタドライバ４６に委任することになるが、フィルタドライバ４６が受け取ったデータをＯＳ側４０に渡す際に読み出しキャッシュデータをコピーすると共に読み出し管理フラグの値を１に変更してキャッシュ管理テーブルを状態ＩＩに遷移させる。状態ＩＩは読み出しキャッシュが利用できる状態であり、読み出し要求信号に対して直ちに読み出しキャッシュデータの内容を応答する。状態ＩＩＩは、書き込み管理フラグに１がたっているため、キャッシュデータの状態が書き込み済であることを表している。従って、このセクタ内に保持されているキャッシュデータを以後利用してはならない。状態ＩＶはＯＳ起動後読み込み処理が一度も行われていないうちに書き込み要求信号が送られた場合を表す。この場合にも書き込み管理フラグに１が立っているためこのセクタ内に保持されているキャッシュデータを以後利用してはならない。なお、後述するように、管理フラグの状態は常に状態Ｉ→状態ＩＩ→状態ＩＩＩ又は状態I→状態IVと遷移する。

なお、「（２）（ｉ）ｂ．」において説明したように、物理ディスクの第１のパーティションＰ１に書き込みキャッシュを割り当てることによって、クライアント端末側のローカルディスクの一部に書き込み済データの保持を許容するキャッシュ領域を更に設け、これを書き込みキャッシュとして利用してネットワーク負荷を軽減してもよい。ただし、この書き込みキャッシュ領域（Ｐ１）は、上述した「読み出しキャッシュ領域（Ｐ２）」とは異なる領域に別途設けなければならない。

図１４は、書き込みキャッシュ（ライトキャッシュ）を設けた場合のディスクアクセスの関係を説明した図である。

（ｉｖ）キャッシュ管理テーブルのバックアップ
管理フラグは物理メモリの非ページ領域（スワップ領域に退避されない領域）に読み込まれるため、ＯＳを再起動すればその内容はすべて消去される。しかし、読み出しキャッシュデータをＯＳ再起動後も利用するためには、ＯＳ再起動前の読み出し管理フラグの状態を保持しておく必要がある。そこで、読み出し管理フラグの状態を物理ディスクの第３のパーティション（Ｐ３）の「キャッシュ管理領域」に定期的にバックアップする。このバックアップ動作はフィルタドライバに対するデータの読み出しや書き込み処理とは非同期に行ってよい。但し、同期漏れ（同期間隔の間に更新されること）があっても、そのセクタについては読み出しキャッシュデータの利用を断念し、後段のフィルタドライバに処理を委任する。これは、読み出しキャッシュであるため、状態Ｉに遷移して再度サーバ側ディスクイメージから読出しを行えばデータの不整合は生じないからである。

キャッシュ管理テーブルは、ＯＳ起動中は、読み出し単位（セクタ）毎に「読み出し管理フラグ」と「書き込み管理フラグ」の合計２ビット必要である。例えば、ＳＣＳＩディスクの場合１セクタが５１２バイトであるから、５１２バイトあたり２ビットの物理メモリが必要となる。しかし、書き込み管理フラグについては再起動後はすべて０とするため、キャッシュ管理テーブルの状態を記憶する「キャッシュ管理領域（Ｐ３）」は、読み出し管理フラグの状態のみ保存すればよいので、５１２バイトあたり１ビットのディスク容量、つまり、読み出しキャッシュデータ１ＧＢ（ギガバイト）あたり、０．２５ＭＢ（メガバイト）のキャッシュ管理領域が最低限必要となる。

但し、実際の運用では、読み出しキャッシュデータの利用効率と高めるために、「読み出し管理フラグ」のデータを少なくともキャッシュ管理領域の異なる２箇所以上の場所に交互にかつ定期的に書き込むことによって、信頼性を高めることが好ましい。２個の複製をバックアップする運用を採用した場合、必要なキャッシュ管理領域の容量は、読み出しキャッシュデータ１ＧＢ（ギガバイト）あたり、０．５ＭＢ（メガバイト）、例えば、読み出しキャッシュデータ領域が３０ＧＢ（ギガバイト）であれば、１５ＭＢ（メガバイト）となる。

（ｖ）まとめ
ａ．書き込み管理フラグ及び読み出し管理フラグが共に０の場合には、読み出しキャッシュデータが存在しないため、リードキャッシュドライバ５０はＯＳ側４０からの読み出し要求信号の処理を後段のフィルタドライバ４６に委任すると共に、フィルタドライバ４６が受け取ったデータを読み出しキャッシュパーティション（Ｐ２）にコピーして読み出し管理フラグを０から１に変更する。（状態Ｉ→状態ＩＩ）

ｂ．書き込み管理フラグが０であって、読み出し管理フラグが１の場合（状態ＩＩ）には、リードキャッシュドライバ５０はＯＳ等４０からの読み出し要求信号に対して読み出しキャッシュデータから読み出したデータを応答する。

ｃ．書き込み要求信号を受け取った場合は、読み出しキャッシュデータを利用せず、リードキャッシュドライバ５０は常に後段のフィルタドライバ４６に読み出し要求信号をスルーさせ、以後の処理は後段のフィルタドライバ４６に委任すると共に書き込み管理フラグを０から１に変更する（状態ＩＩ→状態ＩＩＩ）。また、ＯＳ起動後、一度も読み込みが行われていない領域に、書き込みが行われた場合は、読み出し管理フラグ及び書き込み管理フラグが共に０の状態から、書き込み管理フラグのみを１に変更する（状態Ｉ→状態ＩＶ）。書き込み管理フラグに１がたっている時（状態ＩＩＩ及び状態ＩＶ）は、読み出しキャッシュデータを利用してはならない。

ｄ．サーバ側のイメージデータが更新されている場合やキャッシュデータが破損した場合等は、読み出し管理フラグと書き込み管理フラグの両方を０に変更する。

以上のような構成により、ネットワークブートを１度行ったクライアント端末が多数存在している場合は、２度目以降の起動はネットワークを介さずローカルディスクのキャッシュデータを用いて起動することができるため、ネットワーク負荷を劇的に軽減することができる。

特に、キャッシュデータを持つ多数のクライアントが一斉に起動しても、ネットワークアクセスが実質上ゼロとなり、全てのクライアントがローカルディスクと同等の速度で起動することができるようになる。その結果、サーバ１台あたりに接続できるクライアント端末数を大幅に増大させることができる。さらに、書き込み処理が行われたセクタをキャッシュの対象から除外しながら読み出しキャッシュデータをＯＳの再起動後も保存していくため、クライアント端末を使用すればするほどネットワーク負荷が軽減されていく。

しかも、読み出し専用のキャッシュであるから、ハードディスク障害時など、万一データの読み出しに失敗した場合は仮想ディスクイメージからネットワークブートによって起動するため、従来通りのディスクレス端末として動作させることもできる。

また、読み出しキャッシュ領域に加えて、スワップ領域やアプリケーションソフトのワークエリアや書き込みキャッシュ領域を別途を確保すれば、クライアント端末が一層快適に動作する。

［５］リビジョン（改訂情報）の管理
ネットワークブートシステムでは、最初に、クライアント端末のＯＳの起動イメージをサーバ側で作成することが必要となる。クライアント端末側はこの起動イメージをネットワークを介して仮想ディスクとしてマウントし、起動する。その際、クライアント端末側では上述したリードキャッシュドライバがネットワークを介して読み出したデータを順次保持していくことにより、一度読み出したデータ（より正確にはその後一度も書き込みが行われていないもの）について、再度読み出し要求があったときは、二度目以降はリードキャッシュデータを利用することになる。すなわち、リードキャッシュデータがあれば２回目以降の起動速度が劇的に高速化する。

しかしながら、仮想ディスクのデータが改訂（リビジョン）された場合、そのままではリビジョンされたデータをリードキャッシュデータに反映させることができない。なお、仮想ディスクのデータの改訂を行う要因としては、例えば、ＯＳ或いはウイルスパターンのアップデート・プログラムの新規インストール・ＯＳ上の種々の設定変更などが想定される。

図４（ａ）は、ネットワーク上にある仮想ディスクの実体となる物理ディスク１１に含まれる仮想ディスクのディスクイメージとその改訂番号（リビジョン）の変遷を示している。リビジョンは時間的な前後関係を表すもので、順次増加するように付与すれば、大小関係の比較によって前後関係を容易に比較できる。この例では、現在の仮想ディスクのデータのリビジョンが、リビジョン１からリビジョン５まで遷移して、最新のリビジョンがリビジョン５であることを示している。

図４（ｂ）は、システム内に存在する複数のクライアント端末２０ａ〜２０ｃを示している。このクライアント端末側はローカルディスク内にリードキャッシュパーティションＰ２を持っているが、保持されているリードキャッシュデータのリビジョンはそれぞれ異なっている。例えば、クライアント端末Ａは、リビジョン１のキャッシュデータを持っており、クライアント端末Ｂはリビジョン３のキャッシュデータを持っており、クライアント端末Ｃはリビジョン５のキャッシュデータを持っている。

クライアント端末Ｃは、リードキャッシュデータが最新のリビジョンであるリビジョン５と一致するため、リードキャッシュデータをそのまま利用してもデータの不整合を生じることはなく、安全である。

これに対し、クライアント端末Ａ及びＢは、リードキャッシュデータが最新のリビジョン（リビジョン５）より古いため、ローカルディスク内に保持しているリードキャッシュデータをそのまま利用した場合には、データの不整合を生じる。すなわち、リードキャッシュされている、あるセクタ内のデータが、ｖＤｉｓｋにおける同一セクタ内のデータと不一致となり、本来読み込むべきデータとは異なるデータをクライアント端末が読み取ることになる。このような状況は、クライアント端末側の動作を不安定にすることが懸念され、最悪の場合、そのクライアント端末において、ＯＳが起動が動作しなくなる危険がある。

そこで、仮想ディスクのデータとリードキャッシュデータの現在のリビジョンをそれぞれ保存する領域を設け、両者が一致しているか否かを判定することによってリードキャッシュデータを利用してもよいか否かを判断することができる。

そして、一致している場合にはリードキャッシュデータをそのまま利用し、不一致であれば、リードキャッシュデータを全て破棄し、再度リードキャッシュを行うことで、安全にリードキャッシュを動作させることができる。

なお、リビジョンは時間的な前後関係を表すものであればよい。従って、時刻情報そのものをリビジョンとして利用しても良い。

（第１の実施形態の変形例）
図１５に示すように、クライアント端末から独立した場所にローカルディスクを持つクライアントプロキシー（代理端末）３０を設置してもよい。
クライアント端末２０（２０ａ，２０ｂ，・・・）とクライアントプロキシー３０とを同一のＬＡＮ内におくなどして両者の間に高速通信を確保しておけば、サーバー１０とのデータのやりとりはクライアントプロキシー３０が代理するため、サーバー−プロキシー間のネットワークは「低速」或いは「高遅延」であってもよい。本明細書における「クライアント端末が物理的な記憶装置を備える場合」には、ローカルディスクを備えたクライアントプロキシー３０を利用する代わりにクライアント端末側が物理的な記憶装置（ローカルディスク）を備えていない場合が含まれるものと解する。

（第２の実施形態）−ダーティフラグ（書き込み済フラグ）−
ネットワークブートシステムは、通常、「シェアーモード」と「プライベートモード」という２つの動作モードを有している。シェアーモードとは、複数のクライアント端末でサーバ上の仮想ディスクを共有して使用するモードであり、システムを通常の運用環境で動作させるためのモードである。一方、プライベートモードとは、サーバ上の仮想ディスクにクライアントが直接書き込みすることができるモードであり、システムを保守（メンテナンス）環境で動作させるためのモードである。プライベートモードに設定された状態でクライアント端末を起動することにより、ＯＳやプログラムのアップデートや新規インストール或いは設定変更を行うなど、仮想ディスクのデータに変更を加えることができる。

動作モードの設定は、サーバ上で行われる。クライアント端末は、現在のモードがシェアーモードであるのかプライベートモードであるのかを知ることはできないことが通常である。

シェアーモードで起動した場合、クライアント端末は仮想ディスクに直接書き込みデータを送ることができないため、各クライアントごとに設けられた所定の書き込みキャッシュに書き込みデータを保存する。この書き込みキャッシュの保存領域は、システムによって様々であり、例えばクライアント側のローカルディスクの書き込みキャッシュ領域（例えば図３（ａ）の物理パーティションＰ１）、或いはサーバ側の物理ディスク、ネットワーク上に設けられたファイルサーバ等、いずれもＯＳの起動イメージが保存されている仮想ディスクとは異なる、クライアント端末ごとに設けられた所定のデータ保存領域である。

プライベートモードで起動した場合、クライアント端末は仮想ディスクに直接書き込みデータを送ることができ、仮想ディスクのデータに変更を加えることができる。

すなわち、クライアント端末が書き込みデータを保存する場合、シェアーモードで起動されたときは所定の書き込みキャッシュに、プライベートモードで起動されたときは仮想ディスクに、書き込みデータを保存することになるが、クライアント端末自身は、書き込みデータの保存先を選択することはもちろん、現在の保存先が書き込みキャッシュと仮想ディスクのどちらであるかを意識することすらできないことが通常である。

仮想ディスクのデータに変更を加える際の従来の手順は、システム管理者がまずシェアーモードからプライベートモードに設定変更した後、特定のクライアント端末１台を起動し、そこで仮想ディスクのデータの更新を行い、最後にプライベートモードをシェアーモードに設定を戻し、最後に仮想ディスクのリビジョンを手動で更新するというものである。

読み出しキャッシュ機構を備えたネットワークブートシステムにおいて、仮想ディスクのリビジョンが更新されていく場合に、クライアント端末側に要求される条件は、「リビジョンが異なるときには、リードキャッシュデータをそのまま利用して起動してはならない」ということである。万一、仮想ディスクのデータのリビジョンとリードキャッシュデータのリビジョンとが形式的には同一であるにもかかわらず、データの不一致がある場合、例えば、システム管理者がプライベートモードで仮想ディスクのデータを改訂した後、シェアーモードに設定を戻した際に、リビジョンの更新をし忘れた場合に、リードキャッシュデータをそのまま利用してクライアント端末を起動すると、ＯＳが起動しなかったり異常停止するなど重大なトラブルの原因となる。

ところが、このような問題が起こる直接の原因は、クライアント端末が、リビジョン改訂前のリードキャッシュデータを用いることにあり、発想を転換して、
『仮想ディスクのデータに変更が加えられたときは、特別の条件を満たさない限り、リビジョンの一致不一致にかかわらず、読み出しキャッシュを停止する』ことで、全ての問題が解決する。

この発想を実現するために必要なことは、「仮想ディスクのデータが改訂されたことを示すマークを仮想ディスク内に設けること」である。以下、図面を参照してその具体的な方法について詳述する。

システム構成として、書き込みキャッシュパーティション（例えば図３におけるパーティションＶ１）と、仮想ディスクの一部（例えば図３におけるパーティションＶ２）に、１ビットのフラグ保存領域を設ける。なお、ディスクアクセスの関係図は図１４を援用する。このうち、仮想ディスクのフラグ保存領域に保持されるフラグを特に、「ダーティフラグ」と定義する。ダーティフラグは、仮想ディスクのデータに変更が加えられたことを全てのクライアントに伝える手段として機能する。クライアント端末は、起動時にリビジョンではなくダーティフラグの値に基づいて、読み出しキャッシュを起動するか、停止するかを判断する。

（ダーティフラグに関するルール）
図６は、ダーティフラグに関するルールを説明する一覧表である。以下、具体的に説明する。
ルール１．クライアント端末のＣＰＵは、起動時に、「仮想ディスクのダーティフラグ」に「１」が書き込まれているか否かを調べ、仮想ディスクのダーティフラグの値によって、以下のように動作を切り換える。
ルール１−１ ダーティフラグが０のときは、読み出しキャッシュを開始する。（通常動作）
ルール１−２ ダーティフラグが１のときは、読み出しキャッシュを停止する。
ルール２．クライアント端末を起動したとき、常に、現在のフラグ保存領域に「１」を書き込む。
ルール３．プライベートモードで起動し、仮想ディスクのデータの改訂に成功した後、リビジョンを安全に更新したときは、「ダーティフラグ」をクリアするため、ダーティフラグに「０」を書き込む。

ルール２において、シェアーモードで起動したときの「現在のフラグ保存領域」は書き込みキャッシュであり、プライベートモードのときは仮想ディスクである。つまり、シェアーモードで何回起動しても仮想ディスクに書き込みが行われることはないので、ダーティフラグの値は変更されないが、プライベートモードで起動した場合には、仮想ディスクのデータの変更の有無によらず、起動した時点でダーティフラグの値が１となる。「現在のフラグ保存領域」は、動作モードによって相対的に変動する。

また、ルール３が実行されず、万一、ダーティフラグが０に設定されなかった場合、ダーティフラグが１のままである。この場合、ルール１−２によって、読み出しキャッシュが停止しているため、プライベートモードであれば改訂作業を継続でき、シェアーモードであればキャッシュデータとの不整合によるシステムの障害は回避される。

図５（ａ）は、クライアント端末をシェアモードで起動した際のクライアント端末の動作を示し、図５（ｂ）は、クライアント端末をプライベートモードで起動した際のクライアント端末の動作を示している。

もし、図５（ａ）のように、シェアーモードで起動されているとすると、起動時に書き込まれる１ビットの書き込みデータの保存先は、「書き込みキャッシュ」の一部に設けられたフラグ保存領域であるから、仮想ディスクのダーティフラグに書き込まれることはない。従って、ダーティフラグの値は変化せず、起動前の状態、すなわち、起動前のフラグ状態が０なら起動後も０のままとなる。

ところが、図５（ｂ）のように、プライベートモードで起動されているとすると、起動時に書き込まれる１ビットの書き込みデータの保存先は、「書き込みキャッシュ」の一部に設けられたフラグ保存領域ではなく、仮想ディスクのダーティフラグである。従って、ダーティフラグの値は起動前の状態にかかわらず、１となる。

すなわち、クライアント端末が起動時にダーティフラグの値を調べることで、リードキャッシュデータを利用してよいかどうかを判断することができる。ダーティフラグの値が１であれば、リビジョンの値にかかわらず、仮想ディスクのデータに変更が加えられた可能性があり、ダーティフラグの値が０であれば、リビジョンの値にかかわらず、仮想ディスクのデータのバージョンは、リードキャッシュデータのバージョンと等しいはずであると判断できる。このように、リビジョンの比較ではなくダーティフラグの値によって読み出しキャッシュの動作を決定するのである。ダーティフラグの値は全てのクライアントが共有する「仮想ディスクの一部」であるため、全てのクライアント端末が起動時に知ることができる。そして、ダーティフラグの値が１であれば、いずれかのクライアント端末が仮想ディスクのデータに変更を加えたことを意味するので、そのクライアント端末は、読み出しキャッシュを停止させる（ルール１−２）。

図７は、仮想ディスクのデータ改訂手順を説明するフローチャートである。仮想ディスクのデータを改訂するときは、はじめに、サーバの設定を「プライベートモード」に設定してクライアント端末を起動する（Ｓｔａｒｔ）。クライアント端末のＣＰＵは、ダーティフラグの値を確認する（Ｓａ１）。

ダーティフラグが１である場合、仮想ディスクのデータが、既に他のクライアント端末によって改訂されたかもしくは改訂中である可能性があるため、読み出しキャッシュを停止する（ルール１−２）。これによって、例えば、
１．プライベートモードでクライアント端末Ａを起動し、改訂作業の後、クライアント端末Ａを停止する。
２．さらに、リビジョン更新することなく、プライベートモードのままで端末Bを起動し、改訂作業の続きを行い、クライアント端末Ｂを停止する。
３．その後、仮想ディスクの「リビジョンを更新」し「書き込みフラグをクリア」する。
という一連の作業を問題なく行うことができ、サーバのメンテナンスが容易となる。

ただし、この際、「プライベートモードで初めて起動したクライアント端末Ａによる更新作業時」には読み出しキャッシュが動作していても問題ないのに対し、プライベートモードでの２回目の起動となるクライアント端末Ｂでの更新作業時」には、読み出しキャッシュは必ず停止していなければならない。この理由により、端末の起動時には、毎回必ず「書き込み済みフラグを立てる」という動作を行っているのである。その動作の結果として、プライベートで起動したときは、安全にリビジョンの更新作業を終えダーティフラグをクリアない限り、その次に起動した際にダーティフラグが１になっているという、期待通りの結果になる。

ダーティフラグが０である場合、仮想ディスクのデータは変更されていないので、今から改訂作業を行うことを他のクライアント端末に知らせるため、フラグに１を書き込む（ルール２）。いま、サーバはプライベートモードで起動しているので、仮想ディスクの一部に設けた「ダーティフラグ」に１が書き込まれる（Ｓａ２）。これによって、予期しないクライアント端末が起動しても、ダーティフラグが１であるので起動時に読み出しキャッシュが停止される（ルール１−２）。

次に、仮想ディスクのデータに変更を加える（Ｓａ３）。例えば、ＯＳのアップデート、アプリケーションのインストールや更新・削除、各種の設定変更等を行う。なお、仮想ディスクは全てのクライアント端末が共有するため、データの変更は全てのクライアントの動作に影響する。但し、リードキャッシュデータがある場合には、リードキャッシュデータをそのまま利用することはできないので、全てのリードキャッシュデータを破棄する（第１の実施形態）か、又は変更が加えられたセクタに対応するリードキャッシュデータのみを破棄する（第３の実施形態）。これにより、データの不整合による深刻なシステム障害という問題を回避することができる。

データの改訂が終了した後、仮想ディスクのリビジョンを更新し、最後にダーティフラグを０に設定する（ルール３）。

以上のように、本実施形態に係る発明は、「読み出しキャッシュが動作してはいけない状態」がどのような状態のときであるのかという点についての詳細な検討に基づいている。一見、「プライベートモードで起動しているとき」が条件のようにも思えるが、詳細に検討すると、「プライベートモードで初めて起動された後、２回目以降にプライベートモードで起動された場合」であることが分かる。そこで、仮想ディスク内に「ダーティフラグ」という１ビットの領域を確保し、各クライアント端末のプライベートモードでの起動時には必ずこのフラグを立てるという運用にすると、「書き込み許可モードに変更されたあと、2回目以降に起動された場合」にのみこのフラグの値が1となった状態でプライベート端末が起動されることになる。後は、「ダーティフラグの値が１となっている時には読み出しキャッシュの動作をしない」という判断を入れることで、安全にリードキャッシュデータを利用することができる。なお、この「書き込み済みフラグ」は「リビジョン更新作業」の際に同時に行う設計とすることで、より安全に運用することができる。

（第３の実施形態）−リードキャッシュデータのリビジョン更新−
第３の実施形態では、シェアーモードにおいて、クライアント端末が、自身が保存しているリードキャッシュデータのリビジョンよりも仮想ディスクのリビジョンが大きいことを検知した場合の動作について説明する。この場合、最も安全な動作は第２の実施形態で説明したように、過去のキャッシュデータを全て破棄し、新たに読み出しキャッシュデータを再構成することである。

しかし、この方法では、リビジョンが更新されるたびに蓄積されたリードキャッシュデータの全てが無駄になり、ネットワーク負荷を増大させる原因ともなる。その一方で、リビジョンが異なる２つのｖＤｉｓｋのデータを比較したとき、リビジョンの番号が近ければ近いほどデータの差分は小さいため、大部分のデータが変更されずに保持されているはずである。従って、このような場合に全てのリードキャッシュデータを破棄してしまうことは極めて非効率的であり、可能な限りこのような事態を避けることが好ましい。そこで、既に読み出されたキャッシュデータを極力利用するように、すなわち、リビジョンの更新の結果、変更が行われたセクタ内のデータのみデータを破棄して仮想ディスクから再度読み込み、変更されていないセクタ内のリードキャッシュデータは破棄せずに保持する。

本発明に係るネットワークブートシステムでは、異なるリビジョン間で仮想ディスク内のどの領域のデータが変更されたかを示す「変更領域マップ」を作成し、その変更領域マップを改訂前のリビジョンの「キャッシュ管理テーブル」に適用することによって、改訂後のキャッシュ管理テーブルを生成し、これによって、破棄するデータを必要最小限にとどめている。以下、図８を参照して、具体例を説明する。

図８（ａ）は、リビジョン１２からリビジョン１３への変更領域マップを例示したものである。リビジョンの更新によって、セクタ内のデータに変更が加えられた領域（変更領域）を１、リビジョンの更新によって、セクタ内のデータに変更が加えられない領域（未変更領域）を０として、全てのセクタに対する変更の有無を示している。図８(ａ）に示す変更領域マップは、セクタＡとセクタＢに１が記録され、その他は全て０が記録されている。これは、リビジョン１２からリビジョン１３に変更されたことによって、セクタＡとセクタＢのデータに変更が加えられ、その他のセクタには一切変更が加えられなかったことを示している。すなわち、変更領域マップ６０とは、リビジョン間で仮想ディスクのデータのうちどの領域のデータが改訂されたかを記録して関連づける改訂履歴の管理情報であり、１ビットの情報（０又は１）で表されるビット列であり、例えば初期状態を０として、変更が行われた領域は１、未変更領域は０を割り当てる。

変更領域マップは変更されたデータ領域（セクタ）を示すだけでその領域内のデータの中身については一切情報を保持しない。このため、変更領域マップの容量サイズを仮想ディスク（ｖＤｉｓｋ）のサイズよりもはるかに小さくすることができる。例えば、現状のハードディスク等の記録単位を例にとり、１セクタに５１２バイトのデータが保存されているとすると、５１２バイト（＝４０９６ビット）あたり１ビットとなるため、仮想ディスクの容量の１／４０９６（＝１ビット／５１２バイト）のサイズでよいことが分かる。

図８（ｂ）は、リビジョン１２のキャッシュ管理テーブル７０ａを例示した図である。この例では、仮想ディスクのセクタＡのデータが既にリードキャッシュデータとしてクライアント端末のローカルディスク内に保存されていること、及び仮想ディスクのセクタＢのデータはリードキャッシュデータが無いことを示している。

図８（ｃ）は、図８（ａ）に示すリビジョン１２から１３への「変更領域マップ」を図８（ｂ）に示すリビジョン１２の「キャッシュ管理テーブル」に適用することによって生成された、リビジョン１３のキャッシュ管理テーブルを示している。上述のように、仮想ディスクにおけるセクタＡ内のデータは、クライアント端末において読み出し済であり、すでにリードキャッシュデータを保持している。しかし、図８（ａ）の変更領域マップによれば、セクタＡ内のデータは改訂されているため、ローカルディスク内に保持されているセクタＡのリードキャッシュデータは破棄されなければならない。一方、セクタＢのリードキャッシュデータは、もともとリードキャッシュデータが無いため、キャッシュ管理フラグを０としてネットワークを介して読み出すことができる。

このように、リビジョン間の変更領域マップによって、クライアント側にリードキャッシュされているデータを最大限活かしながら安全にリビジョンを更新させることができ、ネットワーク負荷を軽減することができる。

従って、リビジョンがどれだけ古くても、現在のリビジョンのキャッシュ管理テーブルと、最新のリビジョン間に至る全ての変更領域マップさえあれば、各リビジョン間の変更領域マップを順次適用することで、リードキャッシュデータの破棄を最小限のセクタにとどめ、最新のリビジョンに対応させることができることが分かる。

図９（ａ）は、変更領域マップ群６１を示している。この変更領域マップ群は、リビジョン１からリビジョン２，リビジョン２からリビジョン３、・・・、リビジョン１９から最新であるリビジョン２０へと、隣接する全てのリビジョン間の変更領域マップを集めたものである。

図９（ｂ）は、図９（ａ）に示す変更領域マップ群６１を順次適用することにより、クライアント端末上のリードキャッシュドライバの管理するキャッシュ管理テーブルが、リビジョン１８のキャッシュ管理テーブルから最新のリビジョンであるリビジョン２０へと順次遷移していく様子を示している。

すなわち、図９に示す例では、クライアント端末上のリードキャッシュドライバの管理するキャッシュ管理テーブルのリビジョン（リードキャッシュデータのリビジョン）がリビジョン１８である場合、このリビジョン１８のキャッシュ管理テーブルにリビジョン１８からリビジョン１９への変更領域マップ及びリビジョン１９からリビジョン２０への変更領域マップを順次適用すると、変更領域マップの値が１であるセクタ（変更領域）に対応するキャッシュ管理テーブルが順次０に更新され、最新のリビジョン２０のキャッシュ管理テーブルが生成される。

図１０（ａ）は、２つの変更領域マップからなる変更領域マップ群６２と、両者を集約した１つの変更領域マップ６３を例示している。変更領域マップ群６２は、リビジョン１８からリビジョン１９への変更領域マップ６２ａと、リビジョン１９からリビジョン２０への変更領域マップ６２ｂとから構成される。また、変更領域マップ群６２の下段に示した変更領域マップ６３は、リビジョン１８からリビジョン２０への変更領域マップであるが、変更領域マップ６３のビット列は、変更領域マップ６２ａと変更領域マップ６２ｂの論理和（ｏｒ）と一致している。この例から明らかなように、集約された一つの変更領域マップを作成するには、単に、集約する複数のリビジョン間の変更領域マップ群の論理和を求めればよいことが分かる。なお、変更領域のセクタを直接記録する方法の場合、上述のような変更領域マップの集約は不可能である。

図１０（ｂ）は、図１０（ａ）に示す集約された変更領域マップ６３をリビジョン１８のキャッシュ管理テーブルに適用した場合におけるキャッシュ管理テーブル７２の遷移状態を示している。クライアント端末上のリードキャッシュドライバが管理するリビジョン１８のキャッシュ管理テーブル７２ａに対して、集約された変更領域マップ６３を適用すると、図９（ｂ）に示すリビジョン２０のキャッシュ管理テーブルと同一のキャッシュ管理テーブル７２ｂが得られることが分かる。

図１１（ａ）は、複数の集約された変更領域マップ群６４を例示している。ここに示す変更領域マップ群６４は、リビジョン１３からリビジョン１５への変更領域マップ６４ａと、リビジョン１５からリビジョン１８への変更領域マップ６４ｂと、リビジョン１８からリビジョン２０（但し、リビジョン２０は最新のリビジョンであるとする。）への変更領域マップ６４ｃとから構成される。

図１１（ｂ）は、リビジョン１６のキャッシュ管理テーブルを持つクライアント端末を最新であるリビジョン２０に遷移させる際のキャッシュ管理テーブル７３の遷移状態を例示している。リビジョン１６をリビジョン１８に遷移させる場合、図１１（ａ）で示したリビジョン１５からリビジョン１８の変更領域マップ６４ｂを適用することができる。なぜなら、リビジョン１６は、１５から１８の間に含まれるからである。ここからさらに、リビジョン１８からリビジョン２０への変更領域マップ６４ｃをリビジョン１６のキャッシュ管理テーブルに適用すればよい。すなわち、集約された変更領域マップは、集約された範囲に含まれる全てのリビジョンのキャッシュ管理テーブルに適用することができる。

図１１（ｃ）は、リビジョン１２のキャッシュ管理テーブルからリビジョン２０のキャッシュ管理テーブルに更新させた場合のキャッシュ管理テーブルの遷移を示している。この例のように、クライアント端末のリードキャッシュデータのリビジョンが、複数の集約された変更領域マップ群に含まれるどのリビジョンの範囲内にも存在しないような、古いリビジョン（（すなわち、図１１（ａ）の例ではリビジョン１２以前）のキャッシュ管理テーブルに対しては、リビジョン１２のキャッシュ管理テーブルをリビジョン２０のキャッシュ管理テーブルに更新することができない。

このような場合、クライアント端末上のリードキャッシュドライバは、クライアント端末上のリードキャッシュのデータを全て破棄して、再度新規にデータを読み込むことが必要となるが、このようにすれば、最新のリビジョン２０のキャッシュ管理テーブルでキャッシュされるデータと同じデータをキャッシュできることとなる。

また、変更領域マップはリビジョンが上がるほど数が増えるため、十分な保存領域が確保できない場合が考えられる。しかし、このような場合には、複数の変更領域マップマップを集約することによって、変更領域マップの数を減らすか、又はすでに残っていないであろう古いリビジョンの変更領域マップを削除することで対処できる。万一、リビジョンの更新ができないことがあっても、その場合は図１１（ｃ）で説明したように、クライアント端末上のリードキャッシュのデータを全て破棄して、再度新規にデータを読み込むことで対処できる。

変更領域マップは、仮想ディスクとのデータの整合性と変更領域マップの蓄積及び集約によるクライアント端末上のキャッシュ管理テーブルのデータ更新の利便性から、プライベートモードで仮想ディスクのデータを改訂するたびごとに作成することが好ましい。この場合、先ず変更領域マップを作成し、次いでデータの書き込みを行うべきである。また、変更領域マップは、クライアントが起動時にアクセスできる場所であって、書き込み作業時に記録を残せる場所に保持することが好ましい。従って、変更領域マップを保持するための記憶領域は、仮想ディスク内に確保することが合理的である。仮想ディスク内に変更領域マップを確保すると、どのクライアント端末からでも改訂作業ができるようになる等の利点がある。

（第４の実施形態）−複数の仮想ディスクの共有−
第４の実施形態では、仮想ディスクが複数存在している場合について説明する。クライアント端末が起動時にどの仮想ディスクで起動するかを選択できるように構成されているときは、それぞれの仮想ディスクに対して、リビジョンの更新が行われる。従って、その場合、それぞれの仮想ディスクにタイトルや識別記号等を付与し、どの仮想ディスクに対するリビジョンかを区別することが必要となる。

ある１つの仮想ディスクに着目したとき、その仮想ディスクのリビジョンが更新されデータの内容が少しずつ変更されたとしてても、当該仮想ディスクがＯＳとしてのの同一性を失わないことはいうまでもない。このような意味において、一つの仮想ディスクと変更領域マップによる改訂履歴情報を含む一体性のある系列を「ＯＳグループ」と定義する。

リビジョンは同一のＯＳグループに属する仮想ディスクの更新情報であり、ＯＳグループが同じであれば、仮想ディスクの容量は同一であり、かつキャッシュ領域も同一のものを用いる。ＯＳグループに関する情報（ＯＳの名前や識別記号等）は変更領域マップ等と共に、仮想ディスク自体又は仮想ディスクに関連づけられた場所に保存することが好ましい。仮想ディスクの一部に情報を埋め込むか、又は、ネットワークを介して情報を取得できるようにすればネットワーク上のどこに保存しても差し支えない。

従って、複数のＯＳグループが存在する、すなわち仮想ディスクが複数存在する場合には、仮想ディスクのデータとリードキャッシュデータのそれぞれのリビジョンを対比するだけでなく、ＯＳグループが同一であるかどうかについても判断することが必要となる。

そのため、クライアント端末上のリードキャッシュドライバは、クライアント端末上のリードキャッシュデータのＯＳグループ及びそのリビジョンと、仮想ディスクのＯＳグループ及びそのリビジョンとを比較して以下の処理を行う。

（１）ＯＳグループ及びリビジョン双方が一致する場合、リードキャッシュデータをそのまま利用する。
（２）ＯＳグループが同じで仮想ディスクのリビジョンが新しい場合、リードキャッシュデータを更新し、更新されたリードキャッシュデータを利用する。
（３）ＯＳグループが同じで仮想ディスクのリビジョンが古い場合、リードキャッシュデータを利用しない。
（４）ＯＳグループが異なる場合、リードキャッシュデータのデータを全て破棄して新たに読み出しキャッシュを構成するか又は、読み出しキャッシュを利用しない。

このように、リビジョンはＯＳグループが一致するもの同士で管理される。従って、ＯＳグループが複数存在するときはＯＳグループが一致するか否かについても考慮し、リードキャッシュデータを利用できるか否かを判断し、利用できるときのみ利用することが必要である。

クライアント端末側はＯＳグループを起動時に選択することで、異なるＯＳを起動したり、設定の異なる状態で起動したりすることができる。リードキャッシュデータが利用できる場合にはネットワーク負荷を軽減することができ、起動速度も向上する。

本発明にかかる変更領域マップは、ネットワークブートシステムにおいて、クライアント端末上のキャッシュのデータを更新する際にかかるネットワーク負荷を軽減することができる。このように、本発明を実施した場合の産業上の利用可能性は極めて大きい。

第１の実施形態のネットワークブートシステムの基本構成を説明するための概念図 第１の実施形態のネットワークブートシステムにおけるディスクアクセスの関係を説明図 第１の実施形態のネットワークブートシステムにおけるクライアント端末側のディスク構成例 （ａ）は、ネットワーク上にある仮想ディスクの実体となる物理ディスク１１に含まれる仮想ディスクのディスクイメージとその改訂番号（リビジョン）の変遷図、（ｂ）は、システム内に存在する複数のクライアント端末を示す図 第２の実施形態に係るネットワークブートシステムにおける動作モードの説明図 ダーティフラグに関するルールを説明する一覧表 本発明のクライアント端末上のリードキャッシュドライバの動作手順を説明図 （ａ）は、リビジョン１２からリビジョン１３への変更領域マップの例、（ｂ）は、リビジョン１２のキャッシュ管理テーブル７０ａの例、（ｃ）は、（ｂ）に示すリビジョン１２の「キャッシュ管理テーブル」に対して（ａ）に示すリビジョン１２から１３への「変更領域マップ」を適用して生成された、リビジョン１３のキャッシュ管理テーブル （ａ）は、変更領域マップ群６１、（ｂ）は、（ａ）に示す変更領域マップ群６１を順次適用することにより、クライアント端末上のリードキャッシュドライバの管理するキャッシュ管理テーブルが、リビジョン１８のキャッシュ管理テーブルから最新のリビジョンであるリビジョン２０へと順次遷移していく様子を示した図 （ａ）は、２つの変更領域マップからなる変更領域マップ群６２と、両者を集約した１つの変更領域マップ６３の例、（ｂ）は、（ａ）に示す集約された変更領域マップ６３をリビジョン１８のキャッシュ管理テーブルに適用した場合におけるキャッシュ管理テーブル７２の遷移図 （ａ）は、複数の集約された変更領域マップ群６４の例、（ｂ）は、リビジョン１６のキャッシュ管理テーブルを持つクライアント端末を最新であるリビジョン２０に遷移させる際のキャッシュ管理テーブル７３の遷移状態の例、（ｃ）は、リビジョン１２のキャッシュ管理テーブルからリビジョン２０のキャッシュ管理テーブル更新させた場合のキャッシュ管理テーブルの遷移図 （ａ）及び（ｂ）は、コンピュータシステムにおけるディスクアクセスの関係を説明するための図 （ａ）は、キャッシュ管理テーブルの例、（ｂ）は、キャッシュ管理テーブルの状態とその動作をまとめた一覧表を示す図 書き込みキャッシュ（ライトキャッシュ）を設けた場合のディスクアクセスの関係を説明した図である。 第１の実施形態の変形例を説明した図である。

Claims (8)

1. クライアント端末上で動作するオペレーティングシステムを含むディスクイメージを仮想ディスクとして提供するネットワークブートサーバと、物理的な記憶装置を備えたクライアント端末とがネットワークを介して接続され、
   前記クライアント端末は、前記オペレーティングシステム起動中に必要なデータを一時的に保存することができる物理メモリと、前記ネットワークを介して前記サーバにアクセスするためのネットワークインターフェースとを備えていると共に、
   前記オペレーティングシステムは、
   前記クライアント端末のローカルバスに対するアクセスを前記ネットワークに対するアクセスに変換するためのフィルタドライバと、前記記憶装置を駆動するためのリードキャッシュドライバを備えており、
   前記リードキャッシュドライバが、前記フィルタドライバによって前記ネットワークブートサーバから読み出されたデータを前記記憶装置に読み出しキャッシュするリードキャッシュ機構を備えたネットワークブートシステムであって、
   前記リードキャッシュ機構は、前記サーバから受け取ったデータを保持するための読み出しキャッシュ領域と共に前記物理メモリに保持されている前記リードキャッシュドライバが前記サーバから読み出されたデータが書き込み済であるか否かを判別するための管理フラグの少なくとも一部を書き戻すためのキャッシュ管理領域を備え、
   前記仮想ディスクのデータのリビジョンを記憶する第１の記憶手段と、前記読み出しキャッシュされたリードキャッシュデータのリビジョンを記憶する第２の記憶手段と、前記第１及び第２のリビジョンを比較する手段と、前記比較結果に基づいて前記リードキャッシュドライバの動作を決定する決定手段とを具備することを特徴とするネットワークブートシステム。
2. 前記第１のリビジョンは、前記仮想ディスクの一部として又は前記仮想ディスクに関連づけられて保持されることを特徴とする請求項１記載のネットワークブートシステム。
3. 前記第２のリビジョンは、前記記憶装置の一部に保持されることを特徴とする請求項１又は請求項２記載のネットワークブートシステム。
4. 前記クライアント端末からの書き込み情報をキャッシュするための書き込みライトキャッシュ領域をさらに具備すると共に、
   前記仮想ディスクの一部に、少なくとも１ビットのフラグ保存領域を具備することを特徴とする請求項１乃至３のいずれか１項に記載のネットワークブートシステム。
5. 複数のクライアント端末でサーバ上の仮想ディスクを共有して使用するシェアーモードモードで前記クライアント端末を起動したときは、前記ライトキャッシュ領域に設けたフラグ管理領域に１を書き込み、サーバ上の仮想ディスクにクライアントが直接書き込みすることができるプライベートモードで前記クライアント端末を起動したときは、前記仮想ディスクの保存領域に設けたフラグ管理領域に１を書き込み、
   前記クライアント端末は、起動時に前記仮想ディスクの保存領域に設けたフラグ管理領域の記憶された値に基づいて、前記読み出しキャッシュ機構を起動又は停止させることを特徴とする請求項１乃至４のいずれか１項に記載のネットワークブートシステム。
6. 前記第１のリビジョンのうち、異なる２つのリビジョン間で前記仮想ディスク内のどの領域のデータが変更されたかを示す変更領域マップと、前記変更領域マップを改訂前のリビジョンにおけるリードキャッシュデータの状態を表すキャッシュ管理テーブルに適用することによって、改訂後のキャッシュ管理テーブルを生成することを特徴とする請求項１乃至５記載のネットワークブートシステム。
7. 前記変更領域マップは前記仮想ディスクの一部その他前記クライアント端末が起動時に読み込むことができかつ前記クライアント端末から書き込み可能な領域に記憶されていることを特徴とする請求項６記載のネットワークブートシステム。
8. 前記第１のリビジョンのうち、連続するリビジョン間の変更領域マップの論理和を求めることにより、集約された連続する変更領域マップを生成する変更領域マップ集約手段を具備することを特徴とする請求項６又は請求項７記載のネットワークブートシステム。

Images