JP2001057571A

JP2001057571A - ファイルシステム

Info

Publication number: JP2001057571A
Application number: JP25846299A
Authority: JP
Inventors: Atsuhiro Tsuji; 敦宏辻; Shinzo Doi; 晋三土居; Yukiko Ito; 由起子伊藤; Tsutomu Tanaka; 田中　　勉
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 1998-09-14
Filing date: 1999-09-13
Publication date: 2001-02-27

Abstract

(57)【要約】【課題】帯域設定を行えるファイルシステムを実現す
る。そこにさらに、帯域保証機能や先読み機能を追加し
て、帯域設定機能と有機的に結合させることによって、
リアルタイム・リモート・ファイルシステムを実現す
る。【解決手段】アプリケーション３０２が発した帯域設
定要求は、拡張ＡＰＩ３１３を通じ、帯域設定部３０５
へと与えられる。帯域設定部３０５は、送信帯域幅制御
部３１１，３１４、および先読量制御部３１０に対し
て、帯域設定を行う。送信帯域制御部３１１，３１４、
および先読量制御部３１０はそれぞれ、設定された帯域
に基づいて、送信帯域幅の制御、および先読み量の制御
を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ファイルシステム
に関し、より特定的には、ファイルを蓄積するサーバ
と、ファイル操作を行う複数のクライアントとがネット
ワークを介して接続された環境において用いられ、各ク
ライアントがネットワークを通じてサーバにアクセスし
て、リアルタイムにファイル操作を行うためのリアルタ
イム・リモート・ファイルシステムに関する。

【０００２】

【従来の技術】ファイルシステムは、アプリケーション
からの要求に応じ、記録ディスクに対して、ファイル作
成やファイルの読み出し／書き込み等のファイル操作を
行うためのソフトウェアであり、一般的には、オペレー
ティングシステム（以下、ＯＳ）の一機能として提供さ
れる。特に、クライアント・サーバ・システムに適用さ
れて、サーバ側の記録ディスクに対し、クライアント側
からネットワークを通じてファイル操作を行うようなも
のを、リモート・ファイルシステムと呼ぶ。

【０００３】図３１は、従来のリモート・ファイルシス
テムが適用されるクライアント・サーバ・システムの構
成を示すブロック図である。図３１において、クライア
ント・サーバ・システムは、ファイル・サーバ３１０２
と、複数のクライアント３１０１とを備え、それらファ
イル・サーバ３１０２および複数のクライアント３１０
１がネットワーク３１０３を介して互いに接続されてい
る。ファイル・サーバ３１０２および複数のクライアン
ト３１０１は、それぞれコンピュータ装置によって実現
され、ネットワーク３１０３は、例えばＡＴＭやイーサ
ネット等の有線ネットワーク、Ｗ−ＣＤＭＡ等の無線ネ
ットワークによって実現される。

【０００４】図３２は、従来のリモート・ファイルシス
テムの機能的な構成を示すブロック図である（図３１の
クライアント・サーバ・システムに適用された場合）。
図３２において、従来のリモート・ファイルシステム
（以下、単にファイルシステムと呼ぶ）３２０１は、ク
ライアント３１０１を実現するコンピュータ装置上にお
いてアプリケーション３２０２が動作する環境を用意す
るＯＳ３２０３の一部であり、ファイル管理部３２０４
と、ファイル読出部３２０５と、ファイル書込部３２０
６とを備えている。アプリケーション３２０２とＯＳ３
２０３との間には、アプリケーション・プログラム・イ
ンターフェース（以下、ＡＰＩ）３２０７が設けられ
る。

【０００５】アプリケーション３２０２は、ファイル作
成やファイルの書き込み／読み出し等のファイル操作を
要求する。ＡＰＩ３２０７は、アプリケーション３２０
２からの要求を、ＯＳ３２０３に適合する形式に変換す
る。ＯＳ３２０３は、ＡＰＩ３２０７によって形式変換
された要求をファイルシステム３２０１へと与え、ファ
イルシステム３２０１は、与えられた要求に応じて、フ
ァイル・サーバ３１０２に対し、ネットワーク３１０３
を通じてファイル操作を行う。

【０００６】上記のファイルシステム３２０１におい
て、ファイル管理部３２０４は、そのファイルシステム
３２０１に与えられた要求の種別を判定し、判定の結
果、要求がファイル作成要求であれば、ファイル・サー
バ３１０２の記録ディスク上においてファイルを作成す
ると共に、そのファイルの属性情報（後述）を生成す
る。一方、要求がファイル読み出し要求であれば、ファ
イル・サーバ３１０２から属性情報を読み出してきて、
それをファイル読み出し要求と共にファイル読出部３２
０５へと与え、また、要求がファイル書き込み要求であ
れば、ファイル・サーバ３１０２から属性情報を読み出
してきて、それをファイル書き込み要求と共にファイル
書込部３２０６へと与える。

【０００７】ファイル読出部３２０５は、与えられた要
求に応じ、与えられた属性情報を参照して、ファイル・
サーバ３１０２に対し、ネットワーク３１０３を通じて
ファイル読み出しを実行する。ファイル書込部３２０６
は、与えられた要求に応じ、与えられた属性情報を参照
して、ファイル・サーバ３１０２に対し、ネットワーク
３１０３を通じてファイル書き込みを実行する。

【０００８】なお、上記のような従来のリモート・ファ
イルシステムの代表的な例としては、Ｍｉｃｒｏｓｏｆ
ｔ（登録商標）社のＯＳであるＷｉｎｄｏｗｓＮＴ
（登録商標）の持つリモート・ファイルシステムがあ
る。ＷｉｎｄｏｗｓＮＴやそのリモート・ファイルシ
ステム、その標準ＡＰＩであるＷｉｎ３２ＡＰＩ等につ
いては、「株式会社アスキー」発行、「Ｊｅｆｆｒｅｙ
Ｒｉｃｈｔｅｒ」著、「梅原系／鈴木慎司／長尾高
弘」訳の「ＡＤＶＡＮＣＥＤＷＩＮＤＯＷＳＮＴ」
や、「日経ＢＰ出版センター」発行、「及川卓也ら」著
の「ＷｉｎｄｏｗｓＮＴ３．５完全技術解説」（ＩＳ
ＢＮ４−８２２７−１００５−Ｘ）に詳述されている。
また、上記のようなアプリケーション３２０２として
は、例えば、動画像データをファイル（動画像ファイ
ル）として扱い、コンピュータ装置を用いて、それら動
画像ファイルを編集するためのノンリニア編集アプリケ
ーションなどがある。

【０００９】以上のように構成された従来のリモート・
ファイルシステム３２０１がネットワーク３１０３を通
じて行うファイル操作について、以下に説明する。最
初、アプリケーション３２０２が、ファイル操作を要求
する。このときアプリケーション３２０２が発するファ
イル操作要求には、操作の対象となるファイルを指定す
るための情報と、ファイル操作の種別（ここでは、ファ
イル作成、ファイル読み出し、およびファイル書き込み
のいずれか）とが含まれる。次に、ＡＰＩ３２０７は、
アプリケーション３２０２からのファイル操作要求を、
ＯＳ３２０３に適合する形式に変換する。次に、ＯＳ３
２０３は、ＡＰＩ３２０７によって形式変換された要求
をファイルシステム３２０１へと与える。次に、ファイ
ルシステム３２０１は、与えられた要求に応じて、ファ
イル・サーバ３１０２に対し、ネットワーク３１０３を
通じてファイル操作を行う。

【００１０】図３３は、図３２のリモート・ファイルシ
ステム３２０１が、図３１のクライアント・サーバ・シ
ステムに適用されて、ネットワーク３１０３を通じて行
う処理（ファイル操作）を示すフローチャートである。
図３３において、最初、ファイル管理部３２０４は、フ
ァイルシステム３２０１にファイル操作要求が与えられ
たか否かを判定する（ステップＳ３３０１）。そして、
判定結果が否定であれば待機し、肯定であれば、ファイ
ルシステム３２０１に与えられた要求がファイル作成要
求であるか否かを判定する（ステップＳ３３０２）。ス
テップＳ３３０２の判定結果が肯定の場合、ステップＳ
３３０７に進む。

【００１１】ステップＳ３３０２の判定結果が否定の場
合、ファイル管理部３２０４は、ファイル・サーバ３１
０２からネットワーク３１０３を通じて属性情報を読み
出し（ステップＳ３３０３）、次いで、読み出した属性
情報に含まれているファイル名やディレクトリに基づい
て、操作（読み出しまたは書き込み）の対象となるファ
イルを検索する（ステップＳ３３０４）。その後、ファ
イル管理部３２０４は、ファイルシステム３２０１に与
えられた要求がファイル書き込み要求か否かを判定する
（ステップＳ３３０５）。

【００１２】ステップＳ３３０５の判定結果が否定、つ
まり要求が読み出し要求であれば、ファイル読出部３２
０５は、ファイル読み出しを実行し（ステップＳ３３０
６）、その後、ステップＳ３３０９へと進む。なお、ス
テップＳ３３０６で読み出されたファイルは、ファイル
システム３２０１が管理する領域にいったん記憶され、
その後、アプリケーション３２０２へと渡される（つま
り、アプリケーション３２０２側のバッファ領域へとコ
ピーされる）。

【００１３】一方、ステップＳ３３０５の判定結果が肯
定、つまり要求が書き込み要求であれば、ファイル書込
部３２０６は、ファイル書き込みを実行し（ステップＳ
３３０８）、その後、ステップＳ３３０９へと進む。ス
テップＳ３３０７では、ファイル作成が行われると共
に、そのファイル（ここでは動画像ファイルとする）の
属性情報が生成される。生成された属性情報は、動画像
ファイルと共に、ファイル・サーバ３１０２の記録ディ
スクに格納される。ステップＳ３３０９では、ファイル
システム３２０１の動作を終了するか否かが判断され、
判断結果が否定であれば、ステップＳ３３０１へと戻っ
て、上記と同様の処理が繰り返される。一方、肯定であ
れば、動作が終了される。

【００１４】上記ステップＳ３３０６のファイル読み出
し処理は、次のようにして行われる。アプリケーション
３２０２は、あるファイルを読み出そうとする場合、そ
のファイルを一定サイズを有する複数個のブロック（読
み出し最小単位）に分割して、各ブロックに対する読み
出し要求（以下、ブロック読み出し要求）を順番に発し
ていく。それらブロック読み出し要求は、ＡＰＩ３２０
７によって形式変換された後、ＯＳ３２０３を通じてフ
ァイル読出部３２０５へと与えられる。応じて、ファイ
ル読出部３２０５は、ファイルを構成する各ブロックを
順番に読み出していく。

【００１５】図３４は、図３２のアプリケーション３２
０２が、ファイル読み出しの際に、ファイル読み出し要
求、および一連のブロック読み出し要求を発するタイミ
ングの一例（”同期的”読み出しの場合）を示したタイ
ムチャートである。図３４に示すように、アプリケーシ
ョン３２０２は、ファイル読み出し要求（前述）を発し
た後、ブロック読み出し要求を順番に発する処理を開始
する。その際、あるブロックに対する読み出し要求を発
した後、そのブロックが完全に読み出されるのを待っ
て、次のブロックに対する読み出し要求を発している。
なお、図３４のような”同期的”読み出しでなく、”非
同期的”読み出しを行うアプリケーションもあるが、ア
プリケーションが”同期的”読み出しを行うか、”非同
期的”読み出しを行うかは、本発明の本質と直接には関
係がない。そこで、以下では、アプリケーション３２０
２は、図３４のような手順で読み出し要求を発行するも
の仮定して説明する。

【００１６】なお、ステップＳ３３０８のファイル書き
込み処理も、上記と同様にブロック単位で行われる。こ
うしてブロック単位でファイル読み出し／書き込みを行
うことによって、記録ディスクへのランダムアクセスが
可能となり（これは動画像ファイルの編集処理に不可欠
である）、しかも、読み出したファイルを一時記憶する
バッファの容量を節約することが可能となる。

【００１７】ところで、図３３のステップＳ３３０６／
Ｓ３３０７のファイル読み出し／書き込みは、ネットワ
ーク３１０３の帯域のうち、他のシステム（例えば別の
ファイルシステムや通信システムなど）によって使われ
ていない空き帯域を利用して行われる。そのため、図３
１のようなクライアント・サーバ・システムでは、他の
システムが多くの帯域を使えば、その分、ファイルシス
テム３２０１が使う帯域は小さくなる。また、たとえフ
ァイルシステム３２０１が使う帯域が一定であっても、
複数のクライアント３１０１が同時にファイル読み出し
／書き込みを行えば、１クライアント３１０１あたりの
帯域は小さくなる。さらには、たとえ各クライアント３
１０１が使う帯域が一定であっても、そのクライアント
３１０１が同時に複数のファイル読み出し／ファイル書
き込みを行えば、１ファイルあたりの帯域は小さくな
る。一方、ファイル読み出し／書き込み用の帯域が小さ
くなればなるほど、送信帯域幅が低下し、その結果、読
み出し遅延／書き込み遅延が大きくなるので、従来のリ
モート・ファイルシステム３２０１では、記録再生にリ
アルタイム性が要求される動画像ファイル扱うことは困
難であった。

【００１８】ここで帯域とは、単位時間に伝送可能な最
大のデータ量をいい、例えばネットワーク３１０３を水
道管に例えると、その太さ（つまりパイプの断面積）
が、ネットワーク３１０３の帯域に相当する。一方、送
信帯域幅とは、ファイル読み出しやファイル書き込みを
行う際、単位時間に送信されるデータ量をいい、例え
ば、単位時間に上記の水道管内を流れる水の量が、ネッ
トワーク３１０３を利用してデータ送信を行う際の送信
帯域幅に相当する。また、読み出し遅延とは、アプリケ
ーション３２０２が、あるブロックについての読み出し
要求を発してから、そのブロックが記録ディスクから読
み出されてアプリケーション３２０２へと渡されるまで
に要する時間をいう。

【００１９】そこで、図３１のようなクライアント・サ
ーバ・システムに適用され、クライアント３１０１が、
ネットワークを通じてファイル・サーバ３１０２にアク
セスして、ファイル読み出し／ファイル書き込みをリア
ルタイムに行うことを可能にするようなファイルシステ
ムが望まれる。このようなファイルシステムを、リアル
タイム・リモート・ファイルシステムと呼ぶ。なお、こ
こでいうリアルタイムの定義は、後に明らかになる。リ
アルタイム・リモート・ファイルシステムを実現するの
に役立つ従来技術としては、次の２つがある。

【００２０】第１は、特開平１０−１１１７６１号公報
に開示されている帯域保証技術である。この技術は、複
数のクライアント３１０１が同時にファイル読み出し／
書き込みを実行したり、１つのクライアント３１０１が
同時に複数のファイル読み出し／書き込みを実行して
も、各クライアント用の帯域幅や、各ファイル用の帯域
幅を常に一定の大きさだけ確保する技術である。この技
術を用いれば、ファイル・サーバ３１０２からクライア
ント３１０１への送信帯域幅や、ファイル読み出し／書
き込みを行う際の送信帯域幅の低下を防ぐことができ、
その結果として、遅延時間を保証する、つまり十分高い
確率で、読み出し遅延や書き込み遅延を一定時間内に収
めることが可能となる。

【００２１】第２は、先読み技術である。先読みとは、
ファイルを構成する複数のブロックに関する読み出し順
序が予め決められているものと仮定して、アプリケーシ
ョン３２０２から先頭ブロックについての読み出し要求
を受けたとき（あるいは、読み出すべきファイルが指定
された時点で）、先頭ブロックだけでなく、そのブロッ
クに続いて読み出されるべき一定数のブロックをも予め
（つまりアプリケーション３２０２からの要求を受ける
前に）読み出すような処理をいう。先読みを行うことに
よって、アプリケーション３２０２が次のブロックに対
する要求を発した時点で、既にそのブロックが記録ディ
スクから読み出されてファイルシステム３２０１のバッ
ファに格納されているようにできるので、読み出し遅延
を隠蔽することが可能となる。このような先読みは、例
えば、特開平９−２８４３４３号公報に開示されてい
る。

【００２２】このように、図３２のリモート・ファイル
システム３２０１に、従来の帯域保証技術および先読み
技術を用いることによって、リアルタイム・リモート・
ファイルシステムが実現できると期待される。なぜな
ら、読み出し／書き込み遅延が一定の値以下に収まるこ
とが保証されるので、そこにさらに、上記の先読み技術
を用いれば、その読み出し遅延を隠蔽することが可能と
なるからである。

【００２３】

【発明が解決しようとする課題】しかしながら、上記の
ようなリアルタイム・リモート・ファイルシステムに
は、次のような問題がある。（１）帯域保証の結果として、帯域の有効利用が妨げら
れることがある。例えば、あるファイルの読み出し用と
して確保された保証帯域は、そのファイルの読み出しが
行われない期間は、空き帯域となるからである。空き帯
域の発生は、限りある帯域資源の利用効率を低下させ、
結果として、遅延時間を拡大させる。

【００２４】上記の問題を解消するには、空き帯域の有
効利用を図ればよい。例えば、あるファイルの保証帯域
内に生じた空き帯域を利用して、別のファイルのデータ
を送信するなどの方法が考えられる。（２）ところが、そうすると、上記別のファイルの送信
帯域幅が保証帯域を上回るので、読み出し遅延の隠蔽が
不十分となる恐れがある。なぜなら、従来の先読み技術
は、送信帯域幅は保証帯域幅以下であること、つまり保
証帯域の範囲内で送信が行われることを前提としている
からである。

【００２５】こうした問題点は、いずれも”帯域”に関
連しており、従って、それらが解消されたリアルタイム
・リモート・ファイルシステムを実現するには、まず初
めに、次の課題を解決する必要がある。すなわち、従来
のファイルシステムはどれも、”帯域”に関連する機能
を全く持っていない。例えば、従来のファイルシステム
に設定された保証帯域は、固定的なものであって、たと
えアプリケーションから、別の保証帯域を設定するよう
要求を受けたとしても、従来のファイルシステムは、そ
の要求を認識することすらできない。少なくとも、アプ
リケーションの要求に応じて帯域設定を行う機能が不可
欠と考えられる。

【００２６】それゆえに、本発明の目的は、帯域設定を
行えるファイルシステムを実現することである。

【００２７】また、本発明のさらなる目的は、帯域設定
機能を、帯域保証技術や先読み技術と有機的に結合させ
ることによって、リアルタイム・リモート・ファイルシ
ステムを実現することである。

【００２８】

【課題を解決するための手段および発明の効果】第１の
発明は、アプリケーションが発行するファイル読み出し
要求および／またはファイル書き込み要求を受け、ファ
イルを蓄積するデータ蓄積部に対してファイル読み出し
および／またはファイル書き込みを行うファイルシステ
ムであって、アプリケーションは、帯域設定要求をさら
に発行し、アプリケーションからのファイル読み出し要
求に応じ、データ蓄積部に対してファイル読み出しを実
行するファイル読出部、アプリケーションからのファイ
ル書き込み要求に応じ、データ蓄積部に対してファイル
書き込みを実行するファイル書込部、ファイル書き込み
の際、ファイル書込部からデータ蓄積部へのデータ送信
に使われる送信帯域幅を制御する第１の送信帯域幅制御
部、ファイル読み出しの際、データ蓄積部からファイル
読出部へのデータ送信に使われる送信帯域幅を制御する
第２の送信帯域幅制御部、およびアプリケーションから
の帯域設定要求に応じ、第１の送信帯域幅制御部および
／または第２の送信帯域幅制御部に対して帯域設定を行
う帯域設定部を備えている。

【００２９】上記第１の発明によれば、アプリケーショ
ンの要求に応じ、ファイル書き込みやファイル読み出し
用の帯域を設定できるようなフィルシステムが実現され
る。

【００３０】第２の発明は、第１の発明において、帯域
設定部は、帯域設定を行う際、標準帯域と、帯域保証の
種類とを設定し、帯域保証の種類には、標準帯域を最大
帯域として保証する最大帯域保証が含まれ、第１の送信
帯域幅制御部および／または第２の送信帯域幅制御部
は、最大帯域保証が設定された場合、たとえ空き帯域が
あっても、保証された標準帯域だけを使ってデータを送
信するような送信帯域幅制御を行うことを特徴としてい
る。

【００３１】上記第２の発明によれば、ファイル書き込
みやファイル読み出し用の帯域が保証されるので、ファ
イル読み出しや書き込みを行う際の送信帯域幅の低下を
防ぐことができ、その結果として、遅延時間を保証す
る、つまり十分高い確率を以て、読み出し遅延や書き込
み遅延を一定時間内に収めることが可能となる。

【００３２】第３の発明は、第１の発明において、帯域
保証の種類には、標準帯域を最小帯域として保証する最
小帯域保証がさらに含まれ、第１の送信帯域幅制御部お
よび／または第２の送信帯域幅制御部は、最小帯域保証
が設定された場合、もし空き帯域があれば、保証された
標準帯域だけでなく、その空き帯域も使ってデータを送
信するような送信帯域幅制御を行うことを特徴としてい
る。

【００３３】上記第３の発明では、最小帯域保証が設定
されると、最大帯域保証が設定された場合に生じる空き
帯域を使ってデータ送信が行われるので、帯域の有効利
用が可能となる。なお、ここで補足説明すれば、例えば
あるファイルに最大帯域保証が設定されると、標準帯域
が（そのファイル専用の帯域として）確保されるので、
もしそのファイルに関するデータ送信帯域幅（単位時間
に送信されるデータ量）が減少すると、標準帯域内に空
き帯域が生じる。この空き帯域が、最小帯域保証が設定
されたファイルに関するデータ送信に利用される。

【００３４】第４の発明は、第３の発明において、記帯
域保証の種類には、帯域保証を行わない帯域無保証がさ
らに含まれ、第１の送信帯域幅制御部および／または第
２の送信帯域幅制御部は、帯域無保証が設定された場
合、もし空き帯域があれば、その空き帯域を使ってデー
タを送信するような送信帯域幅制御を行うことを特徴と
している。

【００３５】上記第４の発明によれば、より柔軟な帯域
利用が可能となる。

【００３６】第５の発明は、第３の発明において、第１
の送信帯域幅制御部および／または第２の送信帯域幅制
御部は、送信帯域幅制御を行う際、最小帯域保証と対応
する各送信データに対し、標準帯域に応じて空き帯域を
分配することを特徴としている。

【００３７】上記第５の発明によれば、より効率的な帯
域利用が可能となる。

【００３８】第６の発明は、第４の発明において、第１
の送信帯域幅制御部および／または第２の送信帯域幅制
御部は、送信帯域幅制御を行う際、各送信データに対
し、均等に空き帯域を分配することを特徴としている。

【００３９】上記第６の発明によれば、空き帯域分配の
ための処理が簡単に済む。

【００４０】第７の発明は、第４の発明において、第１
の送信帯域幅制御部および／または第２の送信帯域幅制
御部は、送信帯域幅制御を行う際、帯域無保証と対応す
る送信データよりも最小帯域保証と対応する送信データ
に対して、より優先的に空き帯域を分配することを特徴
としている。

【００４１】上記第７の発明では、最小帯域保証が設定
されたファイル等に関し、遅延が生じる可能性を低くで
きる。

【００４２】第８の発明は、第４の発明において、第１
の送信帯域幅制御部および／または第２の送信帯域幅制
御部は、送信帯域幅制御を行う際に、送信バッファの状
態をも考慮することを特徴としている。

【００４３】上記第８の発明によれば、送信バッファの
不足によって空き帯域の利用効率が低下するのを防ぐこ
とができる。

【００４４】第９の発明は、第４の発明において、第１
の送信帯域幅制御部および／または第２の送信帯域幅制
御部は、送信帯域幅制御を行う際に、送信先にある受信
バッファの状態をも考慮して制御を行うことを特徴とし
ている。

【００４５】上記第９の発明によれば、受信バッファの
不足によって空き帯域の利用効率が低下するのを防ぐこ
とができる。

【００４６】第１０の発明は、第１の発明において、帯
域設定部は、さらに、ファイル読出部に対しても帯域設
定を行い、ファイル読出部は、ファイル読み出しを行う
際、アプリケーションが要求していない所定量のデータ
を先読みするための先読制御部、および先読みしたデー
タが一時記憶される先読みバッファを管理するための先
読みバッファ管理部を含み、先読制御部は、帯域設定部
によって設定される帯域に基づいて、先読みするデータ
の量を決定することを特徴としている。

【００４７】上記第１０の発明では、帯域に応じた量の
データが先読みされるので、帯域設定によって帯域が変
わっても、読み出し遅延を隠蔽することが可能になる。

【００４８】第１１の発明は、第３の発明において、帯
域設定部は、さらに、ファイル読出部に対しても帯域設
定を行い、ファイル読出部は、ファイル読み出しを行う
際、アプリケーションが要求していない所定量のデータ
を先読みするための先読制御部、および先読みしたデー
タが一時記憶される先読みバッファを管理するための先
読みバッファ管理部を含み、先読制御部は、帯域設定部
によって設定される標準帯域と、予め算定された最大遅
延時間との積に基づいて、先読みするデータの量を決定
することを特徴としている。

【００４９】上記第１１の発明によれば、（最大帯域と
して）保証された標準帯域と、最大遅延時間との積で決
まる量のデータを先読みするので、先読み遅延を高い確
率で隠蔽できる。

【００５０】第１２の発明は、第１１の発明において、
最大遅延時間は、その時間を上回るような読み出し遅延
の生じる確率が十分小さくなるように算定された時間で
あることを特徴としている。

【００５１】上記第１２の発明によれば、（最大帯域と
して）保証された標準帯域と、保証された最大遅延時間
との積で決まる量のデータを先読みするので、先読み遅
延を十分に高い確率で隠蔽できる。

【００５２】第１３の発明は、第１１の発明において、
ファイル読出部は、先読みするデータの量を制御するた
めの先読量制御部をさらに含み、先読量制御部は、最小
帯域保証が設定された場合、アプリケーションからの読
み出し要求と対応する送信帯域幅が標準帯域を超えたと
きに、先読みするデータの量を、先読制御部が決定した
量以上となるように制御することを特徴としている。

【００５３】上記第１３の発明では、最小帯域保証が設
定された場合でも、送信帯域幅の変動に、先読み量を追
従させるので、読み出し遅延を隠蔽することが可能にな
る。

【００５４】第１４の発明は、第１３の発明において、
先読みバッファ管理部は、バッファ管理部が管理する先
読みバッファの使用状況に基づいて、先読み量制御を行
うことを特徴としている。

【００５５】第１５の発明は、第１３の発明において、
先読みバッファ管理部は、先読みバッファに記憶されて
いる先読みデータの量を監視して、その監視結果を、先
読みバッファ使用量として、先読量制御部へと通知し、
先読量制御部は、通知された先読みバッファ使用量に基
づいて、先読み量制御を行うことを特徴としている。

【００５６】第１６の発明は、第１５の発明において、
先読量制御部は、通知された先読みバッファ使用量を、
予め決められたしきい値と比較して、その比較結果に関
連して、先読みするデータの量を増減させることを特徴
としている。

【００５７】上記第１４〜１６の発明では、先読みデー
タを記憶するための先読みバッファを、先読み量制御に
利用している。例えば、先読みバッファ内の先読みデー
タの量を監視する一方、先読み量増加処理を開始するし
きい値と、その処理を終了するしきい値と、先読み量減
少処理を開始するしきい値と、その処理を終了するしき
い値との、計４つのしきい値を決めておき、先読みバッ
ファ内の先読みデータ量を各しきい値と比較して、これ
から先読みするデータの量を増減させる。

【００５８】第１７の発明は、第１３の発明において、
バッファ管理部は、先読みバッファを、標準帯域と対応
する基礎領域と、当該標準帯域以外の空き帯域と対応す
る共有領域とに分けて管理することを特徴としている。

【００５９】上記第１７の発明によれば、例えば、ある
ファイルに対して最大帯域保証が設定され、別のファイ
ルに対して最小帯域保証が設定されたとき、後者のファ
イルの読み出しに空き帯域が使われて、バッファの残り
容量が少なくなり、その結果、最大帯域保証が機能しな
くなるような不都合が防がれる。

【００６０】第１８の発明は、第１７の発明において、
共有領域の大きさは、基礎領域の大きさ以上であること
を特徴としている。

【００６１】上記第１８の発明によれば、次のような不
都合が防がれる。すなわち、共有領域が基礎領域を下回
った場合、たとえ空き帯域があっても、バッファが不足
して、先読み量制御が不安定となり、その結果、空き帯
域の利用効率が低下する不都合である。

【００６２】第１９の発明は、第１７の発明において、
共有領域の大きさは、基礎領域の大きさのＮ倍（ただ
し、Ｎは２以上の任意の整数）以上であることを特徴と
している。

【００６３】上記第１９の発明によれば、最小帯域保証
が設定された（Ｎ−１）個のファイルが、同時に先読み
量減少処理中であっても、最小帯域保証が設定された他
のファイルによる空き帯域利用の効率低下を抑えること
ができる。

【００６４】第２０の発明は、第１０の発明において、
先読制御部は、ファイルの先頭とは異なる位置から読み
出しが開始される場合、先読み位置を、アプリケーショ
ンが指定した位置の前方にある、まだ先読みしていない
位置に変更して、その位置から先読みを開始することを
特徴としている。

【００６５】上記第２０の発明によれば、ファイルの途
中から読み出しを開始する際に、読み出し済みのデータ
を再度先読みする無駄がなくなる。

【００６６】第２１の発明は、第１０の発明において、
先読制御部は、ファイル内のデータを断続的に読み出す
高速再生が行われる場合、先読み位置を、アプリケーシ
ョンの要求と、ファイル内のデータ領域のサイズと、読
み出しの方向とに基づいて決定し、決定した位置から、
断続的に先読みを行うことを特徴としている。

【００６７】上記第２１の発明によれば、高速再生の際
にも、先読みを行えるようになる。

【００６８】第２２の発明は、第１０の発明において、
先読制御部は、再生の方向を順方向から逆方向へと切り
換えて、逆方向再生が行われる場合、今回読み出し要求
されたデータと、前回読み出し要求されたデータとの、
ファイル内における位置関係に基づいて、再生方向が順
方向から逆方向へ変化したことを検知し、再生方向が順
方向から逆方向へ変化したことを検知すると、先読みを
行う方向を、順方向から逆方向へと切り換えると共に、
先読み位置を、その位置から見て当該逆方向にある、ま
だ先読みしていない位置に変更して、その位置から当該
逆方向に先読みを開始することを特徴としている。

【００６９】第２３の発明は、第２２の発明において、
先読制御部は、再生の方向を順方向から逆方向へと切り
換えて、逆方向再生が行われる場合に備えて、当該逆方
向のデータを、先読みするデータの量と同量だけ保持し
ておくことを特徴としている。

【００７０】上記第２２，２３の発明によれば、逆方向
再生の際にも、先読みを行えるようになる。しかも、そ
の際に、読み出し済みのデータを再度先読みする無駄が
なくなる。

【００７１】第２４の発明は、第４の発明において、第
１の送信帯域幅制御部および／または第２の送信帯域幅
制御部は、アプリケーションが要求するデータの最小単
位と、データ蓄積部が扱うデータの最小単位とが互いに
異なる場合には、それら２つの最小単位に基づいて、実
際に必要な実帯域幅を計算し、標準域幅の代わりにその
実帯域幅を用いて、送信帯域幅制御を行うことを特徴と
している。

【００７２】上記第２４の発明によれば、もしアプリケ
ーションが要求するデータの最小単位と、データ蓄積部
が扱うデータの最小単位とが違っていても、送信帯域幅
制御を行うことが可能になる。

【００７３】第２５の発明は、第１の発明において、ア
プリケーションからのファイル読み出し要求および／ま
たはファイル書き込み要求を、ファイル読出部に適した
形式に変換する第１のＡＰＩ（アプリケーション・プロ
グラム・インターフェース；以下同様）、およびアプリ
ケーションからの帯域設定要求を、帯域設定部に応じた
形式に変換する第２のＡＰＩをさらに備えている。

【００７４】上記第２５の発明によれば、既存のファイ
ルシステムと同様のＡＰＩ（第１のＡＰＩ）を使いつ
つ、そこに帯域設定用のＡＰＩ（第２のＡＰＩ）を（拡
張ＡＰＩとして）追加するので、ファイルシステムの開
発コストを削減できる。

【００７５】第２６の発明は、第１の発明において、デ
ータ蓄積部に蓄積されているファイルを、当該フィルの
属性を示す属性情報に基づいて管理するファイル管理
部、および属性情報を管理する属性情報管理部をさらに
備えるている。

【００７６】上記第２６の発明によれば、ファイル管理
と、その属性情報の管理とが行える。

【００７７】第２７の発明は、第２６の発明において、
属性情報には、帯域設定部が行う帯域設定に関連する初
期設定情報が含まれていることを特徴としている。

【００７８】上記第２７の発明によれば、帯域設定に関
連する初期設定情報（デフォルト）を属性情報の１つと
して管理するので、帯域設定要求を発行する機能を持た
ないアプリケーションを用いた場合でも、デフォルトを
参照して送信帯域幅制御が行える。

【００７９】第２８の発明は、第１３の発明において、
データ蓄積部は、ネットワークと接続されたファイル・
サーバで実現され、ファイル読出部は、ファイル・サー
バに対し、ネットワークを通じてファイル読み出しを行
い、ファイル書込部は、ファイル・サーバに対し、ネッ
トワークを通じてファイル書き込みを行うことを特徴と
している。

【００８０】上記第２８の発明によれば、最大遅延時間
が保証される結果として、ネットワークを介したクライ
アント・サーバ・システムに適用されるリアルタイム・
リモート・ファイルシステム、すなわち、ネットワーク
を通じ、ファイル・サーバに対して読み出しや書き込み
をリアルタイムに行えるようなファイルシステムが実現
される。なお、このようなファイルシステムは、ネット
ワーク環境で用いる場合に最も効果を発揮するが、ネッ
トワークを介さない環境で用いてもよいのはいうまでも
ない。なぜなら、読み出しや書き込みの遅延は、ネット
ワーク伝送の際だけでなく、例えば、記録ディスクへの
ランダムアクセスを行う際などにも生じるからである。

【００８１】第２９の発明は、第２８の発明において、
帯域設定部は、さらに、ネットワークに対して帯域を設
定することを特徴としている。

【００８２】上記第２９の発明では、ネットワークが送
信帯域幅制御機能を持つ場合、ネットワーク帯域の制御
も可能になる。

【００８３】第３０の発明は、第２８の発明において、
帯域設定部は、ネットワークに対する帯域設定を、１つ
のファイルに対して当該ネットワーク内のコネクション
１本を割り当てるようにして行うことを特徴としてい
る。

【００８４】上記第３０の発明によれば、ファイルに対
する帯域制御が簡単に行える。

【００８５】第３１の発明は、第２８の発明において、
ネットワークに対する帯域設定を、複数のファイルに対
して当該ネットワーク内のコネクション１本を割り当て
るようにして行うことを特徴としている。

【００８６】上記第３１の発明によれば、ネットワーク
内の１本のコネクションが複数のファイルによって共有
されるので、帯域制御による効果がより顕著となる。

【００８７】第３２の発明は、第１の発明において、帯
域設定部は、ファイル毎に帯域設定を行うことを特徴と
している。

【００８８】上記第３２の発明では、ファイル毎に（つ
まり読み書きしようとするファイル１つ１つについて）
帯域設定するので、そのファイルに適した帯域が設定で
きる。

【００８９】第３３の発明は、第２６の発明において、
帯域設定部は、属性に基づいて分類されたファイル・グ
ループ毎に帯域設定を行うことを特徴としている。

【００９０】上記第３３の発明では、ファイル・グルー
プ毎に（つまり共通の属性を持つファイルを１つのグル
ープとして、それらグループ１つ１つについて）帯域設
定するので、属性に適した帯域が設定できる。簡単な例
として、”動画像”ファイルには、大きな帯域幅を設定
し、”文書”ファイルには、小さな帯域幅を設定するこ
とができる。

【００９１】第３４の発明は、第２８の発明において、
ネットワークには、当該ネットワークを通じてファイル
・サーバとの間でデータの送受信を行うクライアントが
接続され、帯域設定部は、クライアント毎に帯域設定を
行うことを特徴としている。

【００９２】上記第３４の発明によれば、クライアント
毎に（つまり、ファイル・サーバに対し、ネットワーク
を通じて読み書きするクライアント１つ１つについて）
帯域設定するので、クライアントに適した帯域が設定で
きる。簡単な例として、動画像を扱うノンリニア編集機
には、大きな帯域幅を設定し、一般端末には、小さな帯
域幅を設定することができる。

【００９３】

【発明の実施の形態】以下、本発明の実施の形態につい
て、図面を参照しながら説明する。〔リアルタイム・リモート・ファイルシステムの適用環
境〕図１は、本発明の一実施形態に係るリアルタイム・
リモート・ファイルシステムが適用されるクライアント
・サーバ・システムの構成を示すブロック図である。図
１において、クライアント・サーバ・システムは、ファ
イル・サーバ１０２と、ディレクトリ・サーバ１０３
と、複数のクライアント１０１とを備え、それらファイ
ル・サーバ１０２、ディレクトリ・サーバ１０３および
複数のクライアント１０１がネットワーク１０４を介し
て互いに接続されている。これらファイル・サーバ１０
２、ディレクトリ・サーバ１０３および各クライアント
１０１は、コンピュータ装置によって実現される。一
方、ネットワーク１０４は、図３１のネットワーク３１
０３と同様のものであり、例えば、ＡＴＭやイーサネッ
ト等の有線ネットワーク、Ｗ−ＣＤＭＡ等の無線ネット
ワークによって実現される。

【００９４】図２は、図１のファイル・サーバ１０２、
ディレクトリ・サーバ１０３および各クライアント１０
１を実現するコンピュータ装置の構成の一例を示すブロ
ック図である。図２において、コンピュータ装置は、Ｃ
ＰＵ２０１と、ＲＡＭ２０２と、プログラムメモリ２０
３と、記録ディスク２０４と、ネットワーク・インター
フェース・カード２０５とを備えている。プログラムメ
モリ２０３には、アプリケーション３０２やＯＳ（ファ
イルシステムを含む）のプログラムが格納され、ＣＰＵ
２０１は、これらプログラムに従って動作する。ＲＡＭ
２０２は、ＣＰＵ２０１が動作するのに必要なデータ類
を記憶するほか、例えば、読み出したファイル（を構成
するデータ）を一時記憶するバッファとしても利用され
る。記録ディスク２０４は、ハードディスクやコンパク
トディスクなどのようなランダムアクセス可能なディス
ク型の記録媒体であって、ファイル（以下では特に、リ
アルタイム性が要求される動画像データからなる動画像
ファイルとする）や、それら動画像ファイルの属性を示
す属性情報を記録する。ネットワーク・インターフェー
ス・カード２０５は、ネットワークへのデータ入出力を
行う（この内部に、読み出したファイルを一時記憶する
専用のバッファメモリを設けてもよい）。

【００９５】ここで、上記のプログラムメモリ２０３に
プログラムを格納する方法としては、次の３つの方法が
ある。第１は、コンピュータ装置の出荷時、予めプログ
ラムメモリ２０３にプログラムを格納しておく方法であ
る。第２は、プログラムが記録された記録媒体からその
プログラムを読み出して、プログラムメモリ２０３に格
納する方法である。第３は、ネットワークを通じて供給
されるプログラムを、プログラムメモリ２０３に格納す
る方法である。

【００９６】上記の属性情報は、ファイル名やファイル
サイズ、ディレクトリなどの従来同様の属性情報だけで
なく、読み出し／書き込み用の標準帯域や帯域保証の種
類（詳細は後述する）などの帯域に関連する属性情報を
も含む。前者の属性情報は、動画像ファイルの管理や検
索を行うために利用され、後者の属性情報は、ファイル
読み出し／書き込み用の送信帯域幅（すなわち、ファイ
ル・サーバ１０２からクライアント１０１側へ／クライ
アント１０１からファイル・サーバ１０２側へファイル
転送を行うための送信帯域幅）の制御に利用される。

【００９７】〔リアルタイム・リモート・ファイルシス
テムの構成〕図３は、本発明の一実施形態に係るリアル
タイム・リモート・ファイルシステムの構成を示すブロ
ック図である（図１のクライアント・サーバ・システム
に適用された場合）。図３において、本発明の一実施形
態に係るリアルタイム・リモート・ファイルシステム
（以下、単にファイルシステムと呼ぶ）３０１は、クラ
イアント１０１を実現するコンピュータ装置（図２参
照）上においてアプリケーション３０２が動作する環境
を用意するＯＳ３０３の一部であり、ファイル管理部３
０４と、帯域設定部３０５と、ファイル読出部３０６
と、ファイル書込部３０７とを備えている。

【００９８】ファイル読出部３０６は、先読バッファ管
理部３０８と、先読制御部３０９と、先読量制御部３１
０とを含む。ファイル書込部３０７は、送信帯域幅制御
部３１１を含む。アプリケーション３０２とＯＳ３０３
との間には、ＡＰＩ３１２および拡張ＡＰＩ３１３が設
けられる（これらＯＳ３０３およびＡＰＩ３１２は、図
３２に示されるＯＳ３２０３およびＡＰＩ３２０７と同
様のものである）。また、ファイルシステム３０１は、
ファイル・サーバ１０２に設けられる別の送信帯域幅制
御部３１４と、ディレクトリ・サーバ１０３に設けられ
る属性情報管理部３１５とをさらに備えている。これら
送信帯域幅制御部３１４および属性情報管理部３１５
は、ファイルシステム３０１の外部に図示されている
が、いずれも、ファイルシステム３０１の構成要素であ
る。

【００９９】アプリケーション３０２は、ファイル作成
やファイルの書き込み／読み出し等のファイル操作を要
求するのに加え、書き込み／読み出し用の標準帯域、お
よび帯域保証の種類を設定するよう要求する（以降、前
者の要求をファイル操作要求、後者の要求を帯域設定要
求と呼ぶ）。ＡＰＩ３１２は、アプリケーション３０２
からのファイル操作要求をＯＳ３０３に適合する形式に
変換し、拡張ＡＰＩ３１３は、アプリケーション３０２
からの帯域設定要求をＯＳ３０３に適合する形式に変換
する。拡張ＡＰＩ３１３が必要な理由は、ＡＰＩ３１２
は、帯域に関連する要求を変換する機能を持ち合わせて
いないからである。

【０１００】ＯＳ３０３は、ＡＰＩ３１２によって形式
変換されたファイル操作要求と、拡張ＡＰＩ３１３によ
って形式変換された帯域設定要求とをファイルシステム
３０１に与える。ファイルシステム３０１は、与えられ
たファイル操作要求に応じて、ファイル・サーバ１０２
の記録ディスク（図２に示される記録ディスク２０４；
以下同様）に対し、ネットワーク１０４を通じてファイ
ル操作を行い、また、与えられた帯域設定要求に応じ
て、ファイル読み出し／書き込み用の標準帯域および帯
域保証の種類の設定（以降、単に帯域設定と呼ぶ）を行
う。

【０１０１】上記のファイルシステム３０１において、
ファイル管理部３０４は、ファイルシステム３０１に与
えられたファイル操作要求の種別を判定する。その判定
の結果、要求がファイル作成要求であれば、ファイル・
サーバ１０２の記録ディスク上においてファイルを作成
すると共に、ディレクトリ・サーバ１０３の記録ディス
ク上においてそのファイルの属性情報を生成する。ディ
レクトリ・サーバ１０３内に遠隔配置された属性情報管
理部３１５は、その記録ディスクに記録されている属性
情報を管理する。

【０１０２】ファイル管理部３０４が生成し、属性情報
管理部３１５によって管理される属性情報には、ファイ
ル名やファイルサイズ、ディレクトリなどのファイル管
理・検索のための属性情報と、ファイル読み出し／書き
込み用の標準帯域や帯域保証の種類などの帯域制御のた
めの属性情報とが含まれている。後者の属性情報は、こ
こではデフォルト（初期設定値）であって、後にアプリ
ケーション３０２から帯域設定要求があり、帯域設定部
３０５によって帯域設定が行われれば、その時点でこれ
らデフォルトは無効となる（または更新される）。

【０１０３】一方、要求がファイル読み出し要求であれ
ば、ファイル管理部３０４は、ディレクトリ・サーバ１
０３から属性情報管理部３１５を通じて属性情報を読み
出してきて、それをファイル読み出し要求と共にファイ
ル読出部３０６へと与える。また、要求がファイル書き
込み要求であれば、ディレクトリ・サーバ１０３から、
属性情報管理部３１５を通じて属性情報を読み出してき
て、それをファイル書き込み要求と共にファイル書込部
３０７へと与える。

【０１０４】帯域設定部３０５は、ファイルシステム３
０１に与えられた帯域設定要求に応じて、帯域設定を行
う。ここでは、ファイル読み出し／書き込み用の帯域幅
および帯域保証の種類を設定する（あるいはディレクト
リ・サーバ１０３内のデフォルトを更新する方法もあ
る）。ファイル読出部３０６は、与えられたファイル読
み出し要求に応じ、与えられた属性情報を参照して、フ
ァイル・サーバ１０２の記録ディスクに対し、ネットワ
ーク１０４を通じてファイル読み出しを実行する。ファ
イル書込部３０７は、与えられたファイル書き込み要求
に応じ、与えられた属性情報を参照して、ファイル・サ
ーバ１０２の記録ディスクに対し、ネットワーク１０４
を通じてファイル書き込みを実行する。

【０１０５】上記のファイル読出部３０６において、先
読バッファ管理部３０８は、ファイル読出部３０６がフ
ァイル・サーバ１０２の記録ディスクから読み出してく
る先読みデータを一時記憶するためのバッファ領域（先
読みバッファ；後述）を管理しており、読み出し中、そ
のバッファ領域の使用量（先読みバッファ使用量；後
述）を監視する。先読制御部３０９は、先読み制御を行
う（すなわち、ファイル読出部３０６を制御して先読み
を行わせる）。

【０１０６】ここで先読みとは、ファイルを構成する複
数のブロックに関する読み出し順序が予め決められてお
り、かつアプリケーション３０２が各ブロックの読み出
し要求を順番に発行していくものと仮定して、アプリケ
ーション３０２から先頭ブロックについての読み出し要
求を受けたとき、ファイルシステム３０１が、先頭ブロ
ックだけでなく、それに続く一定数（ただし、この数
を、ファイルシステムが帯域に応じて指定できる点が、
従来の先読みと異なる）のブロックをも予め（つまりア
プリケーション３０２からの要求を受ける前に）読み出
して（もしくは、読み出す動作を開始して）、先読みバ
ッファに記憶しておくような処理である。その後は、ア
プリケーション３０２からの要求を受け取る毎に、先読
みバッファ内のブロックをアプリケーション３０２側の
バッファへとコピーする。それと共に、要求されたブロ
ックよりも一定数だけ時間的に前方のブロックを追加先
読みしていけば、先読みバッファには、常に一定数以上
の先読みブロックが記憶されているようになる。

【０１０７】先読量制御部３１０は、先読みすべきデー
タ量の最小値（最小先読み量；後述）を、ファイル読出
部３０６に与えられる属性情報に含まれるファイル読み
出し用の標準帯域と、図１のクライアント・サーバ・シ
ステムに固有の読み出し最大遅延時間（後述）とに基づ
いて決定する。そして、帯域保証の種類として、最小帯
域保証が設定された場合に備え、たとえ読み出し帯域幅
が標準帯域を上回っても、先読みバッファ使用量が一定
量を下回ることのないように、先読み量を制御する。

【０１０８】上記のファイル書込部３０７において、送
信帯域幅制御部３１１は、ファイル書込部３０７に与え
られた属性情報に基づいて、クライアント１０１からフ
ァイル・サーバ１０２側へのファイル転送に使われる送
信帯域幅を制御する。一方、ファイル・サーバ１０２に
備わる送信帯域幅制御部３１４は、クライアント１０１
側のファイル読出部３０６がファイル読み出しを実行す
る際に、ファイル・サーバ１０２からクライアント１０
１側へのファイル転送に使われる送信帯域幅を制御す
る。

【０１０９】〔リアルタイム・リモート・ファイルシス
テムの動作の概要〕以上のように構成されたリアルタイ
ム・リモート・ファイルシステム３０１の動作の概要に
ついて、以下に説明する。最初、アプリケーション３０
２は、ファイル操作（ここでは、ファイル作成、ファイ
ル読み出し、およびファイル書き込みのうちのいずれ
か）または帯域設定を要求する。このときアプリケーシ
ョン３０２が発するファイル作成要求、ファイル読み出
し要求、およびファイル書き込み要求には、操作の対象
となるファイルを指定するための情報（例えばファイル
名）が含まれ、帯域設定要求には、設定の対象となるフ
ァイルを指定するための情報と、標準帯域（後述）と、
帯域保証の種類（最大帯域保証、最小帯域保証、および
帯域無保証のうちのいずれか；後述）とが含まれる。

【０１１０】次に、ＡＰＩ３１２は、アプリケーション
３０２からのファイル操作要求を、ＯＳ３０３に適合す
る形式に変換し、一方、拡張ＡＰＩ３１３は、アプリケ
ーション３０２からの帯域設定要求を、ＯＳ３０３に適
合する形式に変換する。次に、ＯＳ３０３は、ＡＰＩ３
１２または拡張ＡＰＩ３１３によって形式変換された要
求を、ファイルシステム３０１へと与える。ファイルシ
ステム３０１は、与えられた要求に応じて、ファイル・
サーバ１０２に対し、ネットワーク１０４を通じてファ
イル操作を行う。また、ファイルシステム３０１内部の
ファイル書込部およびファイル読出部３０６と、ファイ
ル・サーバ１０２とに対し、（前者は直接、後者はネッ
トワーク１０４を通じて）帯域設定を行う。

【０１１１】図４は、本発明の第１の実施形態に係るリ
アルタイム・リモート・ファイルシステムが図１のクラ
イアント・サーバ・システムに適用されて、ネットワー
ク１０４を通じて（または内部的に）行う処理（ファイ
ル操作および帯域設定）を示すフローチャートである。
図４において、最初、ファイル管理部３０４は、ファイ
ルシステム３０１に要求（ここでは、ファイル作成要
求、ファイル読み出し要求、ファイル書き込み要求、お
よび帯域設定要求のいずれか）が与えられたか否かを判
定する（ステップＳ４０１）。そして、判定結果が否定
であれば待機し、肯定であれば、引き続き、その要求が
ファイル作成要求であるか否かを判定する（ステップＳ
４０２）。ステップＳ４０２の判定結果が肯定の場合、
ステップＳ４０８に進む。

【０１１２】ステップＳ４０２の判定結果が否定の場
合、ファイル管理部３０４は、ディレクトリ・サーバ１
０３から属性情報管理部３１５を通じて属性情報を読み
出し（ステップＳ４０３）、次いで、読み出した属性情
報に含まれているファイル名やディレクトリに基づい
て、ファイル・サーバ１０２において、操作または設定
の対象となるファイルを検索する（ステップＳ４０
４）。ここで検索は、ファイル・サーバ１０２の記録デ
ィスクにおいて、操作または帯域設定の対象となるファ
イルがどこに記録されているかを見いだす処理をいう。
次に、ファイル管理部３０４は、ファイルシステム３０
１に与えられた要求が帯域設定要求であるか否かを判定
する（ステップＳ４０５）。ステップＳ４０５の判定結
果が肯定の場合、ステップＳ４０９に進む。

【０１１３】ステップＳ４０５の判定結果が否定の場
合、ファイル管理部３０４は、ファイルシステム３０１
に与えられた要求がファイル書き込み要求であるか否か
を判定する（ステップＳ４０６）。ステップＳ４０６の
判定結果が肯定の場合、ステップＳ４１０に進む。

【０１１４】ステップＳ４０６の判定結果が否定の場
合、ファイル管理部３０４は、ファイル読み出し要求
と、ステップ４０４の検索結果（すなわち、読み出しの
対象となるファイルの記録場所）とを、ファイル読出部
３０６に通知し、同時に、ステップＳ４０３で読み出し
た属性情報を、ファイル・サーバ１０２に通知する。応
じて、ファイル読出部３０６は、ファイル・サーバ１０
２に対し、ネットワーク１０４を通じてファイル読み出
しを実行する（ステップＳ４０７）。このとき、ファイ
ル・サーバ１０２では、送信帯域幅制御部３１４が、与
えられた属性情報に含まれる標準帯域および帯域保証の
種類に基づいて、送信帯域幅の制御（後述）を行う。そ
の後、ステップＳ４１１へと進む。

【０１１５】このファイル読み出しの際、ファイル読出
部３０６では、先読制御部３０９が先読み制御を行い、
それによって、一定量（最小先読み量）のデータが先読
みされる。この先読みデータは、先読みバッファに一時
記憶された後、アプリケーション３０２側のバッファへ
とコピーされる。先読バッファ管理部３０８は、先読み
バッファと、そこに記憶されている先読みデータとを管
理しており、先読みバッファ使用量（後述）を、先読量
制御部３１０に通知する。先読量制御部３１０は、通知
された先読みバッファ使用量に基づいて、先読み量を制
御する。これら先読みバッファ管理処理、先読み処理お
よび先読み量制御処理については、後述する。

【０１１６】ステップＳ４０８では、ファイル管理部３
０４によってファイル（動画像ファイル）が作成され、
同時に、帯域設定部３０５によって、その動画像ファイ
ルの属性情報が生成される。このとき生成される属性情
報には、ファイル管理・検索のための属性情報（ここで
は、ファイル名、ファイルサイズ、およびディレクト
リ）と、ファイル読み出し／書き込みの際に行われる送
信帯域幅制御（ステップＳ４０７，Ｓ４０９参照）のた
めの属性情報（ここでは標準帯域、および帯域保証の種
類；いずれもデフォルト）とが含まれている。その後、
ステップＳ４１１に進む。

【０１１７】なお、ステップＳ４０８で作成された動画
像ファイルは、ファイル・サーバ１０２の記録ディスク
に記録され、生成された属性情報は、ディレクトリ・サ
ーバ１０３の記録ディスクに記録される。なお、ファイ
ル・サーバ１０２内の動画像ファイルは、ファイル管理
部３０４によって、ディレクトリ・サーバ１０３内の属
性情報は、属性情報管理部３１５によって、それぞれ管
理される。

【０１１８】ステップＳ４０９では、帯域設定部３０５
によって、帯域設定が行われる。すなわち、ファイル管
理部３０４が、アプリケーションからの帯域設定要求を
帯域設定部３０５へと通知し、応じて、帯域設定部３０
５は、標準帯域と、帯域保証の種類とを設定する。この
帯域設定処理の結果、ステップＳ４０８で予め設定され
た、ディレクトリサーバ内のデフォルトは、無効とされ
る（または、アプリケーション３０２が指定した標準帯
域および帯域保証の種類に更新される）。

【０１１９】ステップＳ４１０では、ファイル書込部３
０７によって、ファイル書き込みが行われる。すなわ
ち、ファイル管理部３０４が、ファイル書き込み要求
と、ステップ４０４の検索結果（すなわち、書き込みの
対象となるファイルの記録場所）と、ステップＳ４０３
で読み出した属性情報とを、ファイル書込部３０７に通
知し、応じて、ファイル書込部３０７は、ファイル・サ
ーバ１０２に対し、ネットワーク１０４を通じてファイ
ル書き込みを実行する。その際、ファイル書込部３０７
では、送信帯域幅制御部３１１が、与えられた属性情報
に含まれる標準帯域および帯域保証の種類に基づいて、
送信帯域幅の制御（後述）を行う。その後、ステップＳ
４１１へと進む。ステップＳ４１１では、ファイルシス
テム３０１の動作を継続するか否かが判断され、判断結
果が肯定であれば、ステップＳ４０１へと戻って、上記
と同様の処理が繰り返される。否定であれば、動作が終
了される。

【０１２０】〔標準帯域、および帯域保証の種類〕次
に、上記のステップＳ４０９で設定される標準帯域、お
よび帯域保証の種類について、詳細に説明する。図５
は、図３の帯域設定部３０５によって設定される標準帯
域および帯域保証の種類の例を示す図である。図５にお
いて、ファイルハンドルは、ファイルを特定するための
識別子である。帯域保証の種類には、最大帯域保証、最
小帯域保証、および帯域無保証の計３種類があり、各フ
ァイルに対して、それらのうちいずれかが設定される。
最大帯域保証または最小帯域保証が設定されたファイル
については、標準帯域が併せて設定される。

【０１２１】なお、本実施形態では、帯域設定は、ファ
イルに対して行っているが、ディレクトリに対して設定
してもよく、また、クライアント１０１に対して設定し
てもよい。あるいは、ネットワーク１０４を利用する各
システムに対して設定することも考えられる。

【０１２２】帯域無保証とは、ファイル読み出し／書き
込み（ステップＳ４０７，Ｓ４１０参照）を行うための
帯域を保証せず、もし帯域に空きがあれば、その空き帯
域を使ってファイル読み出し／書き込みを行うことをい
う。最小帯域保証とは、ファイル読み出し／書き込みを
行うための帯域（標準帯域）を保証し、かつ、もし帯域
に空きがあれば、さらに、その空き帯域も使ってファイ
ル読み出し／書き込みを行うような帯域保証をいう。つ
まり、最小帯域保証の場合、標準帯域が、ファイル読み
出し／書き込みに使われる帯域の最小値となる。最大帯
域無保証とは、ファイル読み出し／書き込みを行うため
の帯域（標準帯域）を保証するが、たとえ帯域に空きが
あっても、その空き帯域を使ってファイル読み出し／書
き込みを行うことはしないような帯域保証をいう。つま
り、最大帯域保証の場合、標準帯域が、ファイル読み出
し／書き込みに使われる帯域の最大値となる。

【０１２３】〔標準帯域、および帯域保証の種類に基づ
く送信帯域幅制御〕次に、上記のステップＳ４０７，Ｓ
４１０で送信帯域幅制御部３１４，３１１が行う送信帯
域幅の制御について、詳細に説明する。なお、ファイル
書込部３０７の送信帯域幅制御部１１が行う制御も、フ
ァイル・サーバ１０２の送信帯域幅制御部３１４がおこ
なう制御も、その制御原理は同じなので、ここでは、フ
ァイル・サーバ１０２の送信帯域幅制御部３１４が行う
制御（ファイルシステム３０１側から見ればファイル読
み出しを行う場合）を説明する。図６は、図３の帯域設
定部３０５によって設定される標準帯域および帯域保証
の種類の例を示す図である。図６には、（ａ）および
（ｂ）の２つの例が示されている。

【０１２４】図６（ａ）では、４つのファイル（ファイ
ルハンドル”１”〜”４”）に関し、標準帯域および帯
域保証の種類が設定されている。ファイルハンドル”
１”〜”３”に対しては最大帯域保証が、”４”に対し
ては無保証型がそれぞれ設定されている。標準帯域は、
ファイルハンドル”１”〜”２”がそれぞれ６０Ｍｂｐ
ｓ、”３”が３０Ｍｂｐｓである。一方、（ｂ）では、
ファイルハンドル”１”〜”３”に対しては最小帯域保
証が、”４”に対しては無保証型がそれぞれ設定されて
いる。標準帯域は、（ａ）と同様、ファイルハンドル”
１”〜”２”がそれぞれ６０Ｍｂｐｓ、”３”が３０Ｍ
ｂｐｓである。

【０１２５】図７は、図３の送信帯域幅制御部３１４
が、図６のように設置された標準帯域、および帯域保証
の種類に基づいて行う送信帯域幅制御を、直感的に説明
するための図である。図７において、Ｔｓｌｔ（タイム
スロット）は、要求を処理する周期に相当する単位時間
であり、Ｎｍａｘは、１つのＴｓｌｔあたりに処理可能
な要求の個数の最大値である。図中の○は、１つのブロ
ックに対する読み出し要求（以下、単に要求と呼ぶ）を
示し、〜がそれぞれ、図６のファイルハンドル”
１”〜”４”と対応している。ここでは、Ｎｍａｘ＝５
とし、また、１つのＴｓｌｔあたりに１個の要求（○）
を処理したときの送信帯域幅を３０Ｍｂｐｓとする。つ
まり、送信帯域幅制御部３１４では、１つのＴｓｌｔあ
たり最大で５個の要求が処理され、その最大送信帯域幅
は、３０＊５＝１５０Ｍｂｐｓとなる。

【０１２６】いま、送信帯域幅制御部３１４において、
が４個、が１２個、が７個、が２個の計２５個
の要求が処理待ち状態にあるとすると（実際には、次々
に新たな要求が送られてくるので、処理待ち要求の個数
は刻々変化する）、送信帯域幅制御部３１４は、帯域設
定部３０５によって設定された標準帯域、および帯域保
証の種類に基づいて、これら２５個の要求を、Ｔｓｌｔ
（１），Ｔｓｌｔ（２），…，Ｔｓｌｔ（５）へと順番
に充填していく。

【０１２７】図７（ａ）には、標準帯域、および帯域保
証の種類が図６（ａ）のように設定されている場合に、
要求〜を各Ｔｓｌｔへどのような内訳で充填するか
が示されている。〜は、最大帯域保証が設定された
ファイルと対応し、そのファイルに設定された標準帯域
に相当する個数だけ、優先的にＴｓｌｔへと充填される
が、たとえＴｓｌｔに空き帯域があっても、そこに追加
充填されることはない。は、帯域無保証が設定された
ファイルと対応し、もしＴｓｌｔに空き帯域があれば、
そこに充填される。

【０１２８】図７（ａ）において、最初、送信帯域幅制
御部３１４は、Ｔｓｌｔ（１）へ、を２個、を２
個、を１個の計５個を充填し、次に、Ｔｓｌｔ（２）
へ、を２個、を２個、を１個の計５個を充填す
る。この時点で、未充填のがなくなるので、Ｔｓｌｔ
（３）〜Ｔｓｌｔ（５）では、各々要求２個分の空き帯
域が生じることになる。次に、送信帯域幅制御部３１４
は、Ｔｓｌｔ（３）へ、を２個、を１個充填し、こ
のとき生じた２個分の空き帯域には、を２個充填す
る。この時点で、未充填のがなくなる。

【０１２９】次に、送信帯域幅制御部３１４は、Ｔｓｌ
ｔ（４）へ、を２個、を１個充填する。このとき生
じた２個分の空き帯域には、どの要求も充填されない。
次に、送信帯域幅制御部３１４は、Ｔｓｌｔ（５）へ、
を２個、を１個充填する。このとき生じた２個分の
空き帯域には、どの要求も充填されない。この時点で、
未充填の，が各々２個ある。これら合計４個の要求
は、Ｔｓｌｔ（５）に続く図示しないＴｓｌｔ（６），
Ｔｓｌｔ（７）…へと充填されることになる。

【０１３０】一方、図７（ｂ）には、標準帯域、および
帯域保証の種類が図６（ｂ）のように設定されている場
合に、要求〜を各Ｔｓｌｔへどのような内訳で充填
するかが示されている。〜は、最小帯域保証が設定
されたファイルと対応し、そのファイルに設定された標
準帯域に相当する個数だけ、優先的にＴｓｌｔへと充填
され、かつ、もしＴｓｌｔに空き帯域があれば、そこに
追加充填される。は、帯域無保証が設定されたファイ
ルと対応し、もしＴｓｌｔに空き帯域があれば、そこに
充填される。

【０１３１】図７（ｂ）において、最初、送信帯域幅制
御部３１４は、Ｔｓｌｔ（１）へ、を２個、を２
個、を１個の計５個を充填し、次に、Ｔｓｌｔ（２）
へ、を２個、を２個、を１個の計５個を充填す
る。この時点で、未充填のがなくなるので、Ｔｓｌｔ
（３）〜Ｔｓｌｔ（５）では、各々要求２個分の空き帯
域が生じることになる。

【０１３２】次に、送信帯域幅制御部３１４は、Ｔｓｌ
ｔ（３）へ、を２個、を１個充填し、このとき生じ
た２個分の空き帯域には、，を各１個充填する。次
に、送信帯域幅制御部３１４は、Ｔｓｌｔ（４）へ、
を２個、を１個充填し、このとき生じた２個分の空き
帯域には、，を各１個充填する。次に、送信帯域幅
制御部３１４は、Ｔｓｌｔ（５）へ、を２個、を１
個充填し、このとき生じた２個分の空き帯域には、，
を各１個充填する。この時点で、全ての要求の充填が
完了する。

【０１３３】図７（ａ），図７（ｂ）を互いに比較すれ
ばわかるように、ファイルシステム３０１がファイル読
み出し（あるいはファイル書き込み）を行う際の帯域保
証として最小帯域保証を用いることによって、最大帯域
保証を用いた場合に存在していた空き帯域の有効利用が
図れるようになる。なお、ここで補足しておけば、本願
の帯域保証（最大，最小共）は、保証される標準帯域
が、アプリケーションの要求（帯域設定要求）に応じて
任意に設定される点が、従来の帯域保証と異なる。つま
り、従来の帯域保証では、保証される帯域は固定であっ
たのに対し、本願の帯域保証では、保証される帯域（標
準帯域）は、必要に応じて変更設定できる。

【０１３４】なお、ここでは、帯域無保証および最大帯
域保証を用いた場合について、帯域無保証および最大帯
域保証を用いた場合と比較しながら説明したが、最大帯
域保証および最小帯域保証を用いても、あるいは、帯域
無保証、最大帯域保証および最小帯域保証を全て用いて
も、空き帯域の有効利用が図れることに変わりはない。

【０１３５】また、図７（ｂ）の例では、送信帯域幅制
御部３１４は、Ｔｓｌｔ（３）〜Ｔｓｌｔ（５）におい
て生じた空き帯域に、それぞれと、と、と
を充填した。つまり、空き帯域を、帯域無保証または最
小帯域保証が設定された各ファイルに対して、帯域無保
証か最小帯域保証かに関わらず、また標準帯域とも無関
係に、均等に分配したが、代わりに、空き帯域を、帯域
無保証が設定されたファイルよりも、最小帯域保証か設
定されたファイルに対して、より優先的して分配するよ
うにしてもよい。

【０１３６】または、帯域保証の種類として最小帯域保
証が設定されたファイルが複数ある場合、空き帯域を、
各々に設定された標準帯域に応じた比率で分配してもよ
い。または、各ファイルの読み出し状況や書き込み状況
に基づいて分配比率を決定し、空き帯域を、その分配比
率に従って分配してもよい。

【０１３７】さらには、ブロックを送信する先（ファイ
ル・サーバ１０２の送信帯域幅制御部３１４から見れば
ファイル読出部３０６が、ファイル書込部３０７の送信
帯域幅制御部３１１から見ればファイル・サーバ１０２
が、各々ここでいう送信先である）には、それらブロッ
クを一時記憶するバッファがファイル毎に設けられる
が、これらバッファの空き領域に応じて、空き帯域を分
配してもよい。例えば、各ファイルについて、バッファ
の空き領域に関するしきい値を決めておき、あるファイ
ル用のバッファの空き領域がそのしきい値以下の期間
は、そのファイルへの分配を行わない（または分配量を
減らす）といった方法が考えられる。

【０１３８】また、ここでは、送信帯域幅制御部３１４
は、帯域設定部３０５が設定した標準帯域をそのまま用
いて送信帯域幅制御を行っているが、その標準帯域をも
とに実際に必要な帯域を計算し、それにより得られた実
帯域を用いて、送信帯域幅制御を行うようにしてもよ
い。このような実帯域計算が必要となるのは、例えば、
ファイル読み出しを行う際に、アプリケーション３０２
が要求するブロック（読み出し最小単位）のサイズと、
ファイル・サーバ１０２で扱われるブロックのサイズと
が互いに異なるような場合である。その一例が、図８に
示されている。

【０１３９】すなわち、図８は、アプリケーション３０
２が要求するブロックと、ファイル・サーバ１０２の記
録ディスク上に記録されているブロックとの、サイズの
違いを示した図である。図８に示すように、ファイル・
サーバ１０２で扱われるブロックのサイズが１２８ＫＢ
（＝１３１０７２バイト）であるにもかかわらず、アプ
リケーション３０２は、サイズ１２００００バイトのブ
ロックを１２００００バイトおきに要求することがあ
る。このような場合、ファイル・サーバ１０２の送信帯
域幅制御部３１４は、１２００００バイト分のデータ要
求に対して、要求されていない１１０７２バイトをも含
む１３１０７２バイト分のデータを送信することが好ま
しいことがある。そのように送信したときの実帯域は、
標準帯域に（１３１０７２／１２００００）を乗じた値
となる。例えば、標準帯域が６０Ｍｂｐｓの場合、実帯
域は、６５．５Ｍｂｐｓと計算される。

【０１４０】また、次のような場合には、別の実帯域計
算が必要となる。図８と同様、ファイル・サーバ１０２
で扱われるブロックのサイズが１２８ＫＢ（＝１３１０
７２バイト）である一方、アプリケーション３０２が要
求するブロックのサイズが１２００００バイトである場
合、アプリケーション３０２は、ファイル読み出しを行
う際に、ブロックを（例えば１ブロック跳ばしに）断続
的に要求することがある。その一例が、図９に示されて
いる。

【０１４１】すなわち、図９は、ファイル・サーバ１０
２の記録ディスク上に１２８ＫＢ（＝１３１０７２バイ
ト）のブロックが連続的に記録されているとき、アプリ
ケーション３０２が１ブロック跳ばしに（つまり１２０
０００バイトおきに）断続的に要求する様子を示す図で
ある。図９に示すような場合、アプリケーション３０２
の要求が１ブロック（＝１２００００バイト）跳ばしで
あっても、ファイル・サーバ１０２の送信帯域幅制御部
３１４は、ほとんど全てのブロック（１ブロック＝１３
１０７２バイト）を送信することになるので、実帯域
は、標準帯域の２倍となることがわかる。例えば、標準
帯域が６０Ｍｂｐｓの場合、実帯域は、１２０Ｍｂｐｓ
と計算される。より一般的には、実帯域は、標準帯域
と、アプリケーション３０２が読み出そうとするブロッ
クが記録ディスク上のどこにあるかを示す位置情報とか
ら計算することができる。

【０１４２】〔先読み制御処理〕次に、上記のステップ
Ｓ４０７のファイル読み出しの際に行われる先読み制御
処理について、詳細に説明するが、ここで予め、その概
略を説明しておく。前述のように、ファイル読出部３０
６において、先読バッファ管理部３０８は、ファイル読
出部３０６がファイル・サーバ１０２の記録ディスクか
ら読み出してくる先読みデータを一時記憶するための先
読みバッファを管理すると共に、読み出し中、その先読
みバッファの使用量を監視している。

【０１４３】ファイル読出部３０６がファイル読み出し
要求を受け取ると、先読制御部３０９は、最初、帯域設
定部３０５によって設定された標準帯域、またはディレ
クトリ・サーバ１０３の属性情報に含まれる標準帯域
（これはデフォルト）と、図１のクライアント・サーバ
・システムに固有の最大遅延時間（定数）とに基づい
て、最小先読み数（最小先読み量でもよい）を算出し、
次に、算出した最小先読み数と等しい数のブロックを先
読みする（これを初期先読みと呼ぶ）。こうして先読み
されたブロックは、先読みバッファに一時記憶される。

【０１４４】その後、アプリケーション３０２は、一連
のブロック読み出し要求の発行を開始する。応じて、先
読みバッファ内の先読みブロックは、先頭ブロックから
順番に、アプリケーション３０２側のバッファへとコピ
ーされていく。その結果として、先読み量がだんだん減
っていくことになる。このとき、先読バッファ管理部３
０８によって先読み量が監視されており、先読み量が最
小先読み量よりも少なくなると、先読制御部３０９は、
先読み量が最小先読み量に等しくなるように、再び先読
みを実行する（これを追加先読みと呼ぶ）。こうして、
先読みバッファ使用量が、最小先読み量に等しく保たれ
る。

【０１４５】ここで、上記の先読みを、従来の先読みと
比較しておく。従来の先読みでは、常に一定数のブロッ
クが先読みされる（つまり先読み量が一定である）。例
えば、特開平９−２８４３４３号公報では、再送制御を
行うために、ネットワークを往復するのにかかる時間と
対応する量を先読みしている。これに対し、本願の先読
みでは、アプリケーション３０２が任意に設定する標準
帯域と、図１のクライアント・サーバ・システムに固有
の最大遅延時間（定数）とから最小先読み数（最小先読
み量でもよい）を算出して、その最小先読み数と等しい
数のブロックを先読みしている。標準帯域に応じた先読
みを行うためであり、また、遅延は、ネットワーク伝送
時だけでなく、例えば、ファイル・サーバ１０２におい
て記録ディスクへのアクセスを行う際にも生じる（しか
も、記録ディスクへのアクセスの際の遅延は、その大き
さが不定である）からである。

【０１４６】なお、最大遅延時間は、上記のように一定
値とせず、標準帯域に応じて変えてもよい。それによっ
て、より一層、帯域の有効利用が図れるようになる。

【０１４７】上記のような先読み制御の詳細を、以下に
説明する。なお、ここでは、後述する先読み量制御は行
われず、先読み制御だけが行われるものとする。最初、
先読制御部３０９が算出する最小先読み数（最小先読み
量）について説明する。先読制御部３０９は、次式
（１）を用いて、最小先読み数（Ｎ＿ＲＡ）を算出す
る。（Ｎ＿ＲＡ）＝［（Ｂ＿Ａｓｓｕｒｅ）＊（Ｔ＿ＭＲＴＤ）／（Ｄ＿Ｕｎｉｔ）］…（１）上式（１）において、”＊”は乗算、”／”は除算を意
味し、［ｘ］は、ｘを下回らない最小の整数を表す。
（Ｔ＿ＭＲＴＤ）は、図１のクライアント・サーバ・シ
ステムに固有の最大遅延時間（定数）である。また、
（Ｂ＿Ａｓｓｕｒｅ）は、読み出し対象のファイルに対
して設定された標準帯域、（Ｄ＿Ｕｎｉｔ）は、そのフ
ァイルを構成するブロックのサイズである。これらは、
下式（２）においても同様である。

【０１４８】または、先読制御部３０９は、次式（２）
を用いて、最小先読み量（Ｄ＿ＲＡ）を算出する。（Ｄ＿ＲＡ）＝（Ｎ＿ＲＡ）＊（Ｄ＿Ｕｎｉｔ）＝［（Ｂ＿Ａｓｓｕｒｅ）＊（Ｔ＿ＭＲＴＤ）／（Ｄ＿Ｕｎｉｔ）］＊（Ｄ＿Ｕｎｉｔ）…（２）すなわち、（Ｄ＿ＲＡ）は、（Ｂ＿Ａｓｓｕｒｅ）＊
（Ｔ＿ＭＲＴＤ）を（Ｄ＿Ｕｎｉｔ）で規格化すること
により得られる。

【０１４９】最大遅延時間（Ｔ＿ＭＲＴＤ）は、実験に
よって求めることができる。すなわち、図１のクライア
ント・サーバ・システムにおいて生じる読み出し遅延時
間を実際に何度も計測する。そして、それら計測結果か
ら、実際に生じる遅延時間がそれを上回る確率が十分に
小さくなるような遅延時間を算出し、それを図１のクラ
イアント・サーバ・システムに固有の最大遅延時間と定
義する。このとき、実際に生じる時間が最大遅延時間を
上回る確率は、１０^-12未満であるのが好ましい。また
は、ネットワーク１０４やファイル・サーバ１０２の仕
様から、最大遅延時間（Ｔ＿ＭＲＴＤ）を決定すること
もできる。

【０１５０】標準帯域（Ｂ＿Ａｓｓｕｒｅ）は、アプリ
ケーション３０２からの帯域設定要求に応じて帯域設定
部３０５が設定したものを用いるか、または、ディレク
トリ・サーバ１０３に記録された属性情報に含まれてい
るデフォルトを用いる。

【０１５１】こうして最小先読み数を算出すると、先読
制御部３０９は、その最小先読み数に等しい数のブロッ
クを読み出す初期先読みを開始する。その後、アプリケ
ーション３０２は、ブロック読み出し要求の発行を開始
する。応じて、ファイル読出部３０６では、次のような
処理が行われる。

【０１５２】図１０は、図３のファイル読出部３０６
が、アプリケーション３０２からのブロック読み出し要
求に応じて行うブロック読み出し処理を示すフローチャ
ートである。なお、ここでは、アプリケーションが要求
するブロックのサイズと、ファイル・サーバ１０２が扱
えるブロックのサイズが同じと仮定して説明する（サイ
ズが異なる場合の処理については後述）。図１０におい
て、ブロック読み出し要求が送られてくると、ファイル
読出部３０６は、その要求の対象であるブロック（以
下、要求ブロック）が、先読制御部３０９による初期先
読み処理の対象となった一連のブロック（以下、先読み
ブロック；このような先読みブロックは、上記の最小先
読み数に等しい個数だけ存在する）のうちの先頭のブロ
ックと同一のものであるか否かを判定する（ステップＳ
１００１）。その判定結果が否定の場合、ステップＳ１
００６に進む。

【０１５３】ステップＳ１００１の判定結果が肯定の場
合、ファイル読出部３０６は、要求ブロックが、先読み
バッファに到着済みであるか否かを判定する（ステップ
Ｓ１００２）。その判定結果が否定の場合、イベント待
ちに入る。ステップＳ１００２の判定結果が肯定の場
合、ファイル読出部３０６は、アプリケーション３０２
への応答を実行する（ステップＳ１００３）。つまり、
先読みバッファに記憶されている要求ブロックを、アプ
リケーション３０２側のバッファへとコピーする。

【０１５４】次に、ファイル読出部３０６は、先読みバ
ッファの不要領域、つまりステップＳ１００３で応答済
みのブロックが格納されている領域を開放する（ステッ
プＳ１００４）。そして、追加先読みが行われ（ステッ
プＳ１００５）、その後、イベント待ちに入る。ステッ
プＳ１００６では、読み出しジャンプ処理が行われ、そ
の後、イベント待ちに入る。

【０１５５】図１１は、図１０のステップＳ１００５の
追加先読み処理を示すフローチャートである。図１１に
おいて、先読制御部３０９は、最初、追加先読みを実行
する必要があるか否かを判断する（ステップＳ１１０
１）。その判定結果が否定であれば、処理完了となり、
肯定であれば、先読制御部３０９が、追加先読みを実行
する（ステップＳ１１０２）。なお、追加先読みを実行
する必要があるか否かは、先読み量（あるいは先読みブ
ロック数）を、最小先読み量（あるいは最小先読み数）
と比較することによって判断できる。先読みブロックの
数が最小先読み数より少なければ、追加先読みを実行
し、多ければ、処理完了となる。

【０１５６】図１２は、図１０のステップＳ１００６の
読み出しジャンプ処理を示すフローチャートである。図
１２において、ファイル読出部３０６は、最初、要求ブ
ロックが先読みブロックか否か、つまり、先読みしてい
る一連のブロックのいずれかと同一のブロックが要求さ
れているか否かを判断する（ステップＳ１２０１）。そ
の判断結果が否定の場合、実行中の先読みが中断され
（ステップＳ１２０４）、その後、ステップＳ１２０２
に進む。ステップＳ１２０１の判断結果が肯定の場合、
先読み位置を、ジャンプ先の前方にある、まだ先読みし
ていない位置に変更する（ステップＳ１２０２）。次い
で、追加先読みが実行され（ステップＳ１２０３）、そ
の後、処理終了となる。

【０１５７】要するに、要求ブロックが、たとえ一連の
先読みブロックの先頭のものでなくても（ステップＳ１
００１を参照）、それら一連の先読みブロックのいずれ
かであるならば（ステップＳ１２０１を参照）、いま行
っている先読みを中断しなくてもよい。この点に着目
し、上記の読み出しジャンプ処理では、読み出し処理の
中断の頻度を減らしている。それによって、帯域の有効
利用と、応答性の向上とが図れるからである。

【０１５８】図１３は、図３のファイル読出部３０６
が、読み出したブロック（以下、受信ブロック）を先読
みバッファに格納する処理を示すフローチャートであ
る。図１３において、最初、ファイル読出部３０６は、
受信ブロックが廃棄すべきものか否かを判断する（ステ
ップＳ１３０１）。廃棄すべきブロックとしては、先読
みされたにも関わらず、ジャンプ読み出しが行われたた
め不要となったブロックや、先読み量の減少（先読み量
の増減については、後述する先読み量制御処理を参照）
に伴い不要となったブロックなどがある。

【０１５９】ステップＳ１３０１の判断の結果が肯定の
場合、ファイル読出部３０６は、受信ブロックを破棄し
（ステップＳ１３０７）、その後、イベント待ちに入
る。一方、否定の場合、受信ブロックを先読みバッファ
に格納する（ステップＳ１３０２）。次に、ファイル読
出部３０６は、受信ブロックが要求ブロックであるか否
かを判断する（ステップＳ１３０３）。その判断結果が
否定の場合、イベント待ちに入る。ステップＳ１３０３
の判断の結果が肯定の場合は、ファイル読出部３０６
は、アプリケーション３０２への応答を実行し（ステッ
プＳ１３０４）、次いで、不要バッファを開放する（ス
テップＳ１３０５）。次に、先読制御部３０９が追加先
読みを行い（ステップＳ１３０６）、その後、イベント
待ちに入る。

【０１６０】図１４は、図１３のステップＳ１３０２の
受信ブロック格納処理を示すフローチャートである。図
１４において、ファイル読出部３０６は、受信ブロック
を先読みバッファに格納し、併せて、その格納位置（バ
ッファ内のどの位置にそのブロックを格納したか）を登
録する（ステップＳ１４０１）。その後、処理終了とな
る。

【０１６１】〔先読み量制御処理〕次に、上記のステッ
プＳ４０７のファイル読み出しの際に行われる先読み量
制御処理について、詳細に説明するが、ここで予め、そ
の概略を説明しておく。先読制御部３０９が上記のよう
な先読み制御処理を行うことによって、送信帯域幅が常
に標準帯域以下であれば（つまり、帯域保証の種類とし
て最大帯域保証が設定されていれば）、先読み量は、最
小先読み量と等しく保たれれば十分である。ところが、
帯域保証の種類として最小帯域保証が設定されている
と、送信帯域幅が標準帯域を超えることがあるので、先
読み量が最小先読み量と等しく保たれるだけでは十分で
ない。そこで、先読量制御部３１０は、最小帯域保証が
設定された場合、送信帯域幅が標準帯域を超えると、先
読み量を、最小先読み量以上に制御する。それによっ
て、空き帯域を十分に利用できるようになる。この先読
み量制御の原理を、図１５を用いて説明する。

【０１６２】すなわち、図１５は、図３の先読量制御部
３１０が行う先読み量制御の原理を、直感的に説明する
ための図である。図１５において、先読み量制御では、
バッファ使用量に関する４個のしきい値Ａ〜Ｄ（ただ
し、Ａ＜Ｂ＜Ｃ＜Ｄ）を決めておく。Ａは、先読み量増
加処理を開始するか否かの判定基準となる第１のしきい
値、Ｂは、先読み量増加処理を停止するか否かの判定基
準となる第２のしきい値、Ｃは、先読み量減少処理を開
始するか否かの判定基準となる第３のしきい値、Ｄは、
先読み量減少処理を開始するか否かの判定基準となる第
４のしきい値である。一方、先読バッファ管理部３０８
は、先読みバッファ使用量を監視しており、監視結果を
随時、先読量制御部３１０に通知する。ここで先読みバ
ッファ使用量とは、先読みバッファに記憶されている先
読みブロックの数、より正確には、先読みバッファに記
憶されている先読みブロックのうち、まだアプリケーシ
ョン３０２側のバッファへとコピーされていないブロッ
クの数（あるいはデータ量）をいう。

【０１６３】先読量制御部３１０は、通知された先読み
バッファ使用量を、各しきい値Ａ〜Ｄと比較し、比較結
果に応じて、先読み量増加処理を開始／停止させ、かつ
先読み量減少処理を開始／停止させることによって、先
読み量を一定範囲内で変動させる。このとき、しきい値
Ａ〜Ｄが適切に決められていれば、先読み量の変動範囲
は、その下限が上記の最小先読み量であり、かつ上限が
先読みバッファの最大容量であるような範囲となる。そ
して、しきい値Ａ〜Ｄは、実験によって、あるいはネッ
トワーク１０４やファイル・サーバ１０２の仕様から、
適切に決めることができる。

【０１６４】上記のような先読み量制御処理の詳細を、
以下に説明する。なお、ここでは、前述の先読み制御に
加えて、さらに先読み量制御が行われるものする。図１
６は、図３のファイル読出部３０６が、アプリケーショ
ン３０２からのブロック読み出し要求に応じて行うブロ
ック読み出し処理を示すフローチャートである。なお、
図１６の処理は、図１０の処理に、ステップＳ１６０１
〜Ｓ１６０３を追加したものである。図１６において、
ブロック読み出し要求が送られてくると、ファイル読出
部３０６は、要求ブロックが、一連の先読みブロックの
うち先頭のブロックと同一のものであるか否かを判定す
る（ステップＳ１００１）。その判定結果が否定の場
合、ステップＳ１００６に進む。

【０１６５】ステップＳ１００１の判定結果が肯定の場
合、ファイル読出部３０６は、要求ブロックが、先読み
バッファに到着済みであるか否かを判定する（ステップ
Ｓ１００２）。その判定結果が否定の場合、先読量制御
部３１０が、先読み量増加処理開始判定を行い（ステッ
プＳ１６０３）、その後、イベント待ちに入る。ステッ
プＳ１００２の判定結果が肯定の場合、ファイル読出部
３０６は、アプリケーション３０２への応答を実行する
（ステップＳ１００３）。

【０１６６】次に、ファイル読出部３０６は、先読みバ
ッファの不要領域を開放する（ステップＳ１００４）。
次に、先読量制御部３１０が、先読み量減少処理停止判
定を行い（ステップＳ１６０３）、次いで、先読み量増
加処理停止判定を行う（ステップＳ１６０３）。そし
て、追加先読みが行われ（ステップＳ１００５）、その
後、イベント待ちに入る。ステップＳ１００６では、読
み出しジャンプ処理が行われ、その後、イベント待ちに
入る。

【０１６７】図１７は、図３のファイル読出部３０６
が、受信ブロックを先読みバッファに格納する処理を示
すフローチャートである。なお、図１７の処理は、図１
３の処理に、ステップＳ１７０１〜Ｓ１７０３を追加し
たものである。図１７において、最初、ファイル読出部
３０６は、受信ブロックが廃棄すべきものか否かを判断
する（ステップＳ１３０１）。ステップＳ１３０１の判
断の結果が肯定の場合、ファイル読出部３０６は、受信
ブロックを破棄し（ステップＳ１３０７）、その後、イ
ベント待ちに入る。一方、否定の場合、受信ブロックを
先読みバッファに格納する（ステップＳ１３０２）。

【０１６８】次に、ファイル読出部３０６は、受信ブロ
ックが要求ブロックであるか否かを判断する（ステップ
Ｓ１３０３）。その判断結果が否定の場合、先読量制御
部３１０が、先読み量減少処理開始判定を行い（ステッ
プＳ１７０３）、その後、イベント待ちに入る。ステッ
プＳ１３０３の判断の結果が肯定の場合は、ファイル読
出部３０６は、アプリケーション３０２への応答を実行
し（ステップＳ１３０４）、次いで、不要バッファを開
放する（ステップＳ１３０５）。次に、先読量制御部３
１０が、先読み量減少処理停止判定を行い（ステップＳ
１７０１）、次いで、先読み量増加処理停止判定を行う
（ステップＳ１７０２）。そして、先読制御部３０９が
追加先読みを行い（ステップＳ１３０６）、その後、イ
ベント待ちに入る。

【０１６９】図１８は、図１６のステップＳ１６０１の
先読み量減少処理停止判定を示すフローチャートであ
る。図１８において、先読量制御部３１０は、最初、先
読み量減少処理が実行中か否かを判定する（ステップＳ
１８０１）。その判定結果が肯定の場合、処理終了とな
る。ステップＳ１８０１の判定結果が否定の場合、先読
量制御部３１０は、先読みバッファ使用量がしきい値Ｃ
以下であるか否かを判定する（ステップＳ１８０２）。
その判定結果が否定の場合、処理終了となる。ステップ
Ｓ１８０２の判定結果が肯定の場合、先読量制御部３１
０は、先読み量減少処理を停止し（ステップＳ１８０
３）、その後、処理終了となる。

【０１７０】図１９は、図１６のステップＳ１６０２の
先読み量増加処理停止判定を示すフローチャートであ
る。図１９において、先読量制御部３１０は、最初、先
読み量増加処理が実行中か否かを判定する（ステップＳ
１９０１）。その判定結果が肯定の場合、処理終了とな
る。ステップＳ１９０１の判定結果が否定の場合、先読
量制御部３１０は、先読みバッファ使用量がしきい値Ｂ
以上であるか否かを判定する（ステップＳ１９０２）。
その判定結果が否定の場合、処理終了となる。ステップ
Ｓ１９０２の判定結果が肯定の場合、先読量制御部３１
０は、先読み量増加処理を停止し（ステップＳ１９０
３）、その後、処理終了となる。

【０１７１】図２０は、図１６のステップＳ１６０３の
先読み量増加処理開始判定を示すフローチャートであ
る。図２０において、先読量制御部３１０は、最初、先
読み量増加処理が実行中か否かを判定する（ステップＳ
２００１）。その判定結果が肯定の場合、処理終了とな
る。ステップＳ２００１の判定結果が否定の場合、先読
量制御部３１０は、先読みバッファ使用量がしきい値Ａ
以下であるか否かを判定する（ステップＳ２００２）。
その判定結果が否定の場合、処理終了となる。

【０１７２】ステップＳ２００２の判定結果が肯定の場
合、先読量制御部３１０は、先読み量減少処理が実行中
か否かを判定する（ステップＳ２００３）。その判定結
果が否定の場合、ステップＳ２００５に進む。ステップ
Ｓ２００３の判定結果が肯定の場合、先読量制御部３１
０は、先読み量減少処理を停止し（ステップＳ２００
４）、その後、ステップＳ２００５に進む。ステップＳ
２００５では、先読み量増加処理が開始される。その
後、処理終了となる。

【０１７３】図１７のステップＳ１７０１の先読み量減
少処理停止判定は、図１６のステップＳ１６０１と同様
なので、図１８のフローチャートを援用し、説明を省略
する。図１７のステップＳ１７０２の先読み量増加処理
停止判定は、図１６のステップＳ１６０２と同様なの
で、図１９のフローチャートを援用し、説明を省略す
る。

【０１７４】図２１は、図１７のステップＳ１７０３の
先読み量増加処理開始判定を示すフローチャートであ
る。図２１において、先読量制御部３１０は、最初、先
読み量減少処理が実行中か否かを判定する（ステップＳ
２１０１）。その判定結果が肯定の場合、処理終了とな
る。ステップＳ２１０１の判定結果が否定の場合、先読
量制御部３１０は、先読みバッファ使用量がしきい値Ｄ
以上であるか否かを判定する（ステップＳ２１０２）。
その判定結果が否定の場合、処理終了となる。

【０１７５】ステップＳ２１０２の判定結果が肯定の場
合、先読量制御部３１０は、先読み量増加処理が実行中
か否かを判定する（ステップＳ２１０３）。その判定結
果が否定の場合、ステップＳ２１０５に進む。ステップ
Ｓ２１０３の判定結果が肯定の場合、先読量制御部３１
０は、先読み量増加処理を停止し（ステップＳ２１０
４）、その後、ステップＳ２１０５に進む。ステップＳ
２１０５では、先読み量減少処理が開始される。その
後、処理終了となる。

【０１７６】図２２，図２３はそれぞれ、図３の先読量
制御部３１０が行う先読み量増加処理を示すフローチャ
ートである。図２２において、先読量制御部３１０は、
最初、先読みバッファ使用量がしきい値Ａ以下であるか
否かを判定する（ステップＳ２２０１）。その判定結果
が否定の場合、ステップＳ２２０３に進む。ステップＳ
２２０１の判定結果が肯定の場合、先読量制御部３１０
は、先読み量の増加を実行し（ステップＳ２２０２）、
その後、ステップＳ２２０３に進む。

【０１７７】ステップＳ２２０３では、先読み量増加処
理を停止するか否かが判断され（ステップＳ２２０
３）、その判定結果が肯定の場合、処理終了となる。ス
テップＳ２２０３の判定結果が否定の場合、先読量制御
部３１０は、所定の時間だけ処理待ちし（ステップＳ２
２０４）、その後、ステップＳ２２０１へ戻って、上記
と同様の処理を繰り返す。

【０１７８】図２３において、先読制御部３０９は、最
初、読み出しに使われている帯域幅を測定する処理を開
始する（ステップＳ２３０１）。読み出しに使われてい
る帯域幅の計測は、例えば、アプリケーション３０２か
らのブロック読み出し要求の頻度と、ブロックのサイズ
とを検出することにより行える。次に、先読量制御部３
１０は、読み出しに使われている帯域幅に対応する先読
み量を、Ｄ（ｔ）とする（ステップＳ２３０２）。そし
て、現在の先読み量が上記のＤ（ｔ）よりも小さいか否
かを判定する（ステップＳ２３０３）。その判定結果が
否定の場合、ステップＳ２３０５に進む。

【０１７９】ステップＳ２３０３の判定結果が肯定の場
合、先読制御部３０９は、上記のＤ（ｔ）を、現在の先
読み量に変更し（ステップＳ２３０４）、その後、ステ
ップＳ２３０５へ進む。ステップＳ２３０５では、先読
み量増加処理を停止するか否かが判断される。その判断
結果が否定の場合、ステップＳ２３０２に戻って、上記
と同様の処理が繰り返される。ステップＳ２３０５の判
断結果が肯定の場合、先読制御部３０９は、読み出しに
使われている帯域幅を測定する処理を停止し（ステップ
Ｓ２３０６）、その後、処理終了となる。

【０１８０】図２４，図２５はそれぞれ、図３の先読量
制御部３１０が行う先読み量減少処理を示すフローチャ
ートである。図２４において、先読量制御部３１０は、
最初、先読みバッファ使用量がしきい値Ｃ以上であるか
否かを判定する（ステップＳ２４０１）。その判定結果
が否定の場合、ステップＳ２４０５に進む。ステップＳ
２４０１の判定結果が肯定の場合、先読量制御部３１０
は、先読み量の減少を実行し（ステップＳ２４０２）、
次いで、先読みバッファ使用量が、先読み量を超えてい
るか否かを判定する（ステップＳ２４０３）。その判定
結果が否定の場合、ステップＳ２４０５に進む。

【０１８１】ステップＳ２４０３の判定結果が肯定の場
合、現在の先読み量を超えて後方にあるブロックを格納
したバッファが開放され（ステップＳ２４０４）、その
後、ステップＳ２４０５に進む。ステップＳ２４０５で
は、先読み量減少処理を停止するか否かが判断され、そ
の判定結果が肯定の場合、処理終了となる。ステップＳ
２４０５の判定結果が否定の場合、先読量制御部３１０
は、所定の時間だけ処理待ちし（ステップＳ２４０
６）、その後、ステップＳ２４０１へ戻って、上記と同
様の処理を繰り返す。

【０１８２】図２５において、先読制御部３０９は、最
初、読み出しに使われている帯域幅を測定する処理を開
始する（ステップＳ２５０１）。次に、先読量制御部３
１０は、読み出しに使われている帯域幅に対応する先読
み量を、Ｄ（ｔ）とする（ステップＳ２５０２）。そし
て、現在の先読み量が上記のＤ（ｔ）よりも小さいか否
かを判定する（ステップＳ２５０３）。その判定結果が
否定の場合、ステップＳ２５０６に進む。

【０１８３】ステップＳ２５０３の判定結果が肯定の場
合、先読制御部３０９は、上記のＤ（ｔ）を、現在の先
読み量に変更し（ステップＳ２５０４）する。次いで、
現在の先読み量を超えて後方にあるブロックを格納した
バッファが開放され（ステップＳ２５０５）、その後、
ステップＳ２５０６に進む。ステップＳ２５０６では、
先読み量減少処理を停止するか否かが判断される。その
判断結果が否定の場合、ステップＳ２５０２に戻って、
上記と同様の処理が繰り返される。ステップＳ２５０６
の判断結果が肯定の場合、先読制御部３０９は、読み出
しに使われている帯域幅を測定する処理を停止し（ステ
ップＳ２５０７）、その後、処理終了となる。

【０１８４】〔先読みバッファの管理〕次に、上記のス
テップＳ４０７で先読バッファ管理部３０８が行う先読
み先読みバッファ管理について説明する。前述のよう
に、最小帯域保証が設定された場合、標準帯域を超える
帯域幅で読み出しが行われることがある。簡単な一例と
して、あるファイルに対して最小帯域保証が設定され、
別のファイルに対して最大帯域保証が設定されており、
それら２つのファイルの読み出しを同時に実行する場合
を考える。このとき、前者ファイルの読み出し帯域幅が
標準帯域を超えたと仮定すると、後者のファイルの読み
出し帯域幅は、標準帯域を下回る（つまり、最大帯域保
証が機能しない）ことがないとはいえない。なぜなら、
先読みバッファの容量が有限だからである。

【０１８５】そこで、先読バッファ管理部３０８は、先
読みバッファを、標準帯域と対応する基礎領域（つま
り、全てのファイルを各々の標準帯域で読み出す際に必
要となる分の先読みバッファ）と、標準帯域内に生じる
空き帯域と対応する共有領域とに分けて管理する。それ
により、最大帯域保証が機能しなくなる不都合はなくな
る。

【０１８６】なお、上記の共有領域は、帯域の有効利用
の観点から見れば、少なくとも基礎領域と同じ大きさを
確保することが好ましい。つまり、先読みバッファの全
容量は、全てのファイルを各々の標準帯域で読み出す際
に必要となる量の２倍以上であることが好ましい。なぜ
なら、共有領域が基礎領域を下回った場合、たとえ空き
帯域があっても、バッファが不足して、先読み量制御が
不安定となり、その結果、空き帯域の利用効率が低下す
ることがあるからである。一方、共有領域が基礎領域以
上であれば、先読み量制御は安定し、空き帯域利用の効
率低下を抑えることができる。

【０１８７】さらには、共有領域が基礎領域の２倍以上
であれば、より好ましい。なぜなら、共有領域が基礎領
域の２倍を下回っていると、最小帯域保証が設定された
複数のファイルが同時に読み出されている場合に、その
うち１個のファイルが先読み量減少処理中であると、残
りのファイルによる空き帯域利用の効率低下が起こるか
らである。一方、共有領域が基礎領域の２倍以上であれ
ば、最小帯域保証が設定された複数のファイルが同時に
読み出されている場合に、そのうち１個のファイルが先
読み量減少処理中であっても、残りのファイルによる空
き帯域利用の効率低下を抑えることができる。一般的に
は、共有領域の大きさは、基礎領域の大きさのＮ倍（た
だし、Ｎは２以上の任意の整数）以上であるのが、より
好ましい。その場合、最小帯域保証が設定された（Ｎ−
１）個のファイルが同時に先読み量減少処理中であって
も、残りのファイルによる空き帯域利用の効率低下を抑
えることができる。

【０１８８】図２６は、図３のファイル読出部３０６
が、読み出したブロック（受信ブロック）を先読みバッ
ファに格納する処理（そこには、先読バッファ管理部３
０８が行う先読みバッファ量制御が含まれる）を示すフ
ローチャートである。図２６において、最初、先読バッ
ファ管理部３０８は、現在の先読みバッファ量が、標準
帯域に相当する量（上記基礎領域の大きさ）未満である
か否かを判定する（ステップＳ２６０１）。その判定結
果が否定の場合、ステップＳ２６０４へ進む。ステップ
Ｓ２６０１の判定結果が否定の場合、先読バッファ管理
部３０８は、先読みバッファ量の増加を行い（ステップ
Ｓ２６０２）、次いで、ファイル読出部３０６は、受信
ブロックを先読みバッファに格納し、併せて、その格納
位置を登録する（ステップＳ２６０３）。

【０１８９】ステップＳ２６０４では、共有バッファ使
用量が上限に達しているか否かが判断され、達していな
ければ、先読バッファ管理部３０８が、先読みバッファ
量の増加を行い（ステップＳ２６０５）、その後、ステ
ップＳ２６０２へ進む。ここで共有バッファ使用量と
は、先読みバッファの共有領域（上述）に記憶されてい
る先読みブロックのうち、まだアプリケーション３０２
側のバッファへとコピーされていないブロックの数（と
対応する未開放バッファの量）をいう。

【０１９０】ステップＳ２６０４の判定結果が肯定の場
合、受信ブロックの廃棄が行われ（ステップＳ２６０
６）、次いで、先読み要求が中断される（ステップＳ２
６０７）。そして、先読制御部３０９は、先読み位置
を、廃棄された受信ブロックと対応する位置に変更し
て、そこから先読みをやり直す（ステップＳ２６０
８）。その後、処理終了となる。

【０１９１】〔特殊再生を行う場合の先読み処理〕最後
に、特殊再生、例えば高速再生や、逆方向再生を行う場
合の先読み処理を説明しておく。逆方向再生を行う場合
の先読み処理は、次のようになる。図２７は、逆方向再
生を行う場合の先読み処理を直感的に説明するための図
である。図２７に示すように、先読制御部３０９は、再
生方向の反転の有無を、要求ブロックと、次の要求ブロ
ックとの、ファイル内における位置関係に基づいて判定
する。すなわち、いま送られてきた要求と対応するブロ
ックが、その直前に送られてきた要求と対応するブロッ
クよりも後方にあるときは、再生方向の反転なしと判定
し、前方にあるときは、再生方向の反転ありと判定す
る。

【０１９２】図２８は、逆方向再生に伴い、図３の先読
制御部３０９が行う先読み方向切り替え処理を示すフロ
ーチャートである。図２８において、先読み方向を切り
換える場合、先読制御部３０９は、最初、いま行ってい
る先読みを中断し（ステップＳ２８０１）、次いで、先
読み方向を切り換える（ステップＳ２８０２）。次に、
先読制御部３０９は、要求ブロックが先読みバッファ内
に存在するか否かを判断し（ステップＳ２８０３）、そ
の判断結果が否定の場合、ステップＳ２８０４に進む。

【０１９３】ステップＳ２８０３の判断が肯定の場合、
ファイル読出部３０６は、アプリケーション３０２への
応答を実行し（ステップＳ２８０４）、次いで、不要バ
ッファを開放する（ステップＳ２８０５）。そして、先
読制御部３０９は、先読み位置を、その前方の、まだ先
読みされていないブロックと対応する位置に変更して、
そこから先読みをやり直す（ステップＳ２８０６）。そ
して、追加先読みが実行され（ステップＳ２８０７）、
その後、イベント待ちに入る。

【０１９４】特殊再生を行う場合の先読み処理は、次の
ようになる。図２９は、高速再生を行う場合の先読み処
理を直感的に説明するための図である。図２９におい
て、高速再生では、ファイル内のデータが一定間隔で飛
び飛びに読み出され、それらが連続的に再生される。よ
って、先読みの対象となるデータは、通常再生の場合と
異なり、ファイル内に離散的に存在することになる。そ
こで、先読制御部３０９は、合計の先読み量が上式
（２）で算出される値と等しくなるように、あるいは、
合計の先読み数が上式（１）で算出される値と等しくな
るように、断続的に先読みを行う。断続的な先読みは、
ファイルシステムが先読み開始位置を断続的に指定し
て、前述の先読みジャンプ処理を反復実行することによ
り行える。

【０１９５】以上のように、本実施形態によれば、アプ
リケーションの要求に応じ、ファイルシステムが、ファ
イル書き込みやファイル読み出し用の帯域を設定できる
ようになる。また、帯域保証として、最大帯域保証に、
最小帯域保証を組み合わせて用いることによって、最大
帯域保証が設定された場合に生じる空き帯域の有効利用
が可能となる。また、帯域に応じた量のデータを先読み
するので、空き帯域の利用を図っても、遅延の隠蔽が不
十分となることがなくなる。さらに、先読み量を制御す
ることによって、最小帯域保証を用いる場合に生じる送
信帯域幅の変動にも追従することができるようになる。
こうして、最大遅延時間を保証する、つまり十分高い確
率を以て、読み出し遅延や書き込み遅延を一定時間内に
収めることが可能となる。

【０１９６】最大遅延時間が保証される結果として、ネ
ットワークを介したクライアント・サーバ・システムに
適用されるリアルタイム・リモート・ファイルシステ
ム、すなわち、ネットワークを通じ、ファイルサーバに
対して読み出しや書き込みをリアルタイムに行えるよう
なファイルシステムが実現される。そして、このような
フィルシステムは、ネットワーク環境で用いる場合に最
も効果を発揮するが、ネットワークを介さない環境で用
いてもよいのはいうまでもない。なぜなら、読み出しや
書き込みの遅延は、ネットワーク伝送の際だけでなく、
例えば、記録ディスクへのランダムアクセスを行う際に
も生じるからである。

【０１９７】なお、本実施形態では、属性情報管理部３
１５をディレクトリ・サーバ１０３に設けることによっ
て、全ての属性情報を一括管理しているが、代わりに、
各クライアント１０１にそれぞれ、そのクライアント１
０１専用の属性情報管理部を設けてもよい。

【０１９８】また、本実施形態では、帯域設定部３０５
は、ファイル書込部３０７の送信帯域幅制御部３１１
と、ファイル・サーバ１０２の送信帯域幅制御部３１４
とを対象に帯域設定を行っているが、ネットワーク１０
４の伝送帯域制御部（図示せず）を帯域設定対象に加え
てもよい。さらに、ファイル１つに対して、ネットワー
クのコネクション１本を割り当てて上記のように帯域設
定を行ってもよいし、また、上記のように帯域設定を行
った１本のネットワークのコネクションを、複数のファ
イルが使用してもよい。

【０１９９】また、上記の実施形態とは別の実施形態と
して、次のような実施形態もある。図３０は、本発明の
別の実施形態に係るリアルタイム・リモート・ファイル
システムの構成を示すブロック図である。図３０におい
て、リモート・ファイルシステム３２０１およびファイ
ル・サーバ３１０２は、図３２，図３１に示すそれら
（従来技術の欄を参照）と同一であり、リアルタイム・
リモート・ファイルシステム３０１、ファイル・サーバ
１０２およびディレクトリ・サーバ１０３は、図３，図
１に示すそれらと同一である。ＯＳ３０３には、図３に
示すそれにおいて、要求振分部３００１が追加されてい
る。要求振分部３００１は、アプリケーション３０２か
らＡＰＩ３１２を通じて与えられるファイル操作要求
を、リモート・ファイルシステム３２０１側と、リアル
タイム・リモート・ファイルシステム３０１側とに振り
分ける。

【０２００】アプリケーション３０２は、ファイル操作
を要求する際、ファイル・サーバ３１０２に対するファ
イル操作か、ファイル・サーバ１０２に対するファイル
操作かを指定する。要求振分部３００１は、指定に従
い、ファイル操作要求を、リモート・ファイルシステム
３２０１およびリアルタイム・リモート・ファイルシス
テム３０１のいずれかに与える。以降、リモート・ファ
イルシステム３２０１が行う処理、およびリアルタイム
・リモート・ファイルシステム３０１が行う処理は、前
述した通りであり、説明を省略する。

【０２０１】ＯＳ３０３としては、例えば、Ｗｉｎｄｏ
ｗｓＮＴを用いる。ＷｉｎｄｏｗｓＮＴでは、備え
付けのファイルシステムの他に、別のファイルシステム
をさらに組み込むことができる。そして、それら複数の
ファイルシステムを切り換えて使うための要求振り分け
機能が、ＷｉｎｄｏｗｓＮＴサービスの１つとして予
め準備されているので、図３０のようなファイルシステ
ムを容易に実現できる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るリアルタイム・リモ
ート・ファイルシステムが適用されるクライアント・サ
ーバ・システムの構成を示すブロック図である。

【図２】図１のファイル・サーバ１０２、ディレクトリ
・サーバ１０３および各クライアント１０１を実現する
コンピュータ装置の構成の一例を示すブロック図であ
る。

【図３】本発明の一実施形態に係るリアルタイム・リモ
ート・ファイルシステムの構成を示すブロック図である
（図１のクライアント・サーバ・システムに適用された
場合）。

【図４】本発明の第１の実施形態に係るリアルタイム・
リモート・ファイルシステムが図１のクライアント・サ
ーバ・システムに適用されて、ネットワーク１０４を通
じて（または内部的に）行う処理（ファイル操作および
帯域設定）を示すフローチャートである。

【図５】図３の帯域設定部３０５によって設定される標
準帯域および帯域保証の種類の例を示す図である。

【図６】図３の帯域設定部３０５によって設定される標
準帯域および帯域保証の種類の例を示す図である。図６
には、（ａ）および（ｂ）の２つの例が示されている。

【図７】図３の送信帯域幅制御部３１４が、図６のよう
に設置された標準帯域、および帯域保証の種類に基づい
て行う送信帯域幅制御を、直感的に説明するための図で
ある。

【図８】アプリケーション３０２が要求するブロック
と、ファイル・サーバ１０２の記録ディスク上に記録さ
れているブロックとの、サイズの違いを示した図であ
る。

【図９】ファイル・サーバ１０２の記録ディスク上に１
２８ＫＢ（＝１３１０７２バイト）のブロックが連続的
に記録されているとき、アプリケーション３０２が１ブ
ロック跳ばしに（つまり１２００００バイトおきに）断
続的に要求する様子を示す図である。

【図１０】図３のファイル読出部３０６が、アプリケー
ション３０２からのブロック読み出し要求に応じて行う
ブロック読み出し処理を示すフローチャートである。

【図１１】図１０のステップＳ１００５の追加先読み処
理を示すフローチャートである。

【図１２】図１０のステップＳ１００６の読み出しジャ
ンプ処理を示すフローチャートである。

【図１３】図３のファイル読出部３０６が、読み出した
ブロック（以下、受信ブロック）を先読みバッファに格
納する処理を示すフローチャートである。

【図１４】図１３のステップＳ１３０２の受信ブロック
格納処理を示すフローチャートである。

【図１５】図３の先読量制御部３１０が行う先読み量制
御の原理を、直感的に説明するための図である。

【図１６】図３のファイル読出部３０６が、アプリケー
ション３０２からのブロック読み出し要求に応じて行う
ブロック読み出し処理を示すフローチャートである。

【図１７】図３のファイル読出部３０６が、受信ブロッ
クを先読みバッファに格納する処理を示すフローチャー
トである。

【図１８】図１６のステップＳ１６０１の先読み量減少
処理停止判定を示すフローチャートである。

【図１９】図１６のステップＳ１６０２の先読み量増加
処理停止判定を示すフローチャートである。

【図２０】図１６のステップＳ１６０３の先読み量増加
処理開始判定を示すフローチャートである。

【図２１】図１７のステップＳ１７０３の先読み量増加
処理開始判定を示すフローチャートである。

【図２２】図３の先読量制御部３１０が行う先読み量増
加処理を示すフローチャートである。

【図２３】図３の先読量制御部３１０が行う別の先読み
量増加処理を示すフローチャートである。

【図２４】図３の先読量制御部３１０が行う先読み量減
少処理を示すフローチャートである。

【図２５】図３の先読量制御部３１０が行う別の先読み
量減少処理を示すフローチャートである。

【図２６】図３のファイル読出部３０６が、読み出した
ブロック（受信ブロック）を先読みバッファに格納する
処理（そこには、先読バッファ管理部３０８が行う先読
みバッファ量制御が含まれる）を示すフローチャートで
ある。

【図２７】逆方向再生を行う場合の先読み処理を直感的
に説明するための図である。

【図２８】逆方向再生に伴い、図３の先読制御部３０９
が行う先読み方向切り替え処理を示すフローチャートで
ある。

【図２９】高速再生を行う場合の先読み処理を直感的に
説明するための図である。

【図３０】本発明の別の実施形態に係るリアルタイム・
リモート・ファイルシステムの構成を示すブロック図で
ある。

【図３１】従来のリモート・ファイルシステムが適用さ
れるクライアント・サーバ・システムの構成を示すブロ
ック図である。

【図３２】従来のリモート・ファイルシステムの機能的
な構成を示すブロック図である（図３１のクライアント
・サーバ・システムに適用された場合）。

【図３３】図３２のリモート・ファイルシステム３２０
１が、図３１のクライアント・サーバ・システムに適用
されて、ネットワーク３１０３を通じて行う処理（ファ
イル操作）を示すフローチャートである。

【図３４】図３２のアプリケーション３２０２が、ファ
イル読み出しの際に、ファイル読み出し要求、および一
連のブロック読み出し要求を発するタイミングの一
例（”同期的”読み出しの場合）を示したタイムチャー
トである。

【符号の説明】

１０１…クライアント１０２…ファイル・サーバ１０３…ディレクトリ・サーバ１０４…ネットワーク２０１…ＣＰＵ２０２…ＲＡＭ２０３…プログラムメモリ２０４…記録ディスク２０５…ネットワーク・インターフェース・カード３０１…リアルタイム・リモート・ファイルシステム３０２…アプリケーション３０３…ＯＳ３０４…ファイル管理部３０５…帯域設定部３０６…ファイル読出部３０７…ファイル書込部３０８…先読バッファ管理部３０９…先読制御部３１０…先読量制御部３１１，３１４…送信帯域幅制御部３１２…ＡＰＩ３１３…拡張ＡＰＩ３１５…帯域設定部３００１…要求振分部

───────────────────────────────────────────────────── フロントページの続き (72)発明者伊藤由起子大阪府門真市大字門真1006番地松下電器産業株式会社内 (72)発明者田中勉大阪府門真市大字門真1006番地松下電器産業株式会社内Ｆターム(参考） 5B089 GA12 GA21 GB01 GB03 JA32 JA35 KA05 KD01 KE02 5K030 GA02 HA10 HB02 HB11 JL01 KA03 KA07 LA18 LC05 5K034 AA03 BB02 CC02 DD03 EE03 EE11 FF13 HH21 LL01 MM11

Claims

【特許請求の範囲】

【請求項１】アプリケーションが発行するファイル読
み出し要求および／またはファイル書き込み要求を受
け、ファイルを蓄積するデータ蓄積部に対してファイル
読み出しおよび／またはファイル書き込みを行うファイ
ルシステムであって、前記アプリケーションは、帯域設定要求をさらに発行
し、前記アプリケーションからのファイル読み出し要求に応
じ、前記データ蓄積部に対してファイル読み出しを実行
するファイル読出部、前記アプリケーションからのファイル書き込み要求に応
じ、前記データ蓄積部に対してファイル書き込みを実行
するファイル書込部、ファイル書き込みの際、前記ファイル書込部から前記デ
ータ蓄積部へのデータ送信に使われる送信帯域幅を制御
する第１の送信帯域幅制御部、ファイル読み出しの際、前記データ蓄積部から前記ファ
イル読出部へのデータ送信に使われる送信帯域幅を制御
する第２の送信帯域幅制御部、および前記アプリケーシ
ョンからの帯域設定要求に応じ、前記第１の送信帯域幅
制御部および／または前記第２の送信帯域幅制御部に対
して帯域設定を行う帯域設定部を備える、ファイルシス
テム。
【請求項２】前記帯域設定部は、帯域設定を行う際、
標準帯域と、帯域保証の種類とを設定し、前記帯域保証の種類には、前記標準帯域を最大帯域とし
て保証する最大帯域保証が含まれ、前記第１の送信帯域幅制御部および／または前記第２の
送信帯域幅制御部は、前記最大帯域保証が設定された場
合、たとえ空き帯域があっても、保証された前記標準帯
域だけを使ってデータを送信するような送信帯域幅制御
を行うことを特徴とする、請求項１に記載のファイルシ
ステム。
【請求項３】前記帯域保証の種類には、前記標準帯域
を最小帯域として保証する最小帯域保証がさらに含ま
れ、前記第１の送信帯域幅制御部および／または前記第２の
送信帯域幅制御部は、前記最小帯域保証が設定された場
合、もし空き帯域があれば、保証された前記標準帯域だ
けでなく、その空き帯域も使ってデータを送信するよう
な送信帯域幅制御を行うことを特徴とする、請求項２に
記載のファイルシステム。
【請求項４】前記帯域保証の種類には、帯域保証を行
わない帯域無保証がさらに含まれ、前記第１の送信帯域幅制御部および／または前記第２の
送信帯域幅制御部は、前記帯域無保証が設定された場
合、もし空き帯域があれば、その空き帯域を使ってデー
タを送信するような送信帯域幅制御を行うことを特徴と
する、請求項３に記載のファイルシステム。
【請求項５】前記第１の送信帯域幅制御部および／ま
たは前記第２の送信帯域幅制御部は、前記送信帯域幅制
御を行う際、最小帯域保証と対応する各送信データに対
し、標準帯域に応じて空き帯域を分配することを特徴と
する、請求項３に記載のファイルシステム。
【請求項６】前記第１の送信帯域幅制御部および／ま
たは前記第２の送信帯域幅制御部は、前記送信帯域幅制
御を行う際、各送信データに対し、均等に空き帯域を分
配することを特徴とする、請求項４に記載のファイルシ
ステム。
【請求項７】前記第１の送信帯域幅制御部および／ま
たは前記第２の送信帯域幅制御部は、前記送信帯域幅制
御を行う際、帯域無保証と対応する送信データよりも最
小帯域保証と対応する送信データに対して、より優先的
に空き帯域を分配することを特徴とする、請求項４に記
載のファイルシステム。
【請求項８】前記第１の送信帯域幅制御部および／ま
たは前記第２の送信帯域幅制御部は、前記送信帯域幅制
御を行う際に、送信バッファの状態をも考慮することを
特徴とする、請求項４に記載のファイルシステム。
【請求項９】前記第１の送信帯域幅制御部および／ま
たは前記第２の送信帯域幅制御部は、前記送信帯域幅制
御を行う際に、送信先にある受信バッファの状態をも考
慮して制御を行うことを特徴とする、請求項４に記載の
ファイルシステム。
【請求項１０】前記帯域設定部は、さらに、前記ファ
イル読出部に対しても帯域設定を行い、前記ファイル読出部は、ファイル読み出しを行う際、前記アプリケーションが要
求していない所定量のデータを先読みするための先読制
御部、および先読みしたデータが一時記憶される先読み
バッファを管理するための先読みバッファ管理部を含
み、前記先読制御部は、前記帯域設定部によって設定される
帯域に基づいて、先読みするデータの量を決定すること
を特徴とする、請求項１に記載のファイルシステム。
【請求項１１】前記帯域設定部は、さらに、前記ファ
イル読出部に対しても帯域設定を行い、前記ファイル読出部は、ファイル読み出しを行う際、前記アプリケーションが要
求していない所定量のデータを先読みするための先読制
御部、および先読みしたデータが一時記憶される先読み
バッファを管理するための先読みバッファ管理部を含
み、前記先読制御部は、前記帯域設定部によって設定される
標準帯域と、予め算定された最大遅延時間との積に基づ
いて、先読みするデータの量を決定することを特徴とす
る、請求項３に記載のファイルシステム。
【請求項１２】前記最大遅延時間は、その時間を上回
るような読み出し遅延の生じる確率が十分小さくなるよ
うに算定された時間であることを特徴とする、請求項１
１に記載のファイルシステム。
【請求項１３】前記ファイル読出部は、先読みするデ
ータの量を制御するための先読量制御部をさらに含み、前記先読量制御部は、前記最小帯域保証が設定された場
合、前記第１の送信帯域幅制御部の制御の結果として、
前記アプリケーションからの読み出し要求と対応する送
信帯域幅が前記標準帯域を超えたときに、先読みするデ
ータの量を、前記先読制御部が決定した量以上となるよ
うに制御することを特徴とする、請求項１１に記載のフ
ァイルシステム。
【請求項１４】前記先読みバッファ管理部は、前記バ
ッファ管理部が管理する先読みバッファの使用状況に基
づいて、先読み量制御を行うことを特徴とする、請求項
１３に記載のファイルシステム。
【請求項１５】前記先読みバッファ管理部は、先読み
バッファに記憶されている先読みデータの量を監視し
て、その監視結果を、先読みバッファ使用量として、前
記先読量制御部へと通知し、前記先読量制御部は、通知された先読みバッファ使用量
に基づいて、先読み量制御を行うことを特徴とする、請
求項１３に記載のファイルシステム。
【請求項１６】前記先読量制御部は、通知された先読
みバッファ使用量を、予め決められたしきい値と比較し
て、その比較結果に関連して、先読みするデータの量を
増減させることを特徴とする、請求項１５に記載のファ
イルシステム。
【請求項１７】前記バッファ管理部は、先読みバッフ
ァを、前記標準帯域と対応する基礎領域と、当該標準帯
域以外の空き帯域と対応する共有領域とに分けて管理す
ることを特徴とする、請求項１３に記載のファイルシス
テム。
【請求項１８】前記共有領域の大きさは、前記基礎領
域の大きさ以上であることを特徴とする、請求項１７に
記載のファイルシステム。
【請求項１９】前記共有領域の大きさは、前記基礎領
域の大きさのＮ倍（ただし、Ｎは２以上の任意の整数）
以上であることを特徴とする、請求項１７に記載のファ
イルシステム。
【請求項２０】前記先読制御部は、ファイルの先頭と
は異なる位置から読み出しが開始される場合、先読み位
置を、アプリケーションが指定した位置の前方にある、
まだ先読みしていない位置に変更して、その位置から先
読みを開始することを特徴とする、請求項１０に記載の
ファイルシステム。
【請求項２１】前記先読制御部は、ファイル内のデー
タを断続的に読み出す高速再生が行われる場合、先読み位置を、アプリケーションの要求と、ファイル内
のデータ領域のサイズと、読み出しの方向とに基づいて
決定し、決定した位置から、断続的に先読みを行うことを特徴と
する、請求項１０に記載のファイルシステム。
【請求項２２】前記先読制御部は、再生の方向を順方
向から逆方向へと切り換えて、逆方向再生が行われる場
合、今回読み出し要求されたデータと、前回読み出し要求さ
れたデータとの、ファイル内における位置関係に基づい
て、再生方向が順方向から逆方向へ変化したことを検知
し、再生方向が順方向から逆方向へ変化したことを検知する
と、先読みを行う方向を、順方向から逆方向へと切り換
えると共に、先読み位置を、その位置から見て当該逆方
向にある、まだ先読みしていない位置に変更して、その
位置から当該逆方向に先読みを開始することを特徴とす
る、請求項１０に記載のファイルシステム。
【請求項２３】前記先読制御部は、再生の方向を順方
向から逆方向へと切り換えて、逆方向再生が行われる場
合に備えて、当該逆方向のデータを、前記先読みするデ
ータの量と同量だけ保持しておくことを特徴とする、請
求項２２に記載のファイルシステム。
【請求項２４】前記第１の送信帯域幅制御部および／
または前記第２の送信帯域幅制御部は、前記アプリケー
ションが要求するデータの最小単位と、前記データ蓄積
部が扱うデータの最小単位とが互いに異なる場合には、
それら２つの最小単位に基づいて、実際に必要な実帯域
幅を計算し、前記標準域幅の代わりにその実帯域幅を用
いて、送信帯域幅制御を行うことを特徴とする、請求項
４に記載のファイルシステム。
【請求項２５】前記アプリケーションからのファイル
読み出し要求および／またはファイル書き込み要求を、
前記ファイル読出部に適した形式に変換する第１のＡＰ
Ｉ（アプリケーション・プログラム・インターフェー
ス；以下同様）、および前記アプリケーションからの帯
域設定要求を、前記帯域設定部に応じた形式に変換する
第２のＡＰＩをさらに備える、請求項１に記載のファイ
ルシステム。
【請求項２６】前記データ蓄積部に蓄積されているフ
ァイルを、当該フィルの属性を示す属性情報に基づいて
管理するファイル管理部、および前記属性情報を管理す
る属性情報管理部をさらに備える、請求項１に記載のフ
ァイルシステム。
【請求項２７】前記属性情報には、前記帯域設定部が
行う帯域設定に関連する初期設定情報が含まれているこ
とを特徴とする、請求項２６に記載のファイルシステ
ム。
【請求項２８】前記データ蓄積部は、ネットワークと
接続されたファイル・サーバで実現され、前記ファイル読出部は、前記ファイル・サーバに対し、
前記ネットワークを通じてファイル読み出しを行い、前記ファイル書込部は、前記ファイル・サーバに対し、
前記ネットワークを通じてファイル書き込みを行うこと
を特徴とする、請求項１３に記載のファイルシステム。
【請求項２９】前記帯域設定部は、さらに、前記ネッ
トワークに対して帯域を設定することを特徴とする、請
求項２８に記載のファイルシステム。
【請求項３０】前記帯域設定部は、前記ネットワーク
に対する帯域設定を、１つのファイルに対して当該ネッ
トワーク内のコネクション１本を割り当てるようにして
行うことを特徴とする、請求項２８に記載のファイルシ
ステム。
【請求項３１】前記帯域設定部は、前記ネットワーク
に対する帯域設定を、複数のファイルに対して当該ネッ
トワーク内のコネクション１本を割り当てるようにして
行うことを特徴とする、請求項２８に記載のファイルシ
ステム。
【請求項３２】前記帯域設定部は、ファイル毎に帯域
設定を行うことを特徴とする、請求項１に記載のファイ
ルシステム。
【請求項３３】前記帯域設定部は、ファイルの属性毎
に帯域設定を行うことを特徴とする、請求項２６に記載
のファイルシステム。
【請求項３４】前記ネットワークには、当該ネットワ
ークを通じて前記ファイル・サーバとの間でデータの送
受信を行うクライアントが接続され、前記帯域設定部は、前記クライアント毎に帯域設定を行
うことを特徴とする、請求項２８に記載のファイルシス
テム。