JP4219299B2 - 記録デバイスのキャッシュ方法及びデータ記録装置 - Google Patents

Description

本発明は、ファイルシステムを介してデータを記録する際、転送レートを保証できる記録デバイスのキャッシュ方法とそのデータ記録装置に関する。

メモリカードやハードディスク、光ディスクなどの記録媒体では、データはセクタと呼ばれる単位（例えば５１２バイト）でリード／ライトされる。これらの記録媒体をパーソナルコンピュータ（以下、ＰＣと略す）や携帯機器に接続してファイルを記録させる際には、ファイルシステムにより管理領域を除くデータはクラスタと呼ばれる単位（例えば４Ｋバイト,３２Ｋバイト等）でリード／ライトされる。

ファイルシステムの代表的なものには、ＦＡＴ（Standard ECMA-107: Volume and File Structure of Disk Cartridges for Information Interchange）がある。ファイルシステムの動作は複雑であるため、ＰＣや携帯機器にオペレーティングシステム（以下、ＯＳと略す）を搭載して、ソフトウェアとしてファイルシステムを実装するのが一般的である。

ファイルシステムフォーマットの一例として、ＦＡＴフォーマットを図４５を参照して説明する。メモリカードやハードディスク等の物理ドライブ６００は、一般的に、領域の先頭に置かれるマスターブートレコード６０２と１個以上の論理ドライブ６０１とから構成される。１個の論理ドライブ６０１は、１種類のファイルシステムでフォーマットされる。ＦＡＴフォーマットの場合、領域の先頭からパーティションブートセクタ６０３、ファイルアロケーションテーブル（ＦＡＴ）６０４、ＦＡＴのバックアップ６０４ｂ、ルートディレクトリエントリ６０５というシステム領域が順次配置され、システム領域の後にユーザデータ領域６０６が配置される。

パーティションブートセクタ６０３には、パーティションのセクタ数やクラスタサイズといったパーティションを起動するのに必要な情報が記録される。ＦＡＴ６０４には、ファイルの記録情報が配置される。ルートディレクトリエントリ６０５は、ルートディレクトリに置かれているファイル又はフォルダの情報がエントリとして記録される。エントリの情報には、ファイルのデータが置かれる先頭のクラスタ番号が含まれる。ユーザデータ領域６０６には、ファイルのデータ自体が置かれる。

ＦＡＴ６０４に配置されるファイルの記録情報について、図４６を参照して説明する。ＦＡＴ６０４は、ユーザデータ領域６０６上のクラスタを管理するためのテーブルである。ＦＡＴ６０４には、ファイルの次のデータが存在するクラスタ番号が１２ビットや１６ビットといった単位で記録される。図４６に示すように、ユーザデータ領域６０６に記録するファイル３１０を部分データ２１２に分けてクラスタ番号３,４,７のクラスタに記録する場合、ＦＡＴ６０４にはクラスタを連結するための情報として、クラスタ番号３の位置に４が記録され、クラスタ番号４の位置に７が記録される。最後にクラスタ番号７の位置に終了マークが記録される。ファイル３１０における先頭のクラスタ番号３は、前述のようにファイル３１０のエントリに記録される。

図４５のＦＡＴファイルシステムにおけるファイルの記録処理６５０を図４７のフローチャートを参照して説明する。ファイルの記録処理６５０が開始されると、まずファイルを構成する部分データを内部バッファに読み込むステップ６５１を行う。部分データの大きさは、ファイルシステムドライバの構造やファイルを記録する状況により異なる。次に、転送先の空き領域の検索ステップ６５２を行う。ファイルは、クラスタに分割されて記録されるため、空き領域はクラスタ単位で検索される。空き領域の検索は、クラスタを管理するＦＡＴ６０４を参照して行われる。空き領域が検索されると、ＦＡＴとディレクトリエントリの更新ステップ６５３を行う。

上記ファイルの記録処理６５０では、予めＦＡＴ領域とディレクトリエントリを確保しておくことにより、他のプロセスから同じ領域にアクセスされることによる危険を回避できる。クラスタ単位の記録処理の実行ステップ６５４では、クラスタ単位に分割されたデータが記録される。内部バッファに蓄積された部分データの記録が完了したかどうかはステップ６５５で判定される。以上の動作をファイルの記録が完了することをステップ６５６で判定するまで繰り返し行われる。

半導体メモリカードは、一般に１個以上のフラッシュメモリで構成される。フラッシュメモリはメモリセルと呼ばれる最小単位でデータを保持する。一般に、一定数のメモリセルが１個のページを形成し、一定数のページが１個の物理ブロックを形成する。データの消去動作は、フラッシュメモリの特性に基づいて、消去ブロックと呼ばれる物理ブロックに相当する単位（例えば６４Ｋバイト、１２８Ｋバイト等）で行われる。フラッシュメモリ上で物理的に消去可能なブロックの最小単位（消去可能な最小ブロック）は消去ブロックより小さい（例えば１６Ｋバイト等）ことがある。しかしながら、最近のメモリカードの大容量化に伴い、管理領域と検索効率の向上などの理由から消去時のデータの退避は消去可能な最小ブロックでは行えない場合が多い。

フラッシュメモリは、その特性上、記録されているデータの上から新たなデータを上書きするというオーバーライト動作ができない。そのため、データの書き込みには消去動作を伴うことになる。しかしながら、フラッシュメモリの消去動作はリード／ライト動作と比較して莫大な時間を要する。このような理由により、書き込むデータの目標とする論理アドレスに対応する物理ブロックは、消去動作を必要としない物理ブロックに対応付けが変更されたうえで書き込まれ、消去動作は後で行うのが一般的である。

ファイルをメモリカードに記録する場合、通常、図４８に示すようにファイルの記録単位であるクラスタ２１０とメモリカードの消去ブロック１０５とは合致していない。そのため図４９に示す状態が発生することがある。すなわち、ファイルシステム２０１があるクラスタに割り当てたデータＡをメモリカード１００に転送し終えた後に時間を空けてデータＢの転送する処理が実施されることがある。その場合、消去動作を回避するためにデータＢは、物理アドレス上ではデータＡと異なる消去ブロックに記録されてしまうことがある。このような動作が繰り返されると、メモリカード上に消去ブロック間に跨ったデータや消去ブロックに満たないデータの数が増加する。これにより、空き容量の割りに書き込める消去ブロックの数が少なくなり、空き容量の検索処理が増加したり物理上に分断されるデータが増加したりして、その結果として、ライト処理時間が継続的に増加する、という現象が起こる。

特にファイルシステムを用いた記録の場合、ファイルシステムの持つ独特のキャッシュ機構やデバイスドライバ等に起因する理由により、Ｉ／Ｏ要求が分断されたり、ファイルシステム特有のＩ／Ｏ要求が両者の間に挟まったりすることが多い。そのため、データＡとデータＢとが同一のファイルに属するデータであったとしても、上述した現象の発生頻度はより一層高くなる。

このような記録パフォーマンスの劣化対策として、従来からいくつかの構成が提案されている。

第１の構成では、クラスタの境界と消去可能ブロック（記録の単位）の境界を合致させることにより、上記劣化を低減させている（例えば、特許文献１参照）。

第２の構成では、ファイルシステムを消去ブロックに対応させて動作させることでこのような現象を回避させている（例えば、特許文献２参照）。第２の構成は、リアルタイムファイルは消去ブロック単位に記録し、非リアルタイムファイルはクラスタ単位に記録するファイルシステムにしている。これにより、リアルタイムファイルに対して高速な記録動作を実現することができる。
特開２００１−１８８７０１号公報（図１２） 特開２００３−３０８２４０号公報（図７） Standard ECMA-107: Volume and File Structure of Disk Cartridges for Information Interchange

第１の構成には次のような課題がある。一般に、データの記録においてはクラスタサイズより消去ブロックサイズの方が大きい。そのため、第１の構成において、消去ブロックに満たないサイズのデータが多く書き込まれたり、消去ブロックに合わないサイズのデータが多く書き込まれたりした場合には、記録時のパフォーマンス劣化を低減させることはできない。特に、ＰＣにおける標準的なファイルシステムにおいては、Ｉ／Ｏ要求のサイズは消去ブロックサイズより小さい値に限定されているものが多く、それらに対して第１の構成では、記録時のパフォーマンスの劣化を低減させることは困難である。

第２の構成では、ファイルシステムを独自にすることで独自のＡＰＩ（Application Program Interface）が必要となる。そのため、ＰＣで既存アプリケーションを稼動させている状態でこの対策を実施することができない、といった実施上の制限がある。

このような課題は以下の用途に半導体メモリカードを用いる場合に顕著となる。昨今、半導体メモリカードは、放送・業務用カメラレコーダ等の品質と信頼性が要求される用途に利用されつつある。このような用途においては、記録レートの保証は重要なこととなる。

しかしながら、カメラレコーダで撮影した映像及び音声をＡＶファイルとしてメモリカードに記録する際、編集作業でＰＣのファイルシステムを介して記録された経歴のある半導体メモリカードでは、上述した記録パフォーマンスの劣化,すなわち、図４９に示すように、転送レートの低下が発生することがあり、そうすると、リアルタイム記録が保証できなくなってしまう。

上記課題を解決するために、本発明のメモリカードおよびデータ記録装置は、メモリカードにファイルを記録する際、ＣＰＵによりファイルシステムドライバ及びデバイスドライバを動作させ、デバイスドライバは、メモリカードに記録される全てのデータを消去ブロックで区切ることで複数の部分データに分割してからピンポンバッファに保持し、消去ブロックに一致する部分データはそのまま消去ブロックで、また消去ブロックに満たないデータは不足分を読み出して消去ブロックにしてから、メモリカードに書き込むものである。

メモリカードにデータを書き込む際、消去ブロックにアライメントされないデータを多く書き込むことにより起こる転送速度の劣化を防止し、メモリカードへの転送レートを保証することができる。

以下、本発明の実施の形態について、図１から図４４を参照して説明する。

第１の参考例
本発明の第１の参考例であるデータ記録装置１０１の構成を図１に示す。データ記録装置１０１は、ＰＣ（パーソナルコンピュータ）１０２により構成される。ＰＣ１０２は、少なくともメモリカード１００を装填するためのメモリカードスロット１９０を有する。但し、メモリカードスロット１９０の代わりに外付けドライブ１９１を接続しても良い。ＰＣ１０２は、ディスプレイ１９２や入力装置１９３を有するがこれらはなくともよい。

データ記録装置１０１は、図２に示すように、少なくともＣＰＵ１８１、メモリ１８２、プログラムやオペレーションシステム（以下ＯＳ）を格納するハードディスク等の記憶デバイス１８３、それらを接続する内部バス１８４、メモリカード１００を接続するためのバスコントローラ１８５から構成される。メモリカード１００の接続形態としては、例えばＡＴＡ（AT Attachment）、ＵＳＢ（Universal Serial Bus）がある。また多くの場合、データ記録装置１０１は、ディスプレイ１９２を接続するためのグラフィックコントローラや、入力装置１９３を接続するための入力デバイスコントローラ１８６を備える。オペレーションシステム（以下、ＯＳと略す）としては、例えばＷｉｎｄｏｗｓ（登録商標）やＭａｃ ＯＳ（登録商標）などの汎用ＯＳを用いることができる。

データ記録装置１０１において、ＯＳのプログラム２５０、デバイスドライバのプログラム１１０、ファイルシステムドライバのプログラム２００、アプリケーションプログラム３００は記憶デバイス１８３に記録されている。データ記録装置１０１の電源が起動されると、記憶デバイス１８３に格納されたＯＳ２５０が起動する。デバイスドライバのプログラム１１０、ファイルシステムドライバのプログラム２００は、ＯＳ２５０の起動時もしくはメモリカード１００の装填時にメモリ１８２上にロードされる。デバイスドライバ１１０及びファイルシステムドライバ２００は、メモリカード１００に対してファイル入出力を行うのに必要な機能を有する。但しこれらドライバ１１０、２００は、メモリカード１００だけでなく、ハードディスクや光ディスクなどの記録媒体へのファイル入出力に用いても良い。

ユーザがメモリカード１００をデータ記録装置１０１に接続すると、ＯＳ２５０はプラグアンドプレイ機能によりメモリカード１００を認識し、デバイスドライバ１１０をメモリ１８２上にロードする。ファイルシステムドライバ２００は、デバイスドライバ１１０を経由してメモリカード１００上のファイルフォーマットを認識し、論理ドライブとしてマウントする。ユーザはＯＳ２５０上でアプリケーションプログラム３００を起動して入力装置１９３を操作することにより、メモリカード１００にデータを読み書きすることができる。

デバイスドライバ１１０の処理の全体構成を、図３に示す。デバイスドライバの処理１１１は、要求の受付処理１２４、ロード処理１７０、アンロード処理１７９、要求処理スレッド１５５、タイマーライト起動スレッド１６０から構成される。

ロード処理１７０およびアンロード処理１７９は、ＯＳ２５０がデバイスドライバ１１０をメモリ１８２上にロードまたはアンロードする際に、それぞれ実行される。スレッドとは、ＯＳ２５０がマルチタスクを並行して処理する際の１個のプログラムの流れである。デバイスドライバにおけるスレッドは、ロード処理１７０の実行時に起動され、アンロード処理１７９の実行時に削除される。

要求の受付処理１２４は、デバイスドライバ１１０がＯＳ２５０から何らかの要求を受けた際に実行される。要求の受付処理１２４では、要求が受け付けられた（ステップ１２５）のち、受け付けた要求に対応するデータをキューに挿入して（ステップ１２６）終了する。これにより、デバイスドライバ１１０が要求を処理中に受けた新たな要求は、キューに挿入されて処理の順番になるまで待たされる。

要求処理スレッド１５５は、キューに挿入された要求を逐次処理するためのスレッドである。最初に、スレッドを終了すべきかどうかを判定し（ステップ１５６）、終了すべきであれば終了（ステップ１５９）する。終了すべきでない場合は、１個の要求と対応するデータをキューから取得する（ステップ１５７）。次に要求が第２のライト要求１２２かどうかを判定する（ステップ１５８）。第２のライト要求１２２とは、ファイルシステムドライバ２００からデバイスドライバ１１０に送信するデータのライト要求であって、請求項における要求データを構成する。なお、後述するように、アプリケーション３００からファイルシステムドライバ２００に送信するデータのライト要求を第１のライト要求１２１と呼ぶため、ファイルシステムドライバ２００からデバイスドライバ１１０に送信するデータのライト要求を第２のライト要求１２２と呼ぶ。

ステップ１５８で第２のライト要求１２２でないと判定すればライト以外の操作（ステップ１５０）を行う。第２のライト要求１２２であれば、タイマーライトの要求かどうかを判断し（ステップ１５８Ｂ）、タイマーライトの要求であればタイマーライト操作（ステップ１６６）を、そうでなければライト操作（ステップ１３０）を行う。以上で１個の要求の処理を終了し、スレッド終了判定操作（ステップ１５６）に戻る。なお、タイマーライトの要求（ステップ１５８Ｂ）は、後述するタイマーライト起動スレッド（ステップ１６０）で作成されたライト要求を示す。

デバイスドライバ１１０におけるいくつかの処理は、複数のスレッドによって同時並行して実行され得る。即ち、要求の受付処理１２４、要求処理スレッド１５５、タイマーライト起動スレッド１６０は同時並行で行われる可能性がある。しかし、要求とデータを挿入するキューは１個であり、複数の要求の受付処理１２４が並行して動作した場合でも、各受付処理１２４におけるキューへの挿入操作（ステップ１２６）は逐次処理で行われる。

デバイスドライバのロード処理１７０を図４のフローチャートを参照して説明する。最初にデバイスドライバ１１０のインスタンスをメモリ１８２上にロードする（ステップ１７１）。これにより、デバイスドライバのプログラム１１０をメモリ１８２上から利用可能にする。次に、ロードしたデバイスドライバの初期化操作を行う（ステップ１７２）。これには、ＯＳ２５０にデバイスのインスタンスを登録したり、使用する関数やハンドラを登録する操作が含まれる。

次に消去ブロックサイズを決定する（ステップ１７３）。消去ブロックサイズの決定方法としては、デバイスドライバ１１０内部で固定値を指定する方法や、メモリカード内部に用意されたレジスタに値を設定しておき、デバイスドライバ１１０がコマンドを発行してレジスタ上の値を読み込んで値に応じた消去ブロックサイズを設定する方法がある。

消去ブロックサイズが決定された後、メモリ１８２上にライト処理用のバッファ２６３を確保する（ステップ１７４）。このバッファ２６３は、一時保持器として機能するものであり、少なくとも消去ブロックサイズの連続した領域としてメモリ１８２上に確保される。この例を図５に示す。ＯＳのメモリ空間２６０において、カーネル空間２６１上にライト処理のバッファ２６３を確保する。この例では、消去ブロックサイズを１２８Ｋバイトとしている。バッファ２６３は、デバイスドライバ１１０のアンロード処理１７９において解放される。デバイスドライバ１１０のロード処理１７０及びアンロード処理１７９は、それぞれメモリカード１００をデータ記録装置１０１に接続／取り外しするタイミングで行うのが望ましい。

メモリカード１００に対するファイルのリード／ライト動作を図６を参照して説明する。アプリケーションプログラム３００がファイルのリード／ライトを行う際、カーネル空間プログラムであるファイルシステムドライバ２００がアプリケーション３００からのＩ／Ｏ要求を処理する。

ファイルシステムドライバ２００は図４７を参照して従来例で説明したようなファイルシステムフォーマットに記録するための独自のＩ／Ｏ要求をデバイスドライバ１１０に発行する。デバイスドライバ１１０がバスコントローラ１８５を介してメモリカードコントローラ１０９にコマンドとデータを送ることで、記録媒体（メモリカード１００）へのリード／ライト動作が実行される。

デバイスドライバ１１０とメモリカードコントローラ１０９との間のデータの受け渡しの方法は、ＤＭＡ（Direct Memory Access）とＰＩＯ（Programmed I/O）がある。高速性が要求されるデータのリード／ライトにはＤＭＡを用いる。ＤＭＡは、データ記録装置１０１上のメモリ１８２にメモリカードコントローラ１０９が直接アクセスすることでデータの転送を行う。デバイスドライバ１１０は、メモリ１８２上のアドレスとメモリカード１００上のアドレス、及びデータ長などの転送情報のみをメモリカードコントローラ１０９に指定する。メモリカードコントローラ１０９が転送を行うため、ＣＰＵ１８１の処理能力を有効に活用できる。

次に、本参考例の特徴となるメモリカード１００への記録処理を、図７を参照して説明する。アプリケーションプログラム３００は、ファイル３１０をメモリカード１００に記録するためのライト要求（以下、このライト要求を第１のライト要求と呼ぶ）１２１を実行する。ファイルシステムドライバ２００は、図４７を参照して従来例で説明した処理手順に従って、ファイルをクラスタ２１０の単位で記録する。ファイルシステムドライバ２００は、ファイル３１０を記録するために必要なクラスタ２１０や管理情報を、新たないくつかのライト要求（以下、このライト要求は、前述した第２のライト要求である）１２２としてデバイスドライバ１１０に送信する。なお、図７の例は、４個のクラスタ２１０のデータを１個の第２のライト要求１２２として送信する状態を示している。

第２のライト要求１２２は、元のファイル３１０の記録に必要なデータであっても良いし、同時刻に記録すべき他のファイルのデータを含んでいても良い。

第２のライト要求１２２を受けたデバイスドライバ１１０は、ライト処理１３０を開始する。ライト処理１３０では、デバイスドライバ１１０は、今回メモリカード１００に記録する記録用データを消去ブロック１０５で区切ることで複数の部分データに分割し、消去ブロック１０５に一致する部分データはそのまま消去ブロック１０５で、また消去ブロックに満たない部分データはメモリカード１００から不足分を読み出して消去ブロック１０５の大きさにする。このとき、メモリカード１００から読み出すデータのアドレスは、メモリカード１００に書き込むアドレス位置と同一とする。具体的には、次のようにして記録用データを設定する。すなわち、消去ブロック１０５の整数倍の大きさを有するとともに今回の記録処理でメモリカード１００に記録する記録予定データのアドレス領域が全て含有される最小限の大きさを有するもう一つのアドレス領域をメモリカード１００上に設定する。そのうえで、このもう一つのアドレス領域から、記録するデータのアドレス領域を差し引いた残余のアドレス領域に該当する記録済データをメモリカード１００から読み出して残余のアドレス領域に複写することで消去ブロック１０５の境界に一致する記録用データを設定する。

このようにしてすべての記録予定データを消去ブロック１０５にしてから、そのデータをメモリカード１００に書き込む。デバイスドライバ１１０は、ライト処理１３０を消去ブロック１０５にするために図４のステップ１７４で確保したバッファ（一時保持器）２６３を用いる。

デバイスドライバ１１０によるライト処理１３０の詳細を、図８のフローチャートを参照して説明する。なお、図８のフローチャートでは、互いにステップ位置の異なるステップ１４０Ａとステップ１４０Ｂとが設けられているが、これらのステップの操作内容自体は基本的には同一であって、以降の説明および図面において同一の処理として取り扱われて説明される際にはステップ１４０と記載される。

今回のデータを記録する際のメモリカード１００上のアドレス領域の先頭アドレスと、既にバッファ２６３内にあるデータを記録する際のメモリカード１００上のアドレス領域の終端アドレスとが連続するかどうかを判定する（ステップ１３２）。ここでバッファ２６３内にあるデータとは、デバイスドライバ１１０がキャッシュしているデータであり、以前のライト処理１３０によってバッファ２６３に一時保持されたもののまだメモリカード１００にライトされていないデータである。またアドレスとは、メモリカード１００上の論理アドレス又は物理アドレスである。アドレスが連続しない場合は、バッファ２６３内のデータの消去ブロック１０５のライト操作を行う（ステップ１４０Ａ）。連続する場合は、バッファ２６３内で以前のデータと今回のデータとを連結させるため、消去ブロック１０５内の部分データをバッファ２６３にコピーする（ステップ１３４）。

次に、コピーした部分データがバッファ２６３の終端に到達したかどうかを判定し（ステップ１３５）、到達していなければ終了する。到達していればバッファ２６３内のデータの消去ブロック１０５のライト操作（ステップ１４０Ｂ）を行う。なお、前述したように、ステップ１４０Ａとステップ１４０Ｂとは基本的に同一の処理である。

今回の要求データにおいてまだ処理を終了していない残余のデータがあるかどうかを判定し（ステップ１３６）、残っていればステップ１３４に戻る。残っていなければ終了する。

以上説明したデバイスドライバのライト処理１３０の具体例を説明する。図９〜図１３を参照して説明する。これらの例においてバッファ２６３は、図５で予め確保した領域のアドレスであり、０ｘ２００００バイト即ち１２８Ｋバイトの消去ブロックサイズ分の領域としている。

バッファ２６３内にデータがない場合のライト処理１３０の例を図９に示す。第２のライト要求１２２が、ターゲットアドレス０ｘ８２０００、レングス０ｘＤ０００であるとする。ここでターゲットアドレスとは、メモリカード１００上のアドレスを指す。消去ブロックは０ｘ２００００の倍数であるから、ターゲットアドレスを含む消去ブロックの先頭アドレスは０ｘ８００００となる。バッファ２６３を０ｘ８００００から０ｘＡ００００までの消去ブロック１０５の１個に対応させて、０ｘ８２０００から０ｘＤ０００分のデータをバッファ２６３にコピーする（ステップ１３４参照）。この場合、データはバッファ２６３の終端に到達していないので（ステップ１３５参照）、この第２のライト要求１２２に対応するライト処理１３０を終了する。

今回の第２のライト要求１２２がバッファ２６３内のデータと連続する場合の例を図１０に示す。バッファ２６３にはターゲットアドレス０ｘ８００００からレングス０ｘ２０００の書き込むべきデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ８２０００でレングスが０ｘＤ０００の場合、その要求データはバッファ２６３内のデータと連続するので、ターゲットアドレス０ｘ８００００からレングス０ｘ１００００の書き込むべきデータに更新する（ステップ１３４）。

今回の第２のライト要求１２２がバッファ２６３内のデータと連続しない場合の例を図１１に示す。バッファ２６３にはターゲットアドレス０ｘ６Ｃ０００からレングス０ｘ８０００のデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ８２０００でレングスが０ｘＤ０００の場合、バッファ２６３内のデータと今回の要求のアドレス０ｘ８２０００とは連続しないので、バッファ２６３内のデータを消去ブロック１０５のライト操作（ステップ１４０Ａ）で先に読み出してメモリカード１００に書き込んでから、バッファ２６３に今回の要求１２２をコピーする。

今回の第２のライト要求１２２がバッファ２６３内のデータと連続し、消去ブロック１０５の境界を跨ぐ場合の例を図１２に示す。この場合、バッファ２６３にはターゲットアドレス０ｘ９００００からレングス０ｘＡ０００の読み出すべきデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ９Ａ０００でレングスが０ｘＤ０００の場合、バッファ２６３内のデータと連続するが、すべてのデータをバッファ２６３にコピーすると消去ブロック１０５の境界を跨ぐためバッファ２６３にはデータを０ｘ６０００だけしか挿入できない。この場合、図８のステップ１３４で、消去ブロック１０５内に収まるレングス０ｘ６０００の部分データだけをバッファ２６３にコピーする。コピーしたデータはバッファ２６３の終端に到達するので（ステップ１３５）、バッファ２６３内のデータの消去ブロック１０５のライト操作（ステップ１４０Ｂ）を行う。次に残りのレングス０ｘ８０００の部分データを新たにバッファ２６３にコピーする（ステップ１３４）が、データはバッファ２６３の終端に達しないので終了する。

今回の第２のライト要求１２２がバッファ２６３内のデータと連続せず、消去ブロック１０５の境界を跨ぐ場合の例を図１３に示す。この場合、バッファ２６３にはターゲットアドレス０ｘ６Ｃ０００からレングス０ｘ８０００の読み出すべきデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ９Ａ０００でレングスが０ｘＤ０００の場合、そのデータはバッファ２６３内のデータと連続しないので、バッファ２６３内のデータを消去ブロック１０５のライト操作（ステップ１４０Ａ）で先にバッファ２６３から読み出してメモリカード１００に書き込む。そのうえで、今回の第２のライト要求１２２を実行する。ここで、今回の第２のライト要求１２２のターゲットアドレスのデータ量では、バッファ２６３の消去ブロック１０５のブロック境界によってその第２のライト要求１２２は規制されてしまって全てのデータを消去ブロック１０５に挿入することはできず、この場合には、レングス０ｘ６０００だけしか消去ブロック１０５に挿入できない。この場合、図８のステップ１３４で、消去ブロック１０５の境界以内のレングス０ｘ６０００の部分データだけがバッファ２６３にコピーされる。コピーされたデータはバッファ２６３の消去ブロック１０５の終端に到達するので（ステップ１３５）、バッファ２６３内のデータの消去ブロック１０５のライト操作（ステップ１４０Ｂ）を行う。次に残りのレングス０ｘ８０００の部分データを新たにバッファ２６３にコピーする（ステップ１３４）。コピーしたデータはバッファ２６３の終端に達しないので終了する。

バッファ２６３内のデータの消去ブロック１０５のライト操作（ステップ１４０Ａ、１４０Ｂ）を、図１４のフローチャートと前述した図８のフローチャートとを参照して説明する。なお、両ライト操作（ステップ１４０Ａ,１４０Ｂ）は、前述したように、基本的には同一の操作（ステップ１４０）である。

最初の状態では、バッファ２６３内にデータが全く存在しない。そのため、この状態（図９の例参照）では、次のように判定する。すなわち、ライト処理１３０（図８参照）において第１のライト操作（ステップ１４０Ａ）の前操作に位置するステップ１３２の判定においてＮＯ（今回のデータの先頭アドレスと既にバッファ２６３内にあるデータの終端アドレスとは連続しない）と判断する。

このような判定を下すため、第１のライト操作（ステップ１４０Ａ）に移行する。しかしながら、第１のライト操作（ステップ１４０Ａ）では、ステップ１４１の判断（バッファ２６３内にデータは存在するか否かの判断）においてデータは存在しないと判断する。そのため、第１のライト操作１４０Ａを実施することなく、ステップ１３４,１３５を実施する。第２のライト操作１４０Ｂが実施されるかどうかは、今回のデータがバッファの終端に到達したかどうかの判断（ステップ１３５）による。図９の例では、データはバッファの終端（０ｘＡ００００）に到達していないため、第２のライト操作１４０Ｂは実施されない。

次に、バッファ２６３内にデータが存在している場合の消去ブロック１０５のライト操作１４０を説明する。この場合、ステップ１４１でバッファ２６３内にデータが存在することを確認したのち、バッファ２６３内の有効なデータの先頭アドレスが消去ブロック１０５のブロック境界に合致しているか否かを判定する（ステップ１４２）。一致していない場合は、先頭アドレスを消去ブロック１０５のブロック境界に一致させるためのリード操作を行う（ステップ１４３）。一方、一致している場合は、ステップ１４３を実施しない。

ここでいうリード操作とは、次の操作をいう。まず、書き込み対象となっているメモリカード１００の消去ブロック１０５において、書き込み対象データの先頭アドレスと消去ブロック１０５のブロック境界との間のデータ領域に格納されたデータをメモリカード１００から読み出す。読み出したデータを、バッファ２６３においてデータ格納場所となっている消去ブロック１０５の対応アドレス位置にコピーする。これによりバッファ２６３の消去ブロック１０５において残余のデータ領域に、メモリカード１００から読み出したデータをコピーすることで埋め込む。このような一連の操作がここでいうリード操作である。

ステップ１４２,１４３の操作が実施されたのち、次に、バッファ２６３内の有効なデータの終端アドレスが消去ブロック１０５のブロック境界に一致しているか否かを判定する（ステップ１４４）。一致していない場合は、終端アドレスを消去ブロック境界に合わせるためのリード操作を行う（ステップ１４５）。一致している場合は、ステップ１４５を実施しない。

ここでいうリード操作とは、次の操作をいう。まず、書き込み対象となっているメモリカード１００の消去ブロック１０５において、書き込み対象データの終端アドレスと消去ブロック１０５のブロック境界との間のデータ領域に格納されたデータをメモリカード１００から読み出す。読み出したデータを、バッファ２６３においてデータ格納場所となっている消去ブロック１０５の対応アドレス位置にコピーする。これにより、バッファ２６３の消去ブロック１０５において残余のデータ領域に、メモリカード１００から読み出したデータをコピーすることで埋め込む。このような一連の操作がここでいうリード操作である。

ステップ１４４、ステップ１４５を実施することにより、データの端が消去ブロック１０５のブロック境界に一致したことを確認する。境界一致を確認したのち、消去ブロックサイズのライト操作１３０（ステップ１４６）を行う。ライト操作１３０とは、データをバッファ２６３から読み出してメモリカード１００に書き込む操作をいう。

以上のようにして消去ブロックサイズのライト処理１３０を実行する。

バッファ２６３内のデータの消去ブロックのライト操作１４０の例を、図１５を参照して説明する。バッファ２６３内にターゲットアドレス０ｘ６Ｃ０００、レングス０ｘ８０００のデータが存在するとする。この場合、ステップ１４２にてバッファ２６３の先頭アドレスが消去ブロック境界０ｘ６００００に一致していないことが確認される。そこで、デバイスドライバ１１０はターゲットアドレス０ｘ６００００、レングス０ｘＣ０００のリード要求１２７をメモリカードコントローラ１０９に発行することで前述したリード操作を実施する。これにより、バッファ２６３の消去ブロック１０５内のデータにおいて、その先頭アドレスはブロック境界０ｘ６００００に一致する。

次にステップ１４４にてバッファ２６３の終端アドレスが消去ブロック境界０ｘ８００００に合致していないことが確認される。そこで、デバイスドライバ１１０はターゲットアドレス０ｘ７４０００、レングス０ｘＣ０００のリード要求１２７をメモリカードコントローラ１０９に発行することで前述したリード操作を実施する。これにより、バッファ２６３の消去ブロック１０５内のデータにおいて、その終端アドレスは消去ブロック境界に一致する。

最後にターゲットアドレス０ｘ６００００、レングス０ｘ２００００のデータをバッファ２６３から読み出して（リードして）メモリカード１００に書き込む（ライトする）。

なお、デバイスドライバ１１０におけるライト操作１４０以外の操作１５０では、図１６のフローチャートに示すように、バッファ２６３内のデータを消去ブロック１０５でライト操作（ステップ１４０）したのちライト以外の操作を実行する（ステップ１５２）。このような処理手順を踏むことによりバッファ２６３内のデータをメモリカード１００に確実に反映させてデータの整合性を確保することができる。ライト以外の操作（ステップ１５２）としては、リード要求（デバイスドライバ１１０がファイルシステムドライバ２００から受けるリード要求であり、デバイスドライバ１１０がライト処理中に生成するリード要求１２７は含まない）やデバイス制御の要求がある。

デバイスドライバ１１０におけるタイマーライト起動スレッド１６０を、図１７のフローチャートを参照して説明する。図８のライト処理１３０における特徴的な操作は、バッファ２６３内にデータを残したうえで、次の第２のライト要求１２２のアドレスが先の第２のライト要求１２２のアドレスに連続するかを判断することである。これにより、両アドレスが連続する場合には次の要求１２２を先の要求１２２に連結させることが可能となる。

しかし、次の第２のライト要求１２２が来ない時にデータがバッファ２６３に滞留してしまうことがある。このような不具合を解消するため、図１７のタイマーライト起動スレッドを行う。以下説明する。

当該スレッド１６０が終了していない（継続中である）ことを確認したうえで（ステップ１６１）、最近のライト要求終了（又は開始）からの経過時間を判定する（ステップ１６２）。ステップ１６２の判定において、前記経過時間が閾値Ｔｈより大きければ、新たなライト要求を作成したうえで（ステップ１６３）、その要求とデータとをキューに挿入する（ステップ１６４）。そのうえでステップ１６１に戻る。一方、ステップ１６２において閾値Ｔｈ以下の場合は、ステップ１６３、１６４の操作（ライト要求・キュー挿入）を実施せずにステップ１６１に戻る。そして、ステップ１６１でスレッドが終了したことを確認したら、一連のタイマーライト起動スレッド１６０を終了する。なお、ここでいう閾値Ｔｈは、次の要求１２２が来るまでの期間においてデータがバッファ２６３に滞留するか否かの判定を下す際の識別値となる期間の値を示し、予め、設定されて記憶デバイス１８３等に記憶されている。

ステップ１６３で作成したライト要求は、図３に示した要求処理スレッド１５５のステップ１５７においてキューから取り出され、タイマーライト処理１６６で実際にライトされる。

タイマーライト処理１６６は、図１８のフローチャートに示されるように、図１４に示したバッファ２６３内のデータの消去ブロック１０５のライト操作１４０により実行される。この場合、並行して動作する処理のタイミングによっては、ステップ１４１において、バッファ２６３内にデータが存在しない場合もあり得る。バッファ２６３内にデータが存在する場合のみ、消去ブロック１０５のライト処理１４０（ステップ１４６）が実行される。このタイマーライト処理１６６により、メモリカード１００のデータをバッファ２６３でキャッシュしながらも、閾値Ｔｈの時間以内にはメモリカード１００にデータが反映されることを保証する。これにより、メモリカード１００が取り外される場合でも、データの整合性を保つことができる。

本発明の利点は、メモリカード１００に対して必ず消去ブロック１０５で一回の第３のライト要求１２３を行うので、メモリカード１００内に論理アドレスと物理アドレスとの関連付けが細かな単位で分散して記録時の転送レートを低下させる問題を回避できる点である。これにより、本発明のデータ記録装置１０１でデータを記録したメモリカード１００を他の機器で利用する場合でも、転送レートを保証することができる。

以下、本発明の構成が、記録時の転送レートを低下させる問題を回避できる理由を説明する。まず、従来の構成では転送記録時の転送レートが低下する理由を説明する。図１９に示すように、初期状態では、メモリカード１００の論理アドレスと物理アドレスとは、互いに正確に対応付けされた状態となっている。なお、図１９では、次の状態とする。
・リザーブ用の領域を２個（ＹとＺ）とする。
・論理／物理アドレスは、それぞれ記録最小単位である記録ブロックＡｎ,Ｂｎ,〜Ｚｎから構成する。
・記録ブロックＡｎ,Ｂｎ,〜Ｚｎは、論理アドレス上の論理記録ブロックＡｎ,Ｂｎ,〜Ｚｎと、物理アドレス上の物理記録ブロックＡｎ,Ｂｎ,〜Ｚｎとを有する。
・論理／物理アドレス上の消去ブロック（以下、論理／物理消去ブロックＡ,Ｂ,〜Ｚという）を、複数の論理記録ブロックＡｎ,Ｂｎ,〜Ｚｎのグループから構成する。なお、図１９の例では、論理／物理消去ブロックＡ,Ｂ,〜Ｚそれぞれを４つの論理／物理記録ブロックＡｎ,Ｂｎ,〜Ｚｎから構成し、同一の論理／物理消去ブロックＡ,Ｂ,〜Ｚを構成する論理／物理記録ブロックを、論理／物理記録ブロックＡ１〜４,Ｂ１〜４,〜Ｚ１〜４と称する。
・初期状態では、論理消去ブロックＡ,Ｂ,〜Ｚと物理消去ブロックＡ,Ｂ,〜Ｚとは、１対１（Ａ−Ａ,Ｂ−Ｂ,Ｃ−Ｃ）に対応付けられており、さらには、対応付けられた論理消去ブロックと物理消去ブロックとの間において、論理記録ブロックＡｎ,Ｂｎ,〜Ｚｎは、１対１（Ａ１〜Ｚ１−Ａ１〜Ｚ１、Ａ２〜Ｚ２−Ａ２〜Ｚ２、…）に対応付けられている。

なお、論理消去ブロックＡ〜Ｚに記録されるデータは、次のようにして生成される。メモリカード１００とアプリケーションプログラム３００との間にバッファ２６３を中間記録媒体として配置したうえで、バッファ２６３とアプリケーションプログラム３００との間やバッファ２６３とメモリカード１００との間で、データの読み／書き操作を実施する。このような操作の実施を通じてバッファ２６３上に論理消去ブロックＡ〜Ｚのデータを生成してメモリカード１００に供給する。

従来の構成での記録操作を図２０に示す。１回目の記録操作において論理記録ブロックＡ１にデータが書き込まれたとする。その際、物理記録ブロックＡ１にデータが存在しない。そのため、論理記録ブロックＡ１に書き込まれたデータは、そのまま、物理記録ブロックＡ１に記録される。

２回目の記録操作において論理記録ブロックＡ３にデータが書き込まれたとする。その際、１回目の記録操作により論理記録ブロックＡに対応付けされている物理消去ブロックＡの物理記録ブロックＡ１には既にデータが格納されている。そのために、物理記録ブロックＡ１を消去せずに物理記録ブロックＡ３をオーバーライトすることはできない。したがって、論理記録ブロックＡ３に書き込まれたデータは、リザーブ用の領域として確保されている物理消去ブロックＹを構成する物理記録ブロックＹ１に記録される。

このとき、論理記録ブロックＡ３に対応付けられる物理記録ブロックは、物理記録ブロックＹ１に変更される。さらには、リザーブ用の領域を確保するために、次の処置が施される。

論理記録ブロックＹ１をリザーブの領域から解放したうえで、任意の他の論理記録ブロック（図２０では、論理記録ブロックＸ１）を新たにリザーブ用の領域として確保する。

３回目の記録操作において論理記録ブロックＡ２にデータが書き込まれたとする。その際、１回目の記録操作により論理記録ブロックＡに対応付けされている物理消去ブロックＡの物理記録ブロックＡ１には既にデータが格納されている。そのために、物理記録ブロックＡ１を消去せずに物理記録ブロックＡ２をオーバーライトすることはできない。したがって、論理記録ブロックＡ２に書き込まれたデータは、リザーブ用の領域として確保されている物理消去ブロックＺを構成する物理記録ブロックＺ１に記録される。

このとき、論理記録ブロックＡ２に対応付けられる物理記録ブロックは、物理記録ブロックＺ１に変更される。さらには、リザーブ用の領域を確保するために、次の処置が施される。

論理記録ブロックＺ１をリザーブの領域から解放したうえで、任意の他の論理記録ブロックを新たにリザーブ用の領域として確保する。

以上の記録操作が実施されたうえで、論理消去ブロックＡにデータに上書きする場合を想定する。この場合、物理消去ブロックＡ,Ｙ,Ｚは全て消去しなければならなくなり、転送レートは低下してしまう。このように記録ブロックで記録を行うために、メモリカード１００内でデータが分散してしまって、そのために転送レートが低下する。

なお、メモリカード１００に対するライト処理の時間間隔や、ターゲットとするアドレスの相違や、メモリカード１００のコントローラの相違や、さらにはメモリカード１００の内部の状態の相違等に基づいて転送レートの低下の程度は変動する。しかしながら、記録領域に記録ブロックと消去ブロックとが設定された状態で読み書きが実施されるメモリカード１００において転送レートの低下は共通の課題となっている。

次に、本発明を実施することで、転送レートの低下を抑制できる理由を説明する。図２１は本発明の構成での記録操作を示す。

１回目の記録操作において論理消去ブロックＡの論理記録ブロックＡ１にデータが書き込まれたとする。１回目のデータは一旦バッファ２６３にキャッシュされる。２回目の記録操作において論理記録ブロックＡ３にデータが書き込まれたとする。バッファ２６３にあるＡ１に書き込むべきデータと今回のＡ３は連続しないので、次の処理を行う。まず、バッファ２６３内を論理消去ブロックＡに対応させて、物理消去ブロックＡの物理記録ブロックＡ２、Ａ３、Ａ４に格納されているデータを、バッファ２６３内の論理記録ブロックＡ２、Ａ３、Ａ４に対応した位置に読み出す。これにより、バッファ２６３内のデータ内容は、論理消去ブロックＡのデータを反映したものであると同時に物理消去ブロックＡのデータを反映したものとなって、メモリカードのコントローラは、デバイスドライバから受けた論理消去ブロックＡに対するライト要求をそのままの状態で物理消去ブロックＡに書き込み可能となる。

２回目の記録操作において論理記録ブロックＡ３に書き込まれたデータが後にライトされる際においても、まず、バッファ２６３内を論理消去ブロックＡに対応させて、物理消去ブロックＡの物理記録ブロックＡ１、Ａ２、Ａ４に格納されているデータを、バッファ２６３内の論理記録ブロックＡ１、Ａ２、Ａ４に対応した位置に読み出す。これにより、バッファ２６３内のデータ内容は、論理消去ブロックＡのデータを反映したものであると同時に物理消去ブロックＡのデータを反映したものとなって、メモリカードのコントローラは、デバイスドライバから受けた論理消去ブロックＡに対するライト要求をそのままの状態で物理消去ブロックＡに書き込み可能となる。

これにより、本発明では、論理アドレスと物理アドレスとの間の対応付けが所期状態のままで変動することなく維持されることとなり、その結果、転送レートの低下を低減することができる。

本参考例は、図６に示したプログラム構成に基づいているが、図２２に示すように、デバイス独自のＩ／Ｏ処理のみデバイスドライバで行い、本参考例で説明したデバイスドライバのライト処理１１０をデバイスドライバの上位に位置するフィルタドライバ１１５で実行することも可能である。フィルタドライバ１１５を用いた構成の場合、メモリカード１００の種類やメモリカードのインターフェースなどハードウェアに依存する部分をデバイスドライバ１１０が吸収するので、本発明の記録処理はより汎用的に利用できる。

本参考例では、図８のライト処理１３０において、今回のデータとバッファ２６３内のデータとが連続するかどうかを判定するステップ１３２の操作は、図１０に示すように、バッファ２６３内のデータの終端アドレスと第２のライト要求１２２のターゲットアドレスとが完全に一致するか否かで、両データの連続性を判定している。

しかしながら、ターゲットアドレスがバッファ２６３内のデータの終端アドレスより小さく、先頭アドレスより大きい場合にも連続していると判定することができる。例えば図１０の例の場合、ターゲットアドレスが０ｘ８１０００のような場合でも、バッファ２６３内のデータの０ｘ８１０００以降を上書きしてコピーすることができる。この場合、最終的なバッファ２６３内のデータの終端アドレスは０ｘ８Ｆ０００となる。

本参考例では、図１５に示すようにデータの先頭アドレス及び終了アドレスが消去ブロック１０５の境界に合っていない要求の場合、バッファ２６３内のデータを消去ブロック１０５にしてからメモリカード１００に書き込む例を示した。しかしながら、この場合、そのデータをバッファ２６３にコピーする前に、消去ブロック１０５のデータをメモリカード１００から読み出してバッファ２６３にコピーする処理（リード処理）を行って、バッファ２６３全体を消去ブロック１０５サイズのデータで埋める処理を行い、その上から前記要求のデータをバッファ２６３にコピーすることもできる。この処理は、将来、ライト操作１４０において行うべきリード操作を、前もって行うものである
このようなバッファ２６３上の上書き処理を行った場合、前記連続性の判定を変更することにより、バッファ２６３内に存在する消去ブロック１０５の範囲内のターゲットアドレス（及びレングスを加えて求められる終端のターゲットアドレス）を持つライト要求が到着し続けている間は第２のライト要求１２２を行わなくて済む。そのため、ファイルシステムドライバ２００からの一連の第２のライト要求１２２をより高速に処理することが可能となる。

本実施形態では消去ブロック１０５でライト処理を行う例を示したが、消去ブロック１０５の整数倍の単位でライト処理を行っても同様の効果を得ることができる。メモリカード１００をＲＡＩＤディスク状にＬ個（Ｌは自然数）だけ並列に接続した記憶媒体として使用する場合には、消去ブロック１０５のＬ倍のサイズでライト処理を行うことで本発明を適用できる。

本参考例では、メモリカード１００を別のメモリカード１００'に差し替えた場合、消去ブロックサイズを可変とすることが可能である。メモリカード１００を抜いた際にデバイスドライバ１１０のアンロード処理１７９が行われ、別のメモリカード１００'を差した際にデバイスドライバ１１０のロード処理１７０が行われる。ロード処理１７０（図４参照）のステップ１７３で、別のメモリカード１００'に対する消去ブロックサイズを新たに決定することができる。また、ロード処理１７０においてメモリカード固有の情報を用いることで、消去ブロックサイズと異なるブロックサイズを用いることも可能である。

本参考例では、常に一定の消去ブロックサイズでメモリカード１００に書き込む例を示したが、論理アドレスの領域毎に異なるブロックサイズで書き込むことも可能である。例えば、ファイルシステムのシステム領域に相当するアドレスの場合は、より小さいブロックサイズでライト処理を行うことができる。この場合、メモリ１８２上に割り当てるバッファ２６３は、可変となるサイズの最大値を割り当てておけば良い。

ファイルを記録するアプリケーションは、データ記録装置のＯＳ上で動作するものであれば、利用することができる。アプリケーションプログラム３００がファイルシステムドライバ２００の処理やデバイスドライバ１１０の処理を包含する構成も可能である。また、ユーザ空間とカーネル空間の処理を区別しないＯＳ上でも、本発明を実施できる。ＦＡＴファイルシステムを例にとって説明したが、ファイルをクラスタのような一定のサイズに分割して記録するものであれば、他のファイルシステムにも適用できる。クラスタの境界と消去ブロックの境界が一致しない場合を例にとって説明したが、それらが一致する場合にも適用できるのは明らかである。

本参考例では、図１のようなデータ記録装置１０１に適用する例を示したが、ＯＳが搭載されたデータ記録装置であれば、この形態に限るものではない。

本参考例では半導体メモリカードに適用する例を説明したが、半導体メモリカード以外の記録デバイスの場合でも、オーバーライト動作ができず、記録の際に消去動作が必要となるような記録デバイスに適用することが可能である。

第２の参考例
本参考例は、第１の参考例において、データ記録装置１０１のメモリ１８２上に確保された複数の物理メモリ領域を１つのメモリ記述子リストとして記述でき、かつ２つ以上のメモリ記述子リストを連結できる場合に適用できる例である。本参考例は、デバイスドライバ１１０'が第１の参考例と異なり、データ記録装置１０１の構成は第１の参考例と同じである。

メモリ記述子リストを図２３を参照して説明する。ターゲットアドレス０ｘ４２０００、レングス０ｘ６０００の第２のライト要求１２２がある場合、通常レングス０ｘ６０００のデータは、ＯＳのメモリ空間２６０上に格納されている。仮想記憶ではメモリ領域をページ単位に分割するため、データを連続領域に確保せずに図２３のように分散した領域に格納する。メモリ記述子リスト２７０は、この分散した領域を記述するためのリストである。図２３ではメモリアドレスがカーネル空間にある例を示しているが、ユーザ空間にあってもよい。

本参考例のデバイスドライバ１１０'におけるロード処理１７０Ｃを図２４に示す。最初にデバイスドライバ１１０のインスタンスをメモリ１８２上にロードする（ステップ１７１Ｃ）。次に、デバイスドライバ１１０'の初期化操作を行う（ステップ１７２Ｃ）。次に消去ブロックサイズを決定する（ステップ１７３Ｃ）。ここで、第１の参考例とは異なり、バッファ２６３を確保する代わりにライト処理用のバッファリストの領域を確保する（ステップ１７６Ｃ）。バッファリストは、図２３のメモリ記述子リスト２７０と同様のリストであり、リストの行数の上限を設定し、情報の格納に十分な量のバッファリストの領域を確保すれば良い。バッファリストは、アンロード時に解放される。

本参考例のデバイスドライバ１１０'におけるライト処理１３０Ｃを図２５に示す。なお、本参考例のライト処理１３０Ｃは、図８を参照して説明した第１の参考例のライト処理１３０と同様の構成を備える。そのため、図２５のライト処理１３０Ｃにおいて、図８のライト処理と同一の操作には同一の符号を付し、それらについての説明は省略して、ライト処理１３０Ｃの特徴となる操作のみ説明する。

まず、今回のデータの先頭アドレスとバッファリスト内にあるデータの終端アドレスとが連続するかどうかを判定する（ステップ１３２Ｃ）。アドレスが連続しない場合は、バッファリストのデータの消去ブロックの第１のライト操作を行う（ステップ１４０Ｃ）。連続する場合は、バッファ２６３内で以前のデータと今回のデータとを連結させるため、消去ブロック境界以内の部分データのメモリ記述子リストをバッファリストにコピーする（ステップ１３４Ｃ）。

ここで、今回のライト要求２７０Ａが、バッファリスト２８０Ａと連続する場合、図２６に示すように、リストをコピーして拡張することで、バッファリスト２８０Ａをバッファリスト２８０Ｂに更新する。

図２５のフローチャートに戻って説明する。ステップ１３４Ｃの操作を実施したのち、データがバッファ２６３の終端に到達したかどうかを判定し（ステップ１３５）、到達していなければ終了する。到達していればバッファリストのデータの消去ブロック１０５のライト処理（ステップ１４０Ｄ）を行う。

最後に、今回の要求データが残っているかどうかを判定し（ステップ１３６）、残っていればステップ１３４Ｃに戻る。残っていなければ操作を終了する。

但し、バッファリスト内にあるメモリアドレスの範囲は、データがバッファ２６３内で有効な間、ロックしておく必要がある。以上のようにして、デバイスドライバのライト処理１３０Ｃを行う。

以上説明したように、本参考例の消去ブロックのライト処理１４０Ｃにおいては、バッファ２６３がバッファリストで置き換わった以外は、第１の参考例における消去ブロックのライト操作１４０と同様の処理を行う。

本参考例におけるデバイスドライバのライト以外の処理１５０とタイマーライト起動スレッド１６０とは、第１の参考例と同様である。

本参考例は、データを連結させるためにリスト上でデータのリストを連結させている。そのため、メモリ１８２上でデータのコピーを行う必要がなくなり、複数の物理メモリ領域を１つのメモリ記述子リストとして記述できる。さらには、２つ以上のメモリ記述子リストを連結できる条件下においては、第１の参考例より高速なライト処理を行うことができる。

第３の参考例
本参考例の基本構成は、図１に示す第１の参考例と同じであるため、それらについての説明は省略する。本参考例では、図２７に示すように、データ記録装置は撮像記録装置１０１Ｂとして構成される。レンズ１９４から入力された映像信号とマイク１９５から入力された音声信号を、メモリカード１００に記録する。

本参考例の撮像記録装置１０１Ｂの動作も基本的には第１の参考例のデータ記録装置１０１と同様である。しかしながら、本参考例では、デバイスドライバのロード処理１７０（図４参照）において、メモリ１８２上にライト処理用のバッファ２６３を確保する操作（ステップ１７４）が、第１の参考例と異なる。第１の参考例との相違点を図２８を参照して説明する。

図２８に示すように、ＯＳのメモリ空間２６０において、カーネル空間２６１上にライト処理のバッファ２６３を１個以上確保する。本参考例では、１個のバッファ２６３のサイズを２５６Ｋバイトとしており、１２８Ｋバイトとした第１の参考例と異なる。

バッファ２６３は、デバイスドライバ１１０のアンロード処理１７９において解放される。デバイスドライバ１１０のロード処理１７０及びアンロード処理１７９は、それぞれメモリカード１００をデータ記録装置１０１に接続／取り外しするタイミングで行うのが望ましい。

次に本参考例の特徴となるメモリカード１００への記録処理を、図２９を参照して説明する。ファイルシステムドライバ２００は、アプリケーションプログラム３００からファイルをメモリカード１００に記録するための第１のライト要求１２１を受けると、図４７を参照して従来例で説明した手順に従って、ファイルをクラスタ２１０の単位で記録する。ファイルシステムドライバ２００は、ファイル３１０を記録するために必要なクラスタのデータ２２１や管理データ２２０を、新たないくつかの第２のライト要求１２２としてデバイスドライバ１１０に送信する。

第２のライト要求１２２の列には、今回のファイル３１０の記録に必要なデータだけでなく、同時刻に記録すべき他のファイルのデータや管理データを含んでいても良い。

第２のライト要求１２２を受けたデバイスドライバ１１０は、ライト処理１３０を開始する。ライト処理１３０では、デバイスドライバ１１０はメモリカード１００に記録される全てのデータを複数のピンポンバッファ１１３によりキャッシュする。このキャッシュ動作は、メモリカード１００上の論理アドレスが連続する複数の第２のライト要求１２２を連結するように行われる。このキャッシュ動作によりメモリカード１００に対する第３のライト要求１２３の数を減らすことができる。またピンポンバッファ１１３を用いることにより、第２のライト要求１２２のピンポンバッファ１１３へのコピー動作とピンポンバッファ１１３からメモリカード１００への転送動作を同時並行して行うことが可能となる。さらにデータの整合性保証のため、一定時間間隔でピンポンバッファ１１３のフラッシュ動作を行う。ピンポンバッファ１１３は、バッファ２６３を複数用いて構成される。図２９に示すように、２つのピンポンバッファ１１３（＃１）、１１３（＃２）を備え、さらに各ピンポンバッファ１１３を二つのバッファ２６３から構成する場合、図２８に示すバッファ２６３を４個確保すれば良い。

ピンポンバッファ１１３の詳細を、図３０を参照して説明する。図３０は、Ｋ個（Ｋは自然数）のピンポンバッファ１１３を示している。各ピンポンバッファ１１３（＃１〜＃Ｋ）は、図２９の構成と同様、２つのバッファ２６３を備える。以下、ピンポンバッファ１１３（＃１〜＃Ｋ）を構成するバッファ２６３は、＃１−Ａ、＃１−Ｂ、＃２−Ａ、＃２−Ｂ、…＃Ｋ−Ａ、＃Ｋ−Ｂと記す。

ピンポンバッファ１１３（＃１〜＃Ｋ）の構成要素は、実際にバッファ領域が確保されるメモリ１８２上の論理アドレス２６４と、メモリカード１００にライトすべきデータのターゲットアドレス２６５、及びレングス２６６とを有する。ピンポンバッファ１１３（＃１）は、バッファ＃１−Ａにターゲットアドレス０ｘ２００００、レングス０ｘ８０００のデータが入っている。このように、ピンポンバッファ１１３を構成するバッファの少なくとも一つにデータが入っている時、「ピンポンバッファ１１３内にデータが入っている」と表現することにする。したがって、図３０の状態では、ピンポンバッファ１１３（＃１）、ピンポンバッファ１１３（＃２）にはデータが入っており、ピンポンバッファ１１３（＃３）にはデータが入っていないことになる。

また、ピンポンバッファ１１３（＃１〜＃Ｋ）にデータが入っている状態としては、バッファ１１３＃（１〜Ｋ）−Ａとバッファ１１３＃（１〜Ｋ）−Ｂとの一方にデータが入っている場合もあれば、バッファ１１３＃（１〜Ｋ）−Ａとバッファ１１３＃（１〜Ｋ）−Ｂとの両方にデータが入っている場合もある。両バッファにデータが入っている場合は片方のバッファ（例えば１１３＃Ｋ−Ａ）がライト中であり無効となる。そのため、この場合には実際に有効なデータはもう一方のバッファ（例えば１１３＃Ｋ−Ｂ）のみとなる。

デバイスドライバ１１０によるライト処理１３０Ｂの詳細を、図３１のフローチャートを参照して説明する。ピンポンバッファ１１３（＃１〜＃Ｋ）は、図３０に示すように、Ｋ個（Ｋは自然数）確保するとする。

まず、要求データと連続するアドレスのデータを持つピンポンバッファ１１３＃ｋ（ｋは自然数、１≦ｋ≦Ｋ）が存在するかどうかを判定する（ステップ２３１）。ここでアドレスとは、メモリカード１００上の論理アドレス又は物理アドレスである。要求データと連続するアドレスのデータを持つピンポンバッファ１１３＃ｋが存在する場合は、そのピンポンバッファ１１３＃ｋを、要求データをコピーするターゲットバッファｗとする（ステップ２３２）。存在しない場合は、要求データをコピーするターゲットバッファｗを任意に決定する（ステップ２３３）。この決定方法は、メモリカード１００上のデータが矛盾しない範囲で任意の方法が考えられる。例えば、ピンポンバッファ１１３＃ｎ（１≦ｎ≦Ｋ）の中で、要求データとデータのアドレス領域が重複するｎ＝Ｎ１が存在する場合にはｗ＝Ｎ１とし、Ｎ１が存在しない場合にデータが入っていないピンポンバッファｎ＝Ｎ２が存在する場合にはｗ＝Ｎ２とする。いずれも存在しない場合にはｗを任意のｎとする方法がある。ターゲットバッファｗが決定されると、ターゲットバッファｗ内のデータをメモリカード１００に書き込むライト操作を行う（ステップ２３４Ａ）。但し、バッファｗ内にデータが入っていない場合には、ライト操作を行わない。

次に、バッファ境界以内の部分データを、要求データからピンポンバッファｗにコピーする（ステップ２３５）。バッファ境界以内とは、図３０に示したピンポンバッファ１１３の終端アドレス以内に収まることを意味する。例えばピンポンバッファ１１３（＃１）を構成するバッファ＃１−Ａをターゲットバッファｗとする場合、システムファイルドライバ２００が、合計のレングスが０ｘ４００００以内となる部分データをバッファ＃１−Ａにコピーすることを意味する。その際、ターゲットバッファｗには、ステップ２３１でＹＥＳが選択された場合にはデータが入っており、ＮＯが選択された場合にはデータが入っていない。そこで、ステップ２３１でＹＥＳが選択された場合にはデータを連続させるようにバッファ境界以内の部分データをターゲットバッファｗにコピーし、ＮＯが選択されていた場合にはピンポンバッファｗの先頭から部分データをコピーする。

次に、コピーしたデータがピンポンバッファｗの終端に到達したかどうかを判定し（ステップ２３６）、到達していなければ終了する。到達していればピンポンバッファｗ内のデータをメモリカード１００に書き込むライト操作（ステップ２３４Ｂ）を行う。そのうえで、今回の要求データが残っているかどうかを判定し（ステップ２３７）、残っていればステップ１３５に戻る。残っていなければ終了する。

以上説明したデバイスドライバのライト処理１３０Ｂの効果を示す具体例を、図３２と図３３を参照して説明する。ここでは、２個のピンポンバッファ１１３（＃１）、１１３（＃２）が設けられ、さらには、各ピンポンバッファ１１３（＃１）、１１３（＃２）は、それぞれ２個のバッファ＃１−Ａ、＃１−Ｂ、または、バッファ＃２−Ａ、＃２−Ｂを備えているとする。さらには、デバイスドライバ１１０は、図３２に示す４個の第２のライト要求１２２を連続して受信し、その結果、図３１のフローチャートに示すライト処理１３０Ｂが４回実施されるとする。その際、２個のピンポンバッファ１１３（＃１）、１１３（＃２）には、最初は両方ともデータが入っていないものとする。

この場合、図３２に示す処理では、到着順１の第２のライト要求１２２は、ピンポンバッファ１１３（＃１）を構成するバッファ＃１−Ａにコピーされて（ステップ２３３、２３５）、終了する。到着順２の第２のライト要求１２２は、バッファ＃１−Ａに入っているデータとアドレスが連続しない。そのため、この第２のライト要求１２２は、ピンポンバッファ１１３（＃２）を構成するバッファ＃２−Ａにコピーされて（ステップ２３３、２３５）、終了する。到着順３の第２のライト要求１２２は、バッファ＃１−Ａに入っているデータとアドレスが連続するので、バッファ＃１−Ａにコピーされて（ステップ２３２、２３５）、終了する。到着順４の第２のライト要求１２２は、ピンポンバッファ１１３（＃１）を構成するバッファ＃１−Ａに入っているデータとはアドレスが連続しないが、ピンポンバッファ１１３（＃２）を構成するバッファ＃２−Ａに入っているデータとアドレスが連続する。そのため、この第２のライト要求１２２は、バッファ＃２−Ａにコピーされて（ステップ２３２、２３５）、終了する。

以上の処理により、ピンポンバッファ１１３（＃１）、１１３（＃２）にライトすべきデータがキャッシュされる。

次に図３３に示す到着順５の第２のライト要求１２２を受けた場合、この第２のライト要求１２２はピンポンバッファ１１３（＃１）を構成するバッファ＃１−Ａに格納されているデータにも、ピンポンバッファ１１３（＃２）を構成するバッファ＃２−Ａに格納されているデータにも、そのアドレスが連続しない。そのため、図３１のステップ２３３において任意のピンポンバッファ１１３が選択される。この例では、ピンポンバッファ１１３（＃１）が選択されたとする。この場合、バッファ＃１−Ａに格納されているデータを読み出してメモリカード１００に書き込むライト操作を行ったうえで（ステップ２３４Ａ）、到着順５のデータをバッファ＃１−Ｂにコピーする（ステップ２３５）。

このとき、複数のバッファを備えたピンポンバッファ１１３を設けているため、バッファ＃１−Ａに格納されたデータのライト操作（ステップ２３４Ａ）の完了を待つことなく、バッファ＃１−Ｂにデータをコピーする操作（ステップ２３５）を行うことができる。バッファ＃１−Ａ内のデータは、ライト操作（ステップ２３４Ａ）が完了すればクリアされる。これによりピンポンバッファ１１３（＃１）における有効なデータの格納場所（バッファ）は、バッファ＃１−Ａからバッファ＃１−Ｂに変更される。そのため、次に到着順６の第２のライト要求１２２を受ける場合、ステップ２３１の操作においてデータが連続するかどうかを比較する対象となるバッファは、バッファ＃１−Ｂとバッファ＃２−Ａとに変更される。

以上、図３２と図３３とを参照して説明したように、デバイスドライバ１１０が受ける第２のライト要求１２２を、ピンポンバッファ１１３（＃１〜＃Ｋ）を用いてキャッシュすることで、メモリカード１００へ送る第３のライト要求１２３の数を減らすことができ、ライトの転送レートを向上させることができることがわかる。

デバイスドライバ１１０のライト処理１３０Ｂを、具体例を参照して詳しく説明する。図３１のライト処理１３０Ｂでは、ステップ２３２もしくはステップ２３３にてターゲットバッファｗ（１１３）を決定した後は、ターゲットバッファｗに関する動作のみを考えれば良い。よってライト処理１３０Ｂは、ターゲットバッファｗと要求データとの関係から、図３４から図３８に示す５つの場合に代表させることができる。

まず、ターゲットバッファｗ（１１３）内にデータがない場合のライト処理１３０Ｂの例を図３４に示す。ターゲットバッファｗ（１１３）は、図２８で予め確保したバッファ２６３領域のアドレスであり、０ｘ２００００バイト、即ち１２８Ｋバイトの領域としている。

第２のライト要求１２２が、ターゲットアドレス０ｘ８２０００、レングス０ｘＤ０００であるとした場合、０ｘ８２０００から０ｘＤ０００分のデータを、ターゲットバッファｗを構成するバッファ＃ｗ−Ａにコピーする（ステップ２３５）。このとき、バッファ＃ｗ−Ａを０ｘ８２０００から０ｘＡ２０００までのメモリカード１００上の領域に対応させる。

コピーしたデータはバッファ＃ｗ−Ａの終端に到達していないので（ステップ２３６）、この第２のライト要求１２２の処理を終了する。なお、この例ではバッファ＃ｗ−Ａにコピーする例を示したが、ターゲットバッファｗの状態によりバッファ＃ｗ−Ｂにコピーする場合もある。これは、以下に示す他の場合の例でも同じである。

今回の要求がターゲットバッファｗ内のデータと連続する場合の例を図３５に示す。ターゲットバッファｗにはターゲットアドレス０ｘ８００００からレングス０ｘ２０００のデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ８２０００でレングスが０ｘＤ０００の場合、このデータはターゲットバッファｗ内のデータと連続する。そのため、ターゲットバッファｗにおいてターゲットアドレス０ｘ８００００からレングス０ｘ１００００までのデータ領域を、今回の第２のライト要求１２２で指定されるデータに更新して（ステップ２３５）、終了する。

今回の要求がターゲットバッファｗ内のデータと連続しない場合の例を図３６に示す。ターゲットバッファｗを構成するバッファ＃ｗ−Ａにはターゲットアドレス０ｘ６Ｃ０００からレングス０ｘ８０００のデータが入っている。このデータと今回の第２のライト要求１２２のアドレス０ｘ８２０００とは連続しない。そのため、バッファ＃ｗ−Ａ内のデータを先に読み出してメモリカード１００に書き出してから（ステップ２３４Ａ）、バッファ＃ｗ−Ｂに今回の要求をコピーして（ステップ２３５）、終了する。

今回の要求がピンポンバッファｗ内のデータと連続し、ピンポンバッファの境界を跨ぐ場合の例を図３７に示す。ターゲットバッファｗを構成するバッファ＃ｗ−Ａにはターゲットアドレス０ｘ８００００からレングス０ｘ１Ａ０００のデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ９Ａ０００でレングスが０ｘＤ０００の場合、バッファ＃ｗ−Ａ内のデータと連続するが、バッファ境界のためバッファ＃ｗ−Ａにはデータを０ｘ６０００だけしか挿入できない。この場合、バッファ境界以内のレングス０ｘ６０００の部分データだけをバッファ＃ｗ−Ａにコピーする（ステップ２３５）。この場合、データのコピーにより、ピンポンバッファｗ（バッファ＃ｗ−Ａ）では、格納したデータがバッファ終端に到達するので（ステップ２３６）、ピンポンバッファｗ内のデータを読み出してメモリカード１００に書き込むライト操作を行う（２３４Ａ）。ライト操作を実施しても、第２のライト要求１２２の要求データは残っているので（ステップ２３７）、残りのレングス０ｘ８０００の部分データを、ターゲットバッファｗを構成するバッファ＃ｗ−Ｂにコピーする（ステップ２３５）。今回のコピー処理でデータはターゲットバッファｗの終端に達しない（ステップ２３６）ので終了する。

今回の要求がピンポンバッファｗ内のデータと連続せず、ピンポンバッファの境界を跨ぐ場合の例を図３８に示す。ターゲットバッファｗを構成するバッファ＃ｗ−Ａにはターゲットアドレス０ｘ６Ｃ０００からレングス０ｘ８０００のデータが入っている。今回の第２のライト要求１２２のターゲットアドレスが０ｘ９Ａ０００でレングスが０ｘ２８０００の場合、この第２のライト要求１２２で指定されるデータはバッファ＃ｗ−Ａ内のデータと連続しない。そのため、バッファ＃ｗ−Ａ内のデータを先に読み出してメモリカード１００に書き込む（ステップ２３４Ａ）。

次にターゲットバッファｗの境界のため、ターゲットバッファｗを構成するバッファ＃ｗ−Ｂにはデータを０ｘ２００００だけしか挿入できない。この場合、バッファ境界以内のレングス０ｘ２００００の部分データだけをバッファ＃ｗ−Ｂにコピーする（ステップ２３５）。コピーしたデータはターゲットバッファｗの終端に到達するので（ステップ２３６）、ターゲットバッファｗ内のデータのライト処理を行う（ステップ２３４Ｂ）。

以上の操作を実施したのちであっても、第２のライト要求１２２の要求データは残っているので（ステップ２３７）、残りのレングス０ｘ８０００の部分データを、ターゲットバッファｗを構成するもう一つのバッファ＃ｗ−Ａにコピーする（ステップ２３５）。この際、バッファ＃ｗ−Ａが使用できる状態になっているか確認する必要がある。コピーされたデータはバッファ＃ｗ−Ａの終端に達しないので終了する。

以上説明したライト処理１３０Ｂの５つの場合において、図３７と図３８に示すように、コピーするデータがバッファ境界を跨ぐ場合は、ピンポンバッファ１１３を構成するバッファのサイズを十分大きく確保しておけば良い。そうすれば、コピーするデータがバッファ境界を跨ぐことがほとんどなくなる。ファイルシステムドライバ２００からの要求は、いくつかの要求をキャッシュすると次に連続したアドレスの要求が来る確率が高いため、第２のライト要求１２２を連結して一つの要求にできる確率は高くなる。

デバイスドライバ１１０におけるライト以外の処理１５０Ｂを、図３９のフローチャートを参照して説明する。最初に、ピンポンバッファ１１３（＃ｋ）（１≦ｋ≦Ｋ）内のデータを読み出してメモリカード１００に書き込むライト操作を実行する（ステップ１５１）。これは、Ｋ個全てのピンポンバッファ１１３（＃ｋ）内のデータをライトする操作である。この操作によりピンポンバッファ１１３（＃ｋ）内のデータをメモリカード１００に確実に反映させてデータの整合性を確保する。その後ライト以外の操作を実行し（１５２）、終了する。ライト以外の操作には、リード要求（デバイスドライバ１１０がファイルシステムドライバ２００から受けるリード要求）やデバイス制御の要求がある。

デバイスドライバ１１０におけるタイマーライト起動スレッド１６０は、図１７を参照して説明した第１の参考例におけるタイマーライト起動スレッド１６０と同様であるのでその説明は省略する。

本参考例のタイマーライト処理１６６Ｂを図４０のフローチャートを参照して説明する。タイマーライト処理１６６Ｂでは、図３９のステップ１５１の操作であるピンポンバッファ１１３（＃ｋ）（１≦ｋ≦Ｋ）内のデータのライト操作を実行する。並行して動作する処理のタイミングによっては、ステップ１５１において、ピンポンバッファ１１３（＃ｋ）内にデータが存在しない場合もあり得る。ピンポンバッファ１１３（＃ｋ）内にデータが存在する場合のみ、メモリカード１００へのライトが実行される。このタイマーライト処理１６６Ｂにより、メモリカード１００のデータをピンポンバッファ１１３（＃ｋ）でキャッシュしながらも、閾値Ｔｈの時間以内にはメモリカード１００にデータが反映されることを保証する。メモリカード１００が取り外される場合でも、データの整合性を保つことができる。

本参考例により、メモリカード１００へのライト要求をキャッシュし、連続したアドレスの要求を連結することで、メモリカード１００へ送られるライト要求の数を減らすことができる。本発明のデバイスドライバを用いることで、汎用のファイルシステムと汎用のメモリカードを用いる場合でも、ライトの転送レートを向上させることが可能となる。

本参考例は、図６に示したプログラム構成に基づいているが、図２２に示すプログラム構成においても、第１の参考例と同様に実施することができる。

本参考例では、図３１のライト処理１３０Ｂにおいて、今回のデータとピンポンバッファ１１３内のデータとが連続するかどうかを判定するステップ２３１の操作は、図３５のようにターゲットバッファｗ内のデータの終端アドレスと第２のライト要求１２２のターゲットアドレスとが完全に一致するか否かで、両データの連続性を判定している。

しかしながら、ターゲットアドレスがターゲットバッファｗ内のデータの終端アドレスより小さく、先頭アドレスより大きい場合にも連続と判定することができる。例えば図３５の場合、ターゲットアドレスが０ｘ８１０００のような場合でも、バッファ＃ｗ−Ａ内のデータの０ｘ８１０００以降を上書きしてコピーすることができる。この場合、最終的なバッファ＃ｗ−Ａ内のデータの終端アドレスは０ｘ８Ｆ０００となる。以上の連続性の判定を変更する場合には、図３１のステップ２３３において、先述したバッファｎ＝Ｎ１を選択する際の判定条件から、ターゲットアドレスがターゲットバッファｗ内のデータの終端アドレスより小さく、先頭アドレスより大きい場合を除外する必要がある。

本参考例では、図３４のようにターゲットバッファｗ内にデータがない場合、ターゲットバッファｗの先頭から第２のライト要求１２２のデータをコピーする例を示したが、例えばターゲットバッファｗの先頭のターゲットアドレスを０ｘ２００００の倍数である０ｘ８００００と決定し、先頭から０ｘ２０００だけ後ろの位置からデータをコピーしても良い。その場合、最終的に図３１のステップ２３４にてターゲットバッファｗ内のデータをライトする前に、０ｘ８００００から０ｘ２０００だけのデータをメモリカード１００からターゲットバッファｗにリードすることで、常にターゲットアドレスが０ｘ２００００の倍数であるライトを行うことができる。さらに、ステップ２３４にてライトする前にターゲットバッファｗ内のデータの終端アドレスが０ｘＡ００００に合っていない場合は、実際のターゲットバッファｗ内のデータの終端から０ｘＡ００００までのデータをメモリカード１００からリードすることで、常にレングスが０ｘ２００００のライトを行うこともできる。これは、ＮＡＮＤ型フラッシュメモリのようにブロックでデータをライトすることが効率的な記録デバイスに適している。ブロックとしては、記録ブロック、消去ブロック、またはそれらの整数倍の単位を用いることができる。

本参考例では、メモリカード１００を別のメモリカード１００'に差し替えた場合、ピンポンバッファ１１３（＃１〜＃Ｋ）の数Ｋ（Ｋは自然数）やピンポンバッファ１１３（＃１〜＃Ｋ）のサイズを可変とすることが可能である。メモリカード１００を抜いた際にデバイスドライバ１１０のアンロード処理１７９が行われ、別のメモリカード１００'を差した際にデバイスドライバ１１０のロード処理１７０が行われる。ロード処理１７０のステップ１７４で、別のメモリカード１００'に対するピンポンバッファ１１３（＃１〜＃Ｋ）を新たに確保することができる。また、ロード処理１７０においてメモリカード固有の情報を用いることで、ピンポンバッファ１１３（＃１〜＃Ｋ）の数Ｋを決定することも可能である。

本参考例では、図３０のピンポンバッファ１１３（＃１〜＃Ｋ）、即ち２＊Ｋ個のバッファを用いる例を示したが、ｍ＊Ｋ個（ｍは自然数）のバッファを用いても良い。ｍをバッファの並列数と呼ぶことにする。並列数ｍの値により、デバイスドライバ１１０が並列して行える処理の数が変化する。ｍ＝１の場合、例えば図２９において、ファイルシステムドライバ２００からの第２のライト要求１２２をデバイスドライバ１１０がバッファにコピーする処理と、デバイスドライバ１１０がメモリカード１００に第３のライト要求１２３を行う処理とは、双方の処理が同一のバッファ＃ｋ（ｋは自然数、１≦ｋ≦Ｋ）を用いていると同時に行うことができない。つまり図３１のフローチャートにおいて、ライト操作２３４Ａ、２３４Ｂの完了は必ず待たなければならないことになる。ｍ＝２の場合、１回まではライト処理２３４Ａ、２３４Ｂの完了を待たずに次の処理へ進める。一般的にｍ＝Ｍ（Ｍは自然数、１≦Ｍ≦ｍ）の場合、Ｍ−１回のライト処理２３４Ａ、２３４Ｂまではメモリカード１００に対するライトの待ち行列に挿入することができることになる。

ピンポンバッファ１１３（＃１〜＃Ｋ）の数Ｋとバッファの並列数ｍは、デバイスドライバ１１０が確保できるメモリ１８２の容量、データ記録装置１０１で許容できる書き込み遅延時間、メモリカード１００の物理転送レート、使用するファイルシステムドライバ２００の種類などに応じて最適な値を用いることができる。例えばＦＡＴファイルシステムを用いた場合、Ｋ＝２〜５、ｍ＝２を用いることができる。

ファイルを記録するアプリケーションは、データ記録装置のＯＳ上で動作するものであれば、利用することができる。アプリケーションプログラム３００がファイルシステムドライバ２００の処理やデバイスドライバ１１０の処理を包含する構成も可能である。また、ユーザ空間とカーネル空間の処理を区別しないＯＳ上でも、本実施形態を実施できる。ＦＡＴファイルシステムを例にとって説明したが、デバイスドライバ１１０の処理はファイルシステムフォーマットには依存していないため、他のファイルシステムにも適用できる。

本参考例では、図２７のような撮像記録装置１０１Ｂに適用する例を示したが、ＯＳが搭載されたデータ記録装置であれば、この形態に限るものではない。例えば撮像記録装置１０１Ｂに本発明を適用した場合、より高い記録レートを想定した装置にすることが可能である。つまり、レンズ１９４を通して撮影した映像データと、マイク１９５を通して集めた音声データとを、高いビットレートで高品質にメモリカード１００にリアルタイム記録することが可能となる。

本参考例では半導体メモリカードに適用する例を説明したが、半導体メモリカード以外の記録デバイスに対しても適用できることは明らかである。

第４の参考例
本参考例は、第３の参考例において、データ記録装置１０１のメモリ１８２上に確保された複数の物理メモリ領域を１つのメモリ記述子リストとして記述でき、かつ２つ以上のメモリ記述子リストを連結できる場合に適用できる例である。データ記録装置１０１の構成は第１の実施の形態と同じであり、デバイスドライバ１１０のみが異なる。

メモリ記述子リストは、第２の参考例において図２３を用いて説明したものと同じである。

デバイスドライバ１１０におけるロード処理１７０Ｄを図４１に示す。最初にデバイスドライバ１１０のインスタンスをメモリ１８２上にロードする（１７１Ｄ）。次に、デバイスドライバ１１０の初期化処理を行う（１７２Ｄ）。ここで、第３の参考例とは異なり、バッファ２６３を確保する代わりにライト処理用のバッファリストの領域を確保する（１７６Ｄ）。バッファリストは、図２３のメモリ記述子リスト２７０と同様のリストであり、リストの行数の上限を設定し、情報の格納に十分な量のバッファリストの領域を確保すれば良い。バッファリストを用いてライト中に新しいリストで上書きされるのを防ぐため、第１の実施の形態と同様にピンポンバッファリストにしても良い。バッファリスト（又はピンポンバッファリスト）の個数はＫ個（Ｋは自然数）に限定する。バッファリストは、アンロード時に解放される。

デバイスドライバ１１０におけるライト処理を、図４２のフローチャートを参照して説明する。バッファリストは、Ｋ個（Ｋは自然数）確保するとする。まず、要求データと連続するアドレスのデータを持つバッファリストｋ（ｋは自然数、１≦ｋ≦Ｋ）が存在するかどうかを判定する（ステップ２３１Ｄ）。ここでアドレスとは、メモリカード１００上の論理アドレス又は物理アドレスである。第２のライト要求１２２と連続するアドレスのデータを持つバッファリストｋが存在する場合は、要求データのリストをコピーするターゲットバッファｗをバッファｋとする（２３２Ｄ）。存在しない場合は、要求データのリストをコピーするターゲットバッファリストｗを任意に決定する（２３３Ｄ）。この決定方法は、第３の参考例と同様である。ターゲットバッファリストｗが決定されると、バッファリストｗ内のデータのライト処理を行う（２３４Ｄ−１）。但し、ターゲットバッファリストｗ内にデータが入っていない場合には、ライトを行わない。

次に、データの長さが上限に収まるように部分データのリストをバッファリストｗにコピーする（２３５Ｄ）。データの長さの上限は、デバイスドライバ１１０の初期化処理１７２Ｄなどで予め設定した値を使用する。この値としては、例えばメモリカード１００が受け付けるライト要求の長さの最大値を用いることができる。バッファリストｗにコピーするデータの長さが上限に到達したかどうかを判定し（２３６Ｄ）、到達していなければ終了する。到達していればバッファリストｗ内のデータのライト処理（２３４Ｄ−２）を行う。今回の要求のデータが残っているかどうかを判定し（２３７Ｄ）、残っていればステップ２３５Ｄに戻る。残っていなければ終了する。以上のようにして、デバイスドライバ１１０のライト処理１３０Ｄを行う。

今回の要求データがバッファリストｗに連続する場合のコピー処理は、第２の参考例において図２６を参照して説明した通りである。

デバイスドライバ１１０のライト以外の処理１５０、タイマーライト起動スレッド１６０は、基本的に第３の参考例と同様である。また、デバイスドライバ１１０の処理１１１も基本的に第３の参考例と同様である。

本参考例は、データを連結させるためにリスト上でデータのリストを連結させている。そのため、メモリ１８２上でデータのコピーを行う必要がなくなり、複数の物理メモリ領域を１つのメモリ記述子リストとして記述できる。さらには、２つ以上のメモリ記述子リストを連結できる条件下においては、第３の参考例より高速なライト処理を行うことができる。

実施の形態
本実施形態は、第１，２，３，４の参考例において、ライトの遅延時間が極めて小さいことが要求されるデータがある場合、そのライト要求のみをキャッシュせずに即座にライトする機構を設けることができるものである。

本実施形態におけるデバイスドライバの処理１１２を図４３に示す。図４３において、、第１，２，３，４の参考例と異なる点は、ライト操作１３０を行う前に、制約条件に当てはまるかどうかを判定するステップ２３１を設け、当てはまる場合には制約時のライト操作２３０を行うようにしたものである。この制約条件は、任意の条件で良い。例えば、メモリカードへライトするターゲットアドレスの範囲や、データのレングス、又はそれらの組み合わせなどの条件で決定することができる。この制約条件の設定方法は、デバイスドライバ１１０の初期化操作（図４のステップ１７２参照、図２４のステップ１７２Ｃ、図４２のステップ１７２Ｄ参照）にて設定する方法や、要求の受付処理１２５にて要求毎に設定する方法などがある。

制約時のライト操作２３０について、図４４のフローチャートを参照して説明する。まず、要求データと重複するアドレスのデータを持つピンポンバッファ１１３が存在するかどうかを判定する（ステップ２３２）。存在する場合には、ピンポンバッファ１１３内のデータのライト操作を行う（ステップ１３４）。ステップ１３４の操作は、次の理由により実施する。要求データをライトするメモリカード１００のアドレス領域と重なるライト要求がピンポンバッファ１１３にキャッシュされていると、後でそのピンポンバッファ１１３内のデータがライトされてメモリカード１００上のデータに矛盾が生じるためである。ステップ２３２の操作を実施したのち、要求データのライト操作を行い（ステップ２３３）、終了する。

本実施形態は、ライトの遅延時間が極めて小さいことが要求されるデータ、例えばファイルシステムの管理データ等に対して、ライト要求をキャッシュせずに即座にライトすることができる。リアルタイムにライトするデータとキャッシュして高速にライトするデータを区別することができるため、ライトの転送レートを高めつつも高い信頼性を持つデータ記録装置を構成することが可能となる。

映像・音声などの大容量データをファイル形式で高速に記録する必要のあるビデオカメラ、カメラレコーダに有効である。 また、カメラレコーダなどリアルタイム動作が必要なデータ記録装置と共通の記録メディアを使用し、映像・音声などの大容量データを編集・記録する必要のある映像編集装置、データ記録装置に有効である。

本発明の第１の参考例におけるデータ記録装置の構成図 同第１の参考例におけるデータ記録装置の内部構成図 同第１の参考例におけるデバイスドライバの処理を示す図 同第１の参考例におけるデバイスドライバのロード処理を示すフローチャート 同第１の参考例におけるＯＳのメモリ空間におけるライト処理のバッファの確保を示す図 同第１の参考例におけるプログラムの階層構成図 同第１の参考例におけるライト処理を示す図 同第１の参考例態におけるデバイスドライバのライト処理を示すフローチャート 同第１の参考例におけるバッファ内にデータがない場合のデバイスドライバのライト処理を示す図 同第１の参考例におけるバッファ内のデータと連続する場合のデバイスドライバのライト処理を示す図 同第１の参考例におけるバッファ内のデータと連続しない場合のデバイスドライバのライト処理を示す図 同第１の参考例におけるバッファ内のデータと連続し、境界を跨ぐ場合のデバイスドライバのライト処理を示す図 同第１の参考例におけるバッファ内のデータと連続せず、境界を跨ぐ場合のデバイスドライバのライト処理を示す図 同第１の参考例におけるバッファ内のデータの消去ブロックのライト処理を示すフローチャート 同第１の参考例におけるバッファ内のデータの消去ブロックのライト処理を示す図 同第１の参考例におけるデバイスドライバのライト以外の処理を示すフローチャート 同第１の参考例におけるデバイスドライバのタイマーライト起動スレッドを示すフローチャート 同第１の参考例におけるタイマーライト処理を示す図 同第１の参考例のデータ記録動作の第１の説明図 同第１の参考例のデータ記録動作の第２の説明図 同第１の参考例のデータ記録動作の第３の説明図 同第１の参考例におけるプログラムの階層構成図 本発明の第２の参考例におけるメモリ記述子リストを説明する図 同第２の参考例におけるデバイスドライバのロード処理を示すフローチャート 同第２の参考例におけるデバイスドライバのライト処理を示すフローチャート 同第２の参考例におけるバッファリストを説明する図 本発明の第３の参考例のデータ記録装置を組み込んだ撮影記録装置の外観斜視図 同第３の参考例におけるＯＳのメモリ空間におけるライト処理のバッファの確保を示す図 同第３の参考例におけるライト処理を示す図 同第３の参考例におけるピンポンバッファを説明する図 同第３の参考例におけるデバイスドライバのライト処理を示すフローチャート 同第３の参考例におけるデバイスドライバのライト処理の効果を説明する図 同第３の参考例におけるデバイスドライバのライト処理の効果を説明する図 同第３の参考例におけるピンポンバッファ内にデータがない場合のデバイスドライバのライト処理を示す図 同第３の参考例におけるピンポンバッファ内のデータと連続する場合のデバイスドライバのライト処理を示す図 同第３の参考例におけるピンポンバッファ内のデータと連続しない場合のデバイスドライバのライト処理を示す図 同第３の参考例におけるピンポンバッファ内のデータと連続し、境界を跨ぐ場合のデバイスドライバのライト処理を示す図 同第３の参考例におけるピンポンバッファ内のデータと連続せず、境界を跨ぐ場合のデバイスドライバのライト処理を示す図 同第３の参考例におけるデバイスドライバのライト以外の処理を示すフローチャート 同第３の参考例におけるタイマーライト処理を示す図 同第４の参考例におけるデバイスドライバのロード処理を示すフローチャート 同第４の参考例におけるデバイスドライバのライト処理を示すフローチャート 本発明の実施の形態におけるデバイスドライバの処理を示す図 同実施の形態におけるデバイスドライバの制約時のライト処理を示すフローチャート ＦＡＴファイルシステムの構成を説明する図 ファイルアロケーションテーブルの記録情報を説明する図 ＦＡＴファイルシステムにおけるファイルの記録手順を示すフローチャート ファイルシステムのクラスタとメモリカードの消去ブロックとの一般的な関係を示す図 ライトの転送レートが低下する現象を説明する図

符号の説明

１００ メモリカード １０１ データ記録装置
１０２ ＰＣ １０５ 消去ブロック
１０９ メモリカードコントローラ
１１０ デバイスドライバ １１１ デバイスドライバの処理
１１２ デバイスドライバの処理 １１３ ピンポンバッファ
１１５ フィルタドライバのプログラム
１２１ 第１のライト要求 １２２ 第２のライト要求
１２３ 第３のライト要求 １２４ 要求の受付処理
１３０ ライト処理 １４０ ライト操作
１６０ タイマーライト起動スレッド
１７０ ロード処理 １７９ アンロード処理
１８１ ＣＰＵ １８２ メモリ
１８３ 記憶デバイス １８４ 内部バス
１８５ バスコントローラ １８６ 入力デバイスコントローラ
１９０ メモリカードスロット １９１ 外付けドライブ
１９２ ディスプレイ １９３ 入力装置
２００ ファイルシステムドライバ
２１０ クラスタ ２６０ メモリ空間
２６３ バッファ ３００ アプリケーションプログラム
３１０ 元のファイル

Claims (2)

1. ＣＰＵとメモリと記録デバイスとをバスにて接続してなるデータ記録装置において、記録したデータを消去する際に所定の消去ブロックで前記データを消去する制約を有する前記記録デバイスにデータを記録するデータキャッシュ方法であって、
   前記記録デバイスに記録するデータを一次保持する一時保持器を、前記メモリにおいてそれぞれ複数のバッファからなる複数のピンポンバッファにて構成するとともに、前記消去ブロックのＮ倍（Ｎは自然数）のデータ長を保持可能な記録容量でもって予め設定しておく工程と、
   記録するデータを複数個の要求データに分割する工程と、
   前記要求データを前記消去ブロックのＬ倍（Ｌは自然数）の大きさを有する複数個の部分データに分割させてから前記ピンポンバッファに保持させる工程と、
   先に実施されたデータキャッシュ処理により保持されたデータが前記ピンポンバッファに一時保持されているか否かを判定する工程と、
   前記ピンポンバッファにデータが一時保持されていない場合には、前記ピンポンバッファのアドレス終端が前記消去ブロックの境界に一致するか否かを判定し、前記ピンポンバッファの終端が前記消去ブロックの境界に一致する場合には前記要求データを記録用データとして設定し、一致しない場合には前記要求データを前記ピンポンバッファに一時保持させる工程と、
   前記ピンポンバッファにデータが一時保持されている場合には、前記ピンポンバッファが一時保持している保持データと前記要求データとが、前記記録デバイスの記録アドレス上で連続するか否かを判定する工程と、
   前記保持データと前記要求データとが前記記録アドレス上で連続する場合には前記要求データを、前記保持データに連結させた状態で前記ピンポンバッファに一時保持させ、連続しない場合には前記保持データを記録用データとして設定するとともに、前記要求データを前記ピンポンバッファの空きバッファに保持させる工程と、
   前記ピンポンバッファに設定した前記記録用データの記録アドレス領域が前記消去ブロックのＮ倍となるか否かを判定する工程と、
   前記記録用データが前記消去ブロックのＮ倍になる場合には前記記録用データを消去ブロックの境界に一致する記録用データとし、Ｎ倍にならない場合には当該記録用データを前記消去ブロックのＮ倍にするのに必要となる不足データを、前記記録デバイスの前記不足データに対応するアドレス領域から読み出して前記記録用データに複写することで、当該記録用データを消去ブロックの境界に一致する記録用データにする工程と、
   前記消去ブロックの境界に一致した記録用データを前記ピンポンバッファから前記記録デバイスに書き込む工程と、
   の上記各工程を前記ＣＰＵにて実行するとともに、
   前記ＣＰＵは、
   前記一時保持器に保持データが一時保持されている場合、前記要求データが、他のキャッシュ対象データより書き込み時の遅延が小さいことを求られるデータであるか否かを判断し、
   前記要求データが小さい遅延を求められるデータである場合、前記複数の一時保持器それぞれにおいて前記保持データの記録アドレスと当該要求データの記録アドレスとが重複するか否かをさらに判断し、
   前記重複が生じる前記保持データと前記要求データとが存在する場合には、当該保持データを最初に書き込む記録用データとし、当該要求データを次に書き込む記録用データとする、
   ことを特徴とする記録デバイスのキャッシュ方法。
2. ＣＰＵとメモリと記録デバイスとをバスにて接続してなり、記録したデータを消去する際に所定の消去ブロックで前記データを消去する制約を有する前記記録デバイスにデータを記録するデータ記録装置であって、
   前記メモリにおいてそれぞれ複数のバッファからなる複数のピンポンバッファにて構成するとともに、前記消去ブロックのＮ倍（Ｎは自然数）のデータ長を保持可能な記録容量を有しておりかつ前記記録デバイスに記録するデータを一次保持する一時保持器を備えており、
   記録するデータを複数個の要求データに分割する機能と、
   前記要求データを前記消去ブロックのＬ倍（Ｌは自然数）の大きさを有する複数個の部分データに分割させてから前記ピンポンバッファに保持させる機能と、
   先に実施されたデータキャッシュ処理により保持されたデータが前記ピンポンバッファに一時保持されているか否かを判定する機能と、
   前記ピンポンバッファにデータが一時保持されていない場合には、前記ピンポンバッファのアドレス終端が前記消去ブロックの境界に一致するか否かを判定し、前記ピンポンバッファの終端が前記消去ブロックの境界に一致する場合には前記要求データを記録用データとして設定し、一致しない場合には前記要求データを前記ピンポンバッファに一時保持させる機能と、
   前記ピンポンバッファにデータが一時保持されている場合には、前記ピンポンバッファが一時保持している保持データと前記要求データとが、前記記録デバイスの記録アドレス上で連続するか否かを判定する機能と、
   前記保持データと前記要求データとが前記記録アドレス上で連続する場合には前記要求データを、前記保持データに連結させた状態で前記ピンポンバッファに一時保持させ、連続しない場合には前記保持データを記録用データとして設定するとともに、前記要求データを前記ピンポンバッファの空きバッファに保持させる機能と、
   前記ピンポンバッファに設定した前記記録用データの記録アドレス領域が前記消去ブロックのＮ倍となるか否かを判定する機能と、
   前記記録用データが前記消去ブロックのＮ倍になる場合には前記記録用データを消去ブロックの境界に一致する記録用データとし、Ｎ倍にならない場合には当該記録用データを前記消去ブロックのＮ倍にするのに必要となる不足データを、前記記録デバイスの前記不足データに対応するアドレス領域から読み出して前記記録用データに複写することで、当該記録用データを消去ブロックの境界に一致する記録用データに設定する機能と、
   前記消去ブロックの境界に一致した記録用データを前記ピンポンバッファから前記記録デバイスに書き込む機能と、
   前記要求データが、他のキャシュ対象データより書き込み時の遅延が小さいことを求められるデータである場合、前記複数の一時保持器それぞれにおいて前記保持データの記録アドレスと当該要求データの記録アドレスとが重複するか否かをさらに判断する機能と、
   記録アドレスが前記要求データと重複する保持データが存在する場合にはその保持データを最初に書き込む記録用データとし、その要求データを次に書き込む記録用データとする機能と、
   の上記各機能を前記ＣＰＵが備えていることを特徴とするデータ記録装置。

Images