(57)【要約】【課題】管理アクセス中に一般アクセスがあった場合に一般アクセスに対するレスポンスのよいファイル管理システム等を提供する。【解決手段】ファイルシステムにおいて連続したブロックを確保し（Ｓ５２０）１ブロック分のデータをこの確保した領域へコピーする。そしてオペレーティングシステムからクローズが要求されたか否かを判定し（Ｓ５３０）、クローズが要求されていない場合には（Ｓ５４０：いいえ）Ｓ５５０へ移行して、最終ブロックか否かを判定し、最終ブロックの場合には、Ｓ５６０へ移行し、ブロック群情報を書き換え、Ｓ５８０へ移行する。一方、最終ブロックでない場合には、次のブロックをコピー対象のブロックにセットしてＳ５３０へ移行する。またＳ５４０で、クローズが要求されたと判定された場合には、Ｓ５７０へ移行してＳ５２０で確保したブロック群を解放する。そして、Ｓ５８０で、このファイルをクローズする。【選択図】図７
2005056245.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムにおけるファイルアクセス管理方法において、
ファイルの管理のためのアクセスである管理アクセス中のファイルに対して、前記管理アクセス以外のアクセスである一般アクセスの要求があったか否かを判別し、前記管理アクセス中のファイルに対して前記一般アクセスの要求があった場合には、当該管理アクセスを中断させ、前記一般アクセスの要求に応じたアクセスを許可すること
を特徴とするファイルアクセス管理方法。
【請求項２】
ファイルの管理を行うプロセスである管理プロセスと、前記管理プロセス以外のプロセスである一般プロセスとを実行可能なコンピュータシステムにおけるファイルアクセス管理方法であって、
前記管理プロセスからのアクセスである管理アクセス中のファイルに対して、前記一般プロセスからのファイルアクセス要求があったか否かを判別し、前記管理プロセスからのアクセスである管理アクセス中のファイルに対して、前記一般プロセスからのファイルアクセス要求があった場合には、前記管理プロセスに通知して当該管理アクセス中のファイルをクローズし、前記一般プロセスからのファイルアクセス要求に応じたアクセスを許可すること
を特徴とするファイルアクセス管理方法。
【請求項３】
コンピュータシステムにおけるファイルアクセス管理方法において、
記憶装置に記憶されたファイルのうちロックされたファイルを識別するファイル識別情報と、当該ロックされたファイルへのアクセスがファイルの管理を目的とするアクセスである管理アクセスによるものか、前記管理アクセス以外のアクセスである一般アクセスによるものかを識別するための情報であるアクセス目的識別情報とを関連付けて記憶する記憶手段を備え、
ファイルへのアクセス要求を受け付けた場合、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されているか否かを判定し、記憶されていない場合には、当該ファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して当該ファイルへのアクセスを許可する一方、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されている場合には、当該アクセス要求が前記管理アクセスの要求であるか前記一般アクセスの要求であるかを識別し、当該アクセス要求が一般アクセスの要求であって、かつ、前記記憶手段に記憶された当該ファイルのファイル識別情報に関連づけて記憶された前記アクセス目的識別情報が管理アクセスによるものを示す場合には、当該管理アクセスを中断させ、前記アクセス要求されたファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して前記アクセス要求に応じたアクセスを許可すること
を特徴とするファイルアクセス管理方法。
【請求項４】
請求項３に記載のファイル管理方法において、
前記管理アクセスを行うプロセスを識別する識別情報を備え、
前記アクセス要求が、ファイルの管理のためのアクセスの要求である管理アクセス要求であるか、前記管理アクセス以外のアクセスの要求である一般アクセス要求であるかの識別は、前記ファイルに対するアクセス要求をしてきたプロセスの識別情報に基づいて行うこと
を特徴とするファイル管理方法。
【請求項５】
請求項１〜４のいずれかに記載のファイル管理方法において、
前記管理アクセスは、デフラグ、エラー検出、エラー訂正のためのアクセスであること
を特徴とするファイルアクセス管理方法。
【請求項６】
請求項１〜５のいずれかに記載のファイル管理方法において、
前記一般アクセスは、外部からのファイルアクセス要求に基づくアクセスであること
を特徴とするファイルアクセス管理方法。
【請求項７】
請求項１〜６のいずれかに記載のファイルアクセス管理方法をコンピュータシステムによって実現させるためのプログラム。
【請求項８】
請求項７に記載のプログラムと、当該プログラムを実行するコンピュータシステムとを備えたファイルアクセス管理システム。
【請求項９】
コンピュータシステムにおけるファイルアクセス管理システムにおいて、
ファイルの管理のためのアクセスである管理アクセス中のファイルに対して、前記管理アクセス以外のアクセスである一般アクセスの要求があったか否かを判別する判別手段と、
前記判別手段によって、前記管理アクセス中のファイルに対して前記一般アクセスの要求があったと判別された場合には、当該管理アクセスを中断させ、前記一般アクセスの要求に応じたアクセスを許可する管理手段とを備えること
を特徴とするファイルアクセス管理システム。
【請求項１０】
ファイルの管理を行うプロセスである管理プロセスと、前記管理プロセス以外のプロセスである一般プロセスとを実行可能なコンピュータシステムにおけるファイルアクセス管理システムであって、
前記管理プロセスからのアクセスである管理アクセス中のファイルに対して、前記一般プロセスからのファイルアクセス要求があったか否かを判別する判別手段と、
前記判別手段によって、前記管理プロセスからのアクセスである管理アクセス中のファイルに対して、前記一般プロセスからのファイルアクセス要求があったと判別された場合には、前記管理プロセスに通知して当該管理アクセス中のファイルをクローズし、前記一般プロセスからのファイルアクセス要求に応じたアクセスを許可する管理手段とを備えること
を特徴とするファイルアクセス管理システム。
【請求項１１】
コンピュータシステムにおけるファイルアクセス管理システムにおいて、
記憶装置に記憶されたファイルのうちロックされたファイルを識別するファイル識別情報と、当該ロックされたファイルへのアクセスがファイルの管理を目的とするアクセスである管理アクセスによるものか、前記管理アクセス以外のアクセスである一般アクセスによるものかを識別するための情報であるアクセス目的識別情報とを関連付けて記憶する記憶手段と、
ファイルへのアクセス要求を受け付けた場合、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されているか否かを判定し、記憶されていない場合には、当該ファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して当該ファイルへのアクセスを許可する一方、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されている場合には、当該アクセス要求が前記管理アクセスの要求であるか前記一般アクセスの要求であるかを識別し、当該アクセス要求が一般アクセスの要求であって、かつ、前記記憶手段に記憶された当該ファイルのファイル識別情報に関連づけて記憶された前記アクセス目的識別情報が管理アクセスによるものを示す場合には、当該管理アクセスを中断させ、前記アクセス要求されたファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して前記アクセス要求に応じたアクセスを許可する制御手段とを備えること
を特徴とするファイルアクセス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムにおけるファイルアクセス管理方法、ファイルアクセス管理システム、プログラムに関する。
【背景技術】
【０００２】
従来より、コンピュータシステムにおいて、記憶装置に記憶されたファイルや、ファイルを構成するデータの移動・連結・チェックなどの記憶管理を目的とした管理アクセスを行うものが知られている。こうした管理アクセスとしては、例えば、記憶装置の容量の有効利用や入出力性能の維持などを目的として記憶装置内のデータの再配置（例えばデフラグなど）を行うためアクセスや、記憶装置に記憶されたファイルの異常を検査するアクセスなどがある。
【０００３】
また、いわゆるマルチタスクのシステムにおいて、プロセスに優先順位を付け、その優先順位を動的に制御する動的制御方法が知られている（例えば、特許文献１参照。）。
【特許文献１】特開平１１-０８５５４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、マルチタスクのシステムにおいては、管理アクセスと一般アクセスの競合が起こりうる。例えば、あるファイルへの管理アクセスを行っている最中に、そのファイルに対して管理アクセス以外のアクセスである一般アクセスが行われる可能性がある。例えば、管理アクセスによるファイル内のデータの移動等の途中で、一般アクセスによるライトアクセスを行われた場合、ライトアクセスの内容が記憶装置上に反映されなかったり、ファイルが壊れたりする可能性がある。またリードアクセスの場合も同様に、管理アクセスの影響によって、一般アクセスで誤ったデータが読み出されることがある。
【０００５】
そこで、このような不具合を防ぐために、従来のファイルアクセス管理システムにおいては、アクセス中のファイルに対して他のアクセスができないようにロックを行うなどの排他制御を行っている。その結果、管理アクセス中のファイルには一般アクセスが不可能となり、また逆に一般アクセス中のファイルには管理アクセスが不可能となる排他制御がなされる。
【０００６】
しかしながら、管理アクセスは、一般的に、一般アクセスよりも長時間にわたって連続してなされることが多い。そのため、例えば、管理アクセスを行う記憶管理プログラムの実行中は、一般アクセスを行う管理プログラム以外のプログラムによる処理が処理待ちとなり、一般アクセスが可能となるまでの待ち時間が長時間にわたる場合があった。このような場合、管理アクセスを行う管理プログラム以外のプログラム（その他のプログラム）による処理の応答性が悪くなるという問題があった。例えば、記憶管理プログラムとしてデフラグプログラムを実行する場合、デフラグプログラムによる記憶装置のデフラグ処理が完了するまで、その他のプログラムの実行が待たされることがある。このように、管理アクセスが、一般アクセスを抑制してしまい、一般アクセス時のファイルシステムのレスポンスが低下するという問題があった。
【０００７】
そこで、本発明は、上述した問題点を解決するためになされたものであり、管理アクセス中に、管理アクセス以外のアクセスである一般アクセスがあった場合に、一般アクセスに対するファイルシステムのレスポンスを向上させることができるファイルアクセス管理方法、ファイルアクセス管理システム、プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した問題点を解決するためになされた請求項１に係るファイルアクセス管理方法は、ファイルの管理のためのアクセスである管理アクセス中のファイルに対して、前記管理アクセス以外のアクセスである一般アクセスの要求があった場合、前記管理アクセスを中断させ、前記一般アクセスの要求に応じたアクセスを行う。よって、管理アクセス中に、管理アクセス以外のアクセスである一般アクセスがあった場合に、一般アクセスに対するレスポンスを向上させることができる。
【０００９】
管理アクセスは、例えばカーネルモジュール内など各種のプログラムモジュール内で行うことができるが、例えば、プロセスから行うように構成する場合には、請求項２に示すようにするとよい。すなわち、請求項２に示すように、ファイルの管理を行うプロセスである管理プロセスと、管理プロセス以外のプロセスである一般プロセスとを実行可能なコンピュータシステムにおけるファイルアクセス管理方法であって、管理プロセスからのアクセスである管理アクセス中のファイルに対して、一般プロセスからのファイルアクセス要求があったか否かを判別し、管理プロセスからのアクセスである管理アクセス中のファイルに対して、一般プロセスからのファイルアクセス要求があった場合には、管理プロセスに通知してその管理アクセス中のファイルをクローズし、一般プロセスからのファイルアクセス要求に応じたアクセスを許可するとよい。例えば、管理アクセス中のファイルをクローズさせ、一般プロセスからのファイルアクセス要求に応じたファイルをオープンする。こうした処理は、例えばオペレーティングシステム（例えばファイルシステム）において、実行するように構成するとよい。
【００１０】
このようにすれば、管理プロセスから管理アクセス中のファイルに対して一般プロセスからのアクセス要求があった場合に、一般プロセスからのアクセス待ち時間を短くすることができる。例えば、管理プロセスからオープンされたファイルに対し、一般プロセスからのオープンの要求があった場合、管理プロセスにそのファイルをクローズさせ、一般プロセスからそのファイルをオープンすることが可能となり、一般プロセスからのアクセスに対するレスポンスを向上させることができる。なお、ここでアクセス中とは、ファイルがオープンされている状態をいう。
【００１１】
ファイルが管理プロセスからのアクセス中であるか一般プロセスからのアクセス中であるかは、例えば、請求項３に示すようにして管理するとよい。
すなわち、コンピュータシステムにおけるファイルアクセス管理方法において、記憶装置に記憶されたファイルのうちロックされたファイルを識別するファイル識別情報と、当該ロックされたファイルへのアクセスがファイルの管理を目的とするアクセスである管理アクセスによるものか、前記管理アクセス以外のアクセスである一般アクセスによるものかを識別するための情報であるアクセス目的識別情報とを関連付けて記憶する記憶手段を備え、ファイルへのアクセス要求を受け付けた場合、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されているか否かを判定し、記憶されていない場合には、当該ファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して当該ファイルへのアクセスを許可する一方、アクセス要求されたファイルのファイル識別情報が前記記憶手段に記憶されている場合には、当該アクセス要求が前記管理アクセスの要求であるか前記一般アクセスの要求であるかを識別し、当該アクセス要求が一般アクセスの要求であって、かつ、前記記憶手段に記憶された当該ファイルのファイル識別情報に関連づけて記憶された前記アクセス目的識別情報が管理アクセスによるものを示す場合には、当該管理アクセスを中断させ、前記アクセス要求されたファイルのファイル識別情報及び前記アクセス目的識別情報を前記記憶手段に記憶して前記アクセス要求に応じたアクセスを許可する。
【００１２】
なお、管理プロセスからのファイルアクセス要求であるか一般プロセスからのファイルアクセス要求であるかは、例えば、プロセスから自己のプロセスが管理プロセスであるか一般プロセスであるかを示す情報を付加してファイルアクセス要求を行い、この情報を参照して判別する構成とすることができる。あるいは、請求項４に示すように、管理アクセスを行うプロセスを識別する識別情報を備え、アクセス要求が、ファイルの管理のためのアクセスの要求である管理アクセス要求であるか、管理アクセス以外のアクセスの要求である一般アクセス要求であるかの識別は、前記ファイルに対するアクセス要求をしてきたプロセスの識別情報に基づいて行うとよい。このように、アクセス要求元のプロセス識別情報（プロセスＩＤ）等を参照して判別する構成とすることができる。
【００１３】
なお、管理アクセスは、例えば、請求項５に示すように、デフラグ、エラー検出、エラー訂正のためのアクセスとすることができる。また、一般アクセスは、請求項６に示すように、外部からのファイルアクセス要求に基づくアクセスとすることができる。例えば、コンピュータシステムがファイルサーバの場合、ネットワーク等を介して他のコンピュータシステム等の外部から要求されたファイルへのアクセスとすることができる。
【００１４】
また、請求項１〜６では、ファイルアクセス管理方法の請求項を挙げたが、請求項７に示すように、上述した、ファイルアクセス管理方法をコンピュータシステムによって実現させるためのプログラムとして構成することができる。
【００１５】
また、請求項８に示すように、請求項７に記載のプログラムと、当該プログラムを実行するコンピュータシステムとを備えたファイル管理システムとして構成することができる。
【００１６】
例えば、請求項９〜１１に記載のファイル管理システムとして構成することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００１８】
図１は、本実施例のファイルアクセス管理システムとしてのカラオケ装置１ａ，１ｂ，１ｃ…を含むカラオケシステムの構成を示すブロック図である。カラオケ装置１ａ，１ｂ，１ｃ…は、それぞれローカル・エリア・ネットワーク（ＬＡＮ）３０に接続されている。カラオケ装置１ａ，１ｂ，１ｃ…は、基本的な構成は同じであるが、カラオケ装置１ａのみが通信ネットワーク３を介してホストコンピュータ２に接続可能に構成されている点が異なる。
【００１９】
ホストコンピュータ２は、各種のファイル（例えば、曲データ（歌詞データ、演奏データ、映像データ等））を記憶しており、公衆電話回線等の通信ネットワーク３を介してカラオケ装置１ａに対して、これらのファイルを送信する機能を備える。なお、ホストコンピュータ２は、ファイルを、ファイル名・ファイルの記録ブロック番号・ファイルのＣＲＣ値等のファイル属性データと、当該ファイルの記録ブロック番号のブロックに実際に記憶されたデータである実データとで構成して記憶している。そして、ホストコンピュータ２は、公衆電話回線等の通信ネットワーク３を介してカラオケ装置１ａへファイルを送信する。したがって、データとともにファイル属性データが送信されることとなる。
【００２０】
カラオケ装置１ａは、通信ネットワーク３を介してホストコンピュータ２からファイルを取得して、ハードディスク１３へ記憶する。カラオケ装置１ａのハードディスク１３内では、ファイルは、例えば図２に示すようなファイルシステムによって管理している。すなわち、ファイルはハードディスク１３上では固定サイズ（例えば１ｋｂｙｔｅなど）のデータのブロックの集合として記憶しており、各ブロックはＬＢＡ（Logical Block Addressing）番号によって識別するのである。ホストコンピュータ２からファイル受信した場合、ファイルのデータを、ハードディスク１３内でデータが未だ格納されていないＬＢＡ番号の領域に記憶し、ファイル属性データを、ファイル管理領域に記憶する。ファイル管理領域には、データを記憶するＬＢＡ番号の領域の開始番号とその開始番号のブロックから何ブロックがデータを記録した領域かを示すブロック総数とから構成されるブロック群のリストと、ファイル名と、ＣＲＣ値とを関連付けて記憶する。図２に示すファイルの格納例では、ＬＢＡ番号の１番から３番までの領域をファイル管理領域としており、４番以降をデータ領域として用いている。ＬＢＡ番号の５番、６番、９番、１０番には、すでにデータが格納されているため、データは、ＬＢＡ番号の４番、７番、８番、１１番に記憶している。そして、ファイル管理領域には、この例では、ファイル名として「file.bin」、ファイル状態として「正常」、ＣＲＣ値として「１２３４ｈ」（ｈは１６進数を示す）を記憶している。そして、さらに、ファイル管理領域には、ブロック群のリストを記憶している。すなわち、ブロック群１としてこのファイルのデータを記憶したＬＢＡ領域の開始番号（開始ＬＢＡ）である４番とその開始番号のブロックから何ブロックがデータを記録した領域かを示すブロック総数である１とを記憶している。また、同様に、ブロック群２として、開始ＬＢＡとして７番を記憶しブロック総数として２を記憶している。これはＬＢＡ番号の７番・８番が、連続する領域であるからである。また、ＬＢＡ番号１１番については、ブロック群３として開始ＬＢＡとして１１を、ブロック総数として１を記憶している。なおＣＲＣ値は、ファイルのＣＲＣとしてホストコンピュータ２から受信した値であり、ファイル状態は、ハードディスク１３に記憶したデータを読み出してＣＲＣ値を求め、ホストコンピュータ２から受信したＣＲＣ値と比較した結果である。
【００２１】
そして、カラオケ装置１ａは、ＬＡＮ３０（例えばEthernet（登録商標）ケーブル）によってカラオケ装置１ｂ，１ｃ…と互いに通信可能に構成されており、カラオケ装置１ａは、ハードディスク１３に記憶されたファイルを他のカラオケ装置１ｂ，１ｃ…に送信するファイルサーバ機能を備える。また、カラオケ装置１ｂ，１ｃ…は、カラオケ装置１ａと同様に自己のハードディスクに記憶されているファイルを他のカラオケ装置へ送信するファイルサーバ機能を備える。そして、各カラオケ装置は、他のカラオケ装置からファイルを受信して自己のハードディスクに記憶するクライアント機能を備える。
【００２２】
カラオケ装置１ａには、図１に示すように、ホストコンピュータ２に通信ネットワーク３を介して接続し各種の情報を送受信する通信装置１９、曲の予約などを行う操作パネル等の入力装置１０、カラオケ装置１ａ全体の制御を司るＣＰＵ１４、各種情報を一時的に記憶するＲＡＭ１５、演奏の再生を行う音源再生装置１８、音楽情報にかかる電気信号を増幅等するアンプ２０、アンプ２０からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ２２、利用者の歌声等をアンプ２０に入力するためのマイクロフォン（以下、単にマイクと称す。）２３、ＥＥＰＲＯＭ１２、カラオケ用の音楽情報や画像情報その他各種情報を記憶しているハードディスク１３、画像情報等を映像化するための映像再生装置２４、画像情報である背景画及び歌詞等を表示する表示装置２６、およびＬＡＮ３０に接続するためのネットワークインターフェース１７を備えている。この内、操作パネル１０、ＥＥＰＲＯＭ１２、ハードディスク１３、ＲＡＭ１５、ネットワークインターフェース１７、音源再生装置１８及び映像再生装置２４は、ＣＰＵ１４に接続されている。
【００２３】
なお、他のカラオケ装置１ｂ，１ｃ…は通信装置１９を備えないだけで、他の構成は備えているため、ここではカラオケ装置１ａのみの説明をし、他のカラオケ装置１ｂ，１ｃ…の構成についての説明は省略する。
【００２４】
上述した通信装置１９は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１４の制御の下、通信ネットワーク３を通じてホストコンピュータ２にアクセス可能に構成されている。それによって、通信装置１９は、通信ネットワーク３を介してホストコンピュータ２から送られてくるファイルを受信したり、データをホストコンピュータ２に伝送することができる。
【００２５】
また、入力装置１０は、利用者によって操作されるものであり、任意の曲の選択、演奏音のキーの調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うため操作部と例えば選択された曲番号等を表示するための表示部（図示せず）を備えている。利用者は、その操作部を操作することによって、再生する曲をカラオケ装置１ａに予約登録することができる。
【００２６】
また、ＥＥＰＲＯＭ１２にはシステムプログラムや各種の設定に必要な設定データなどが記憶されている。
また、ハードディスク１３には、音楽情報や画像情報、ＣＰＵ１４にカラオケ演奏を実行処理させるための演奏プログラム、演奏記録などのログデータなどが上述したファイルとして記憶されている。そして、操作パネル１０の操作部を介して曲が選択されると、ＣＰＵ１４は、歌詞データのファイル、映像データからなる画像情報のファイル、および演奏データからなる音楽情報のファイルをハードディスク１３から呼び出して、映像再生装置２４および音源再生装置１８に同期させて出力する演奏処理を行う。なお、ハードディスク１３には、識別情報としての曲番号に対応して演奏データや歌詞データ等が記憶されている。
【００２７】
そして、ハードディスク１３に記憶されたプログラムは、カラオケ装置１ａの電源投入時に、ハードディスク１３からＲＡＭ１５に読み出されてＣＰＵ１４が実行可能に構成されている。
【００２８】
ＣＰＵ１４から出力される演奏データは、音源再生装置１８において、アナログの演奏音信号に変換された後、アンプ２０へ送られて電気的に増幅される。このアンプ２０は、マイク２３を介して入力される利用者（歌唱者）の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ２０からスピーカ２２に出力され、音声及び演奏音となってスピーカ２２から外部へ出力される。
【００２９】
一方、映像再生装置２４は、ＣＰＵ１４の制御の下、ハードディスク１３から読み出された画像情報のファイルに基づく画像の再生を行うものである。それにより、ＣＰＵ１４により出力される歌詞データは、映像再生装置２４において映像データと合成され、表示装置２６の画面に背景映像とともに歌詞テロップが表示されるようになっている。
【００３０】
このような構成のため、利用者は、表示装置２６に表示される歌詞テロップを参照しながら、スピーカ２２より流れるカラオケ演奏にあわせ、マイク２３を使って歌唱できる。
また、カラオケ装置１ａは、ＣＰＵ１４が、ハードディスク１３に記憶されたプログラムをＲＡＭ１５にロードしてこのプログラムを実行することで、上述したホストコンピュータ２からのファイルの取得処理を行う。さらに、上述のように、ハードディスク１３に記憶されているファイルを他のカラオケ装置１ｂ，１ｃ…に送信するファイルサーバ処理も行う。このファイルサーバ処理は、ＬＡＮ３０に接続されたカラオケ装置１ｂ，１ｃ…からのファイルのリクエストに応じて、リクエストされたファイルをハードディスク１３から読み出してネットワークインターフェース１７を制御してＬＡＮ３０を介してリクエスト元のカラオケ装置へ送信する処理である。
【００３１】
例えば、カラオケ装置１ｂ〜１ｃは、それぞれ自己のカラオケ装置のハードディスクに未だ記憶されていない曲に対して、利用者からのカラオケ演奏の指示が入力された場合には、ＬＡＮ３０を介してカラオケ装置１ａに対して、この曲データの配信データのファイルをリクエストする処理を行う。カラオケ装置１ａは、上述したファイルサーバ処理によって、ＬＡＮ３０に接続されたカラオケ装置１ｂ，１ｃ…からのリクエストがあった場合、リクエストされた曲に関するファイルを、ハードディスク１３から読み出してネットワークインターフェース１７を制御してＬＡＮ３０を介してリクエスト元のカラオケ装置へ送信する。リクエスト元のカラオケ装置は、この曲の配信データのファイルを受信して自己のハードディスクに記憶して、その曲のファイルを自己のハードディスクから読み出して演奏を行う演奏処理を開始する。
【００３２】
また、カラオケ装置１ａは、ハードディスク１３に記憶されたファイルの正当性を保証するために、配信データのファイルのＣＲＣチェック処理を定期的に行い、かつ、ファイル読み出しの高速化を目的としてファイルを一連の連続したブロックにまとめるデフラグ処理を定期的に行う。
【００３３】
ＣＲＣチェック処理は、ファイルのデータからＣＲＣ値を求め、ファイル管理領域に記憶されたＣＲＣ値と一致するか否かを判定し、一致しない場合には、そのファイル状態を異常としてハードディスク１３のファイル管理領域に記憶する処理である。例えば、図２に示したファイル名「file.bin」のファイルについて、ＬＢＡ番号４，７，８，１１に記憶されたデータのＣＲＣ値を求め、ファイル管理領域に記憶されたＣＲＣと一致するか否かを判定し、一致しない場合には、ファイル管理領域のファイル状態を「異常」に変更してハードディスク１３に記憶する。なお、ファイル状態が「異常」としてハードディスク１３に記憶されているファイルは、ＣＰＵ１４のアイドル時に、通信装置１９を制御して、通信ネットワーク３を介してホストコンピュータ２から再取得して記憶しなおす再取得処理を行う。
【００３４】
デフラグ処理は、ハードディスク１３に記憶されたファイルを構成するブロックの再配置を行う処理である。すなわち、ファイルはハードディスク１３上では固定サイズ（例えば１ｋｂｙｔｅなど）のデータのブロックの集合として実現されているので、ファイルに対する変更を繰り返すと、ファイルの構成要素たるブロックは、図２に示したように複数の分散したブロック群として記録せざるを得なくなる場合が発生する。このような状態ではファイルの全データをリードする場合に、ブロック群境界で次のブロック群を検索するシーク動作が起こる。そのため、単一の連続したブロック群で構成される場合よりも読み出しにかかる時間が大きくなってしまう。そこで、これを防ぐために、ファイルのデータを連続したブロック群に再配置する処理がデフラグ処理である。例えば、図２のように記憶されたブロック群を、図３のように連続したブロック群に再配置する。なお、ＣＲＣチェック処理及びデフラグ処理を含むすべての処理は、ＣＰＵ１４が、ハードディスク１３に記憶されたプログラムをＲＡＭ１５にロードして実行することで行われる。
【００３５】
また、カラオケ装置１ａはハードディスク１３に、オペレーティングシステムを記憶しており、ＣＰＵ１４が、ハードディスク１３に記憶されたオペレーティングシステムをＲＡＭ１５にロードして実行する。このオペレーティングシステムの一部に、ファイルを管理するファイル管理処理を行うファイルシステムを備える。このファイルシステムは、オープン中のファイルを図４に示すようなロックテーブルを用いてアクセスの排他制御をするファイル管理処理を行う。すなわち、オープン中のファイルについて、ファイルのオープンが単一のプロセスのみから可能であるようにロックすることによって、リード中のファイルの変更などの問題を回避するものである。このロックテーブルには、ファイルのオープンがどのような用途であるかをロック属性として記録する。ロック属性としては、一般アクセス（図４に示すようにロックテーブル上ではuserと記憶される）と管理アクセス（図４に示すようにロックテーブル上ではcontrolと記憶される）とがある。管理アクセスは、管理プロセスからのアクセスであり、一般プロセスは、管理プロセス以外のプロセスからのアクセスである。管理プロセスは、ＣＲＣチェック処理及びデフラグ処理のプロセスであり、一般プロセスとは、それ以外の処理（例えば、演奏処理、再取得処理、ファイルサーバ処理など）のプロセスである。各プロセスは、予め設定されたプロセスＩＤを、そのプロセスの生成時にオペレーティングシステムに渡し、オペレーティングシステムは、このプロセスＩＤを実行中のプロセスＩＤとしてプロセスの終了要求がそのプロセスからあるまでＲＡＭ１５上のロックテーブルに記憶しておく。例えば、デフラグ処理はプロセスＩＤとしてdeflag、ＣＲＣチェック処理は、プロセスＩＤとしてcheckとして設定している。オペレーティングシステムは、管理プロセスからファイルへの管理アクセスの要求があった場合には、図４に示すように、管理アクセスの要求があったファイルのファイル名と、その管理アクセスを要求してきたプロセスが管理プロセスの場合にはそのプロセスＩＤと、管理プロセスからのアクセスか、一般プロセスからのアクセスかを示す情報であるロック属性とを関連付けてロックテーブルに記録する。また、オペレーティングシステムは、各プロセスに対してシグナルやメッセージを送信することができる。例えば他のプロセスへクローズ要求のメッセージを送信し、他のプロセスはクローズ要求のメッセージを受けた場合に、ファイルをクローズする。
【００３６】
上述したオペレーティングシステムのファイルシステムにおけるファイル管理処理において、プロセスからファイルのオープン要求があった際に実行されるファイル管理処理について図５に示して説明する。
【００３７】
ファイルのオープンがプロセスから要求されると、本ファイルシステムは、図５に示すようなアルゴリズムにしたがってファイルのアクセスを開始する。なお、ファイルのオープンの要求は、オープンするファイルのファイル名を指定してプロセスから行われる。
【００３８】
まず、図５に示すように、図４に示したロックテーブル上でオープンするファイルのファイル名を検索する（Ｓ１１０）。そして、すでにそのファイルがロックされているか否かを、ロックテーブル上にそのファイルのファイル名が存在するか否かによって判定する（Ｓ１２０）。すでにロックされている場合、すなわち、そのファイル名がロックテーブル上に存在する場合には（Ｓ１２０：はい）、Ｓ１３０へ移行し、未だロックされていない場合、すなわち、そのファイル名がロックテーブル上に存在しない場合には（Ｓ１２０：いいえ）、Ｓ１７０へ移行する。
【００３９】
Ｓ１３０では、controlオープンか否かを判定する。つまり、管理プロセスからのアクセス要求か否かを判定する。controlオープンの場合（管理プロセスからのアクセス要求の場合）（Ｓ１３０：はい）、Ｓ１６０へ移行して一定時間待った後、Ｓ１１０へ戻る。このようにして、すでにロックされているファイルに対して管理プロセスからオープンの要求があった場合、一定時間待つ。一方、controlオープンでない場合（一般プロセスからのアクセス要求の場合）（Ｓ１３０：はい）、Ｓ１４０へ移行する。
【００４０】
Ｓ１４０では、controlロックか否か、すなわち、図４に示したロックテーブルにおいて、オープンを要求されたファイル名に関連付けられたロック属性がcontrolか否かを判定する。controlロックの場合、すなわち、ロックテーブルにおいてそのファイル名に関連付けられたロック属性がcontrolの場合（Ｓ１３０：はい）、Ｓ１５０へ移行し、Ｓ１５０では、ロックプロセスに開放を要求する。つまり、そのファイル名に関連付けられたプロセスＩＤのプロセスに対してファイルのクローズ要求のメッセージを送る。そして、Ｓ１６０へ移行して一定時間待った後、Ｓ１１０へ戻る。一方、controlロックでない場合、すなわち、そのファイル名に関連付けられたロック属性がcontrolでない場合（Ｓ１３０：はい）、Ｓ１６０へ移行して一定時間待った後、Ｓ１１０へ戻る。このようにして、ファイルのオープンが管理プロセス以外のプロセス（一般プロセス）から要求された場合であって（Ｓ１３０：いいえ）、そのファイルがすでに管理プロセスによってオープンされてロックされている場合には（Ｓ１４０：はい）そのロックをしている管理プロセスに対してロックの開放を要求し、ファイルをクローズさせる。そして、クローズされた場合には、Ｓ１２０の判定でＳ１７０へ移行することとなる。この管理プロセスにおけるファイルのクローズ処理等については、後で図６、図７を参照して説明する。
【００４１】
Ｓ１７０では、プロセスからオープンが要求されたファイルをロックする。すなわち、ロックテーブルに、プロセスからオープンが要求されたファイル名を格納し、そのファイル名に対応付けて、ロック属性を記憶する。ロック属性は、ファイルオープン要求時に、「control」すなわち管理プロセスからのアクセス（管理アクセス）、「user」すなわち一般プロセスからのアクセス（一般アクセス）の種別が要求元から示される。
【００４２】
続くＳ１８０では、controlオープンか否かを判定する。controlオープンの場合（Ｓ１８０：はい）、Ｓ１９０へ移行してプロセスＩＤをそのファイル名に関連付けてロックテーブルに記憶する。すなわち、図４に示すように、デフラグ処理のプロセスからファイルのオープンの要求があった場合には「deflag」を記憶し、ＣＲＣ処理のプロセスからオープンの要求があった場合には「check」を記憶する。そして、この処理を終了する。一方、Ｓ１８０でcontrolオープンでない場合、すなわち、ファイルのオープンを要求してきたプロセスのプロセスＩＤがdeflagまたはcheckではない場合（Ｓ１８０：いいえ）、この処理を終了する。このようにしてロックテーブルが構成される。
【００４３】
次に、プロセスＩＤがchekckであるＣＲＣチェックプロセスにおけるＣＲＣチェック処理の流れを図６に、プロセスＩＤがdeflagであるデフラグプロセスにおけるデフラグ処理の流れを図７に示して説明する。
【００４４】
ＣＲＣチェック処理は、例えば１日１回のように所定の時間経過する毎に実行される。また、デフラグ処理は、後述するようにＣＲＣチェック処理内から実行が開始される。
ＣＲＣチェック処理について、図６を参照して説明する。
【００４５】
図６に示すように、まず、ファイルをcontrolオープンする（Ｓ３１０）。すなわち、ファイル名を指定してファイルのオープンをオペレーティングシステムに対して要求する。そして、上述の図５に示したファイルシステムの処理によって、ファイルがオープンされた場合、Ｓ３２０へ移行する。
【００４６】
続くＳ３２０では、ハードディスク１３から、そのファイルを１ブロック分読み出す。
続くＳ３３０では、オペレーティングシステムからクローズが要求されたか否かを判定する。クローズが要求されていない場合には（Ｓ３５０：いいえ）、Ｓ３６０へ移行する。Ｓ３６０では、最終ブロックか否かを判定し、最終ブロックの場合には（Ｓ３６０：はい）、Ｓ３７０へ移行する。一方、最終ブロックでない場合には（Ｓ３６０：いいえ）、次のブロックを読み出し対象のブロックにセットしてＳ３２０へ移行する。一方、Ｓ３３０で、クローズが要求がされたと判定された場合には（Ｓ３５０：はい）、Ｓ３９０へ移行する。
【００４７】
Ｓ３７０では、Ｓ３４０で計算されたＣＲＣ値とファイル管理領域に記憶されたＣＲＣ値とを比較し、双方のＣＲＣ値が合致するか否かを判定する。合致する場合には（Ｓ３７０：いいえ）、Ｓ３９０へ移行し、合致しない場合には（Ｓ３７０：はい）Ｓ３８０へ移行してファイル管理領域のファイル状態を「異常」に変更してＳ３９０へ移行する。
【００４８】
Ｓ３９０では、ファイルをクローズする。
そして、続くＳ４００では、このファイルが複数のブロック群からなるファイルであるか否かファイル管理領域ブロック群のリストに基づいて判定し、複数のブロック群からなる場合には（Ｓ４００：はい）、Ｓ４１０へ移行してデフラグプロセスにこのファイルがデフラグ処理の対象のファイルである旨を通知する。なおデフラグプロセスが起動していない場合には、デフラグプロセスを起動する。
【００４９】
このようにして、ＣＲＣを計算する処理の途中で、オペレーティングシステムからのクローズ要求が合った場合（Ｓ３５０：はい）、ＣＲＣのチェック処理を即座に中止して（Ｓ３５０：はい）、ファイルをクローズすることができる。したがって、一般プロセスからこの管理アクセス中のファイルに対するアクセス要求があった場合に、即座に一般プロセスによるファイルのオープンを行うことができる。
【００５０】
次に、デフラグ処理について、図７を参照して説明する。
図７に示すように、まず、ファイルをcontrolオープンする（Ｓ５１０）。すなわち、ファイル名を指定してファイルのオープンをオペレーティングシステムに対して要求する。そして、上述の図５に示したファイルシステムの処理によって、ファイルがオープンされた場合、Ｓ５２０へ移行する。
【００５１】
Ｓ５２０では、全ブロック群と等しいサイズの連続したブロックを取得する。例えば、図２に示すファイルをデフラグ処理する場合、全ブロック数は、４であるので、４つの連続したブロックを取得する。例えば、ＬＢＡ番号１２，１３，１４，１５の４つの連続したブロックを取得する。
【００５２】
続く、Ｓ５３０では、１ブロック分のデータをＳ５２０で確保した領域へコピーする。
そして、続くＳ５４０では、オペレーティングシステムからクローズが要求されたか否かを判定する。クローズが要求されていない場合には（Ｓ５４０：いいえ）、Ｓ５５０へ移行する。Ｓ５５０では、最終ブロックか否かを判定し、最終ブロックの場合には（Ｓ５５０：はい）、Ｓ５６０へ移行し、ブロック群情報を書き換える。例えば、図３に示すように、図２のファイルのＬＢＡ番号４のブロックをＬＢＡ番号１２のブロックへコピーし、ＬＢＡ番号７のブロックをＬＢＡ番号１３のブロックへコピーし、ＬＢＡ番号８のブロックをＬＢＡ番号１４のブロックへコピーし、ＬＢＡ番号１１のブロックをＬＢＡ番号１５のブロックへコピーした場合には、ブロック群１の開始ＬＢＡとして１２を、ブロック総数として４をファイル管理領域に記憶する。そして、Ｓ５８０へ移行する。一方、最終ブロックでない場合には（Ｓ５５０：いいえ）、次のブロックをコピー対象のブロックにセットしてＳ５３０へ移行する。
【００５３】
また、Ｓ５４０で、クローズが要求がされたと判定された場合には（Ｓ５４０：はい）、Ｓ５７０へ移行する。
Ｓ５７０では、Ｓ５２０で取得したブロック群を解放する。
【００５４】
そして、Ｓ５８０では、このファイルをクローズする。
このようにして、デフラグ処理の途中で、オペレーティングシステムからのクローズ要求があった場合（Ｓ５４０：はい）、デフラグ処理を即座に中止して（Ｓ５４０：はい）、ファイルをクローズすることができる（Ｓ５８０）。したがって、一般プロセスからこの管理アクセス中のファイルに対するアクセス要求があった場合に、即座に一般プロセスによるファイルのオープンを行うことができる。例えば、図６に示したＣＲＣチェック処理中あるいは図７に示したデフラグ処理中のファイルの取得要求が、他のカラオケ装置からあった場合には、即座にそのファイルに対するＣＲＣチェック処理またはデフラグ処理を中止して、他のカラオケ装置に対してそのファイルを提供することができる。
【００５５】
例えば、カラオケ装置１ｂにおいて、自己ハードディスクに未だ記憶されていない曲に対して、利用者からのカラオケ演奏の指示が入力された場合には、ＬＡＮ３０を介してカラオケ装置１ａに対して、この曲データの配信データのファイルをリクエストする。カラオケ装置１ａは、例えば、ＣＲＣチェック処理やデフラグ処理中であっても、カラオケ装置１ｂからリクエストされた曲に関するファイルを、即座に、ハードディスク１３から読み出してカラオケ装置１ｂへ送信することができる。したがって、カラオケ装置１ｂでは、ユーザからの要求に従来よりも早く対応して、演奏処理を開始することができる。
【００５６】
なお、本実施例では、デフラグ処理について、図７に示したように、最終ブロックまでコピーした後で（Ｓ５５０：はい）、ブロック群情報を書き換えることとしたが、図８に示すように、１ブロックコピーする毎に（Ｓ５３０）、ブロック群情報を書き換えるようにしてもよい。このようにすれば、例えば、図２のファイルのＬＢＡ番号４のブロックをＬＢＡ番号１２のブロックへコピーし、ＬＢＡ番号７のブロックをＬＢＡ番号１３のブロックへコピーし、ＬＢＡ番号８のブロックをＬＢＡ番号１４のブロックへコピーした状態で、オペレーティングシステムからクローズ要求された場合（図８のＳ５４０：はい）、その時点で取得したブロック群を解放して（Ｓ５７０）、ファイルをクローズすることができる（Ｓ５８０）。このとき、ファイル管理領域は、図９に示す状態となる。
【図面の簡単な説明】
【００５７】
【図１】実施例のカラオケ装置の概略構成を示すブロック図である。
【図２】ファイルの格納状態の例を示す説明図である。
【図３】図２のファイルに対してデフラグ処理を行った後のファイルの格納状態の例を示す説明図である。
【図４】ファイル管理テーブルの説明図である。
【図５】オペレーティングシステムにおけるファイル管理処理の流れを示すフローチャートである。
【図６】プロセスＩＤがchekckであるＣＲＣプロセスにおけるＣＲＣチェック処理の流れを示すフローチャートである。
【図７】プロセスＩＤがdeflagであるデフラグプロセスにおけるデフラグ処理の流れを示すフローチャートである。
【図８】デフラグ処理の別例を示すフローチャートである。
【図９】図８の処理中にクローズ要求された際のファイルの格納状態の例を示す説明図である。
【符号の説明】
【００５８】
１ａ，１ｂ，１ｃ…カラオケ装置、２…ホストコンピュータ、３…通信ネットワーク、１０…入力装置、１２…ＥＥＰＲＯＭ、１３…ハードディスク、１４…ＣＰＵ、１５…ＲＡＭ、１７…ネットワークインターフェース、１８…音源再生装置、２０…アンプ、２２…スピーカ、２３…マイクロフォン、２４…映像再生装置、２６…表示装置。
【図１】
2005056245.tif 000003
【図２】
2005056245.tif 000004
【図３】
2005056245.tif 000005
【図４】
2005056245.tif 000006
【図５】
2005056245.tif 000007
【図６】
2005056245.tif 000008
【図７】
2005056245.tif 000009
【図８】
2005056245.tif 000010
【図９】
2005056245.tif 000011