カーネル空間内の管理データを格納する格納手段と、前記管理データをユーザ空間から参照する参照手段と、前記管理データをユーザ空間から更新する更新手段とを備えることを特徴とするファイルシステム。カーネル空間内の管理データを格納する格納工程と、前記管理データをユーザ空間から参照する参照工程と、前記管理データをユーザ空間から更新する更新工程とを備えることを特徴とするファイルシステムの高速化方法。請求項2に記載の方法の各工程をコンピュータにて実行させるためのプログラム。しかしながら、FUSEのような仕組みでは、VFS管理下のモジュールからユーザ空間上のプロセスへ、つまりカーネル空間からユーザ空間へ、ファイル操作命令、管理用データ、読み書き対象のデータ、といった情報を空間間コピーしていた。また、読み書き対象のデータは、再度、カーネル空間にコピーされることとなる。つまり、FUSEのような仕組みを用いて同じ装置上の記録装置にアクセスする場合、用いない場合と比較して、空間間コピーがさらに2回実行されるので、空間間コピーの対象が多く、コピー量が多かった。そこで、本発明の目的は、空間間コピーの際のコピー量を削減し、アプリケーションからのファイルアクセスの速度を高速化することにある。本発明のファイルシステムは、カーネル空間内の管理データを格納する格納手段と、前記管理データをユーザ空間から参照する参照手段と、前記管理データをユーザ空間から更新する更新手段とを備えることを特徴とする。本発明によれば、空間間コピーの際のコピー量を削減することで、アプリケーションからのファイルアクセスの速度を高速化することが可能となる。また、本発明によれば、コピーに要するバッファを削減することで、メモリ使用量も削減できる。以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。先ず、本発明の第1の実施形態について説明する。図1は、本発明の第1の実施形態である、ユーザ空間上で動作するファイルシステムの実行対象のハードウェア構成を示すブロック図である。図1において、101はCPUであり、プログラムを実行する処理装置である。102はRAMであり、CPU101の実行ワークエリアとして使用される。具体的には、変数データの格納領域、スタック領域、ヒープ領域等として使用される。103はROMであり、CPU101で実行されるプログラムがCPU101で実行可能な形態にコンパイルされた状態で格納されている。104はバスであり、CPU101、ROM102、RAM103、後述の入力インタフェース105、出力インタフェース106、記録装置107を相互接続する。105は入力インタフェースであり、キーボード、マウス、ボタンからの入力信号を伝達する。106は出力インタフェースであり、CPU101の実行結果の出力信号を伝達する。107は記録装置であり、ファイルシステムの読み書き対象である。例えばUSBメモリ、SDカード、ハードディスクが例として挙げられる。100は装置であり、CPU101から記録装置107までの要素が格納される。図2は、コンピュータ等の装置100で動作する、本実施形態に係るソフトウェア構成のブロック図を示している。201はアプリケーションであり、システムコールを介してカーネルにファイルアクセスを依頼する。書き込みの際はアプリケーション201からカーネルに、ファイルの内容となる書き込みデータがコピーされ、読み込みの際はカーネルからアプリケーション201に、ファイルの内容である読み込みデータがコピーされる。202は通信デーモンである。203は通信ライブラリであり、後述の通信モジュール206とやりとりを行う。通信ライブラリ203は、前述のFUSEライブラリと同様な役割を担う。204はファイルシステムであり、ユーザ空間上で動作する。通信ライブラリ203とファイルシステム204は、通信デーモン202のプロセス内で動作する。通信ライブラリ203およびファイルシステム204のバイナリ自体は、通信デーモン202と一体でなくとも構わない。205はVFSである。206は通信モジュールであり、前述のFUSEモジュールと同様な役割を担う。207は管理データ用バッファである。管理データとは、ファイル操作命令の種別、アプリケーション201のプロセスIDやグループID、通信ライブラリ203との通信で用いるユニークID等、通信モジュール206と通信ライブラリ203とのやりとりに要するデータである。管理データ用バッファ207では、この管理データを格納する。208は書き込みデータ用バッファであり、アプリケーション201から、ファイルに書き込むデータが渡された場合、それを格納する。209は読み込みデータ用バッファであり、アプリケーション201からファイルの読み込み命令が実行された場合、記録装置107から読み取ったファイルの内容を格納する。なお、207、208、209の各バッファは、通信モジュール206の外部であっても、通信モジュール206からアクセス可能であれば問題ない。210はデバイスドライバであり、記録装置107へのアクセスを処理する。211はファイルメタデータ用バッファである。ファイルメタデータとは、記録装置107に読み書きする、ファイルの位置情報等の、書き込みデータおよび読み込みデータ以外の記録装置107上のファイルに関する情報である。ファイルメタデータ用バッファ211には、このファイルメタデータを格納する。212は書き込みデータ用バッファ参照テーブルであり、書き込みデータ用バッファ208へのポインタを格納する。213は読み込みデータ用バッファ参照テーブルであり、読み込みデータ用バッファ209へのポインタを格納する。なお、ファイルメタデータ用バッファ211、212および213の各参照テーブルは、デバイスドライバ210の外部であっても、デバイスドライバ210からアクセス可能であれば問題ない。以下、図1のハードウェア上で、図2のソフトウェア構成を用いて実行するプログラムを、図3、図4及び図5を用いて説明する。図3は、前記プログラムの初期化部分の一部を示すフローチャートである。図3の中央の列にあるステップS301、S302、S305、S306、S310、S311は、図2の通信デーモン202が実行するステップである。同様にステップS303、S304は、通信モジュール206であり、ステップS307、S308、S309は、デバイスドライバ210で実行するステップである。ステップS301より、処理が開始される。ステップS302において、通信デーモン202は、管理データ用バッファをマップする命令を実行する。ここで管理データとは、図2の管理データ用バッファ207の説明の際に述べた、通信モジュール206と通信ライブラリ203のやり取りで用いるデータである。マップする命令はシステムコールによりカーネルに伝達される。システムコールは、例えばmmapやioctlを使用できる。ステップS303において、通信モジュール206は、図2の管理データ用バッファ207、書き込みデータ用バッファ208、読み込みデータ用バッファ209の3つのバッファを確保する。ここで、3つのバッファは、ステップS302の実行前に確保されていても問題ない。例えば、通信モジュール206の初期化開始直後などに確保しても問題ない。ステップS304において、管理データ用バッファを通信ライブラリ203から直接参照可能なようにマップする。例えばLinuxでは、remappfnrange関数やnopage関数を使用する。マップ終了後、ステップS305に遷移し、ステップS302からの管理データ用バッファマップ命令を終了する。以上の処理で、通信デーモン202は、カーネル空間内の管理データ用バッファ207の内容を、空間間コピーすることなく参照可能となる。次にステップS306において、通信デーモン202は、ファイルメタデータ用バッファマップ命令を実行する。ステップS302の場合と同様に、ステップS306のマップ命令は、システムコールでカーネルに伝達される。システムコールは、先と同様に、例えばmmapやioctlを使用できる。ステップS307において、デバイスドライバ210は、図2のファイルメタデータ用バッファ211を確保する。ここで、ステップS306の実行前にバッファは確保されていても問題ない。例えば、デバイスドライバ210の初期化開始直後などに確保しても問題ない。ステップS308において、ファイルメタデータ用バッファ211をファイルシステム204から直接参照可能なようにマップする。ここでステップS304と同様に、例えばLinuxでは、remappfnrange関数やnopage関数を使用する。次にステップS309において、図2の書き込みデータ用バッファ参照テーブル212が書き込みデータ用バッファ208を、読み込みデータ用バッファ参照テーブル213が読み込みデータ用バッファ209をポイントするよう設定する。ステップS310に遷移し、ステップS306からのマップ命令を終了する。ステップS311に遷移し、ステップS301からの処理を終了する。図2において、ステップS309の処理を、ステップS307及びS308の処理の後に行ったが、ステップS303の処理、つまり書き込みデータ用バッファ208、読み込みデータ用バッファ209が確保された後なら、実行順序は特に問わない。以上の処理で、管理データ及びファイルメタデータは、ユーザ空間から、コピーの必要なく参照することが可能となる。また、書き込みデータ及び読み込みデータを、カーネル空間内で、通信モジュール206とデバイスドライバ210で共有することが可能となる。図4及び図5は、前記プログラムの記録装置107へのファイル読み書きのアクセスを高速化する高速化方法を示すフローチャートである。記載スペースの都合上、1つのフローを図4と図5に分割する。ステップS401より、処理が開始される。ステップS402において、アプリケーション201よりシステムコールが実行される。ステップS403において、VFS205はシステムコール実行時に指定されたパスより、VFS管理下のモジュールに処理を振り分ける。ここでは通信モジュール206の処理が実行される。ステップS404において、通信モジュール206は管理データ用バッファ207に管理データを作成する。ステップS405において、アプリケーション201からのシステムコールに書き込みデータがあるか判定する。ある場合、YESとなりステップS406に遷移し、ない場合、NOとなりステップS407に遷移する。ステップS406において、通信モジュール206は、アプリケーション201のプロセス空間から書き込みデータ用バッファ208に、書き込みデータを空間間コピーする。コピー終了後、ステップS407に遷移する。ステップS407において、通信モジュール206は、通信デーモン202に、通知準備が完了した旨を通知する。ここで通知の方法は特に問わない。FUSEで行っているように、FUSEデーモンの読み込み処理ルーチンに通知の旨を記載し、スリープ処理を起床させてもよい。ステップS408において、通信デーモン202は通信ライブラリ203の関数を実行し、管理データ用バッファ207を参照し、通信モジュール206がステップS404で準備した管理データをコピーすることなく参照する。その後、参照した管理データに基づき、ファイルシステム204の関数を実行する。ステップS409において、ファイルシステムの関数内で、デバイスファイルアクセスの箇所でread処理かそうでないwrite処理かを判定する。ここでread、writeは、記録装置107に読み込みか書き込みかの処理をすることを指す。例えば、ファイルの読み込み時、アクセス時間を更新する処理の場合は、ファイルメタデータのアクセス時間の箇所を書き込むことになるので、write処理となる。read処理の場合はYESとなり、ステップS414に遷移する。write処理の場合はNOとなり、ステップS410に遷移する。ステップS410において、ファイルシステム204は、ファイルメタデータ用バッファ211にあるファイルメタデータを参照する。なお、ファイルメタデータ用バッファ211へのファイルメタデータの書き込みは、後述のステップS414にて実施される。ステップS411において、ファイルシステム204は、ステップS410で参照したファイルメタデータと、ファイルシステム204内の計算より新たなファイルメタデータの更新部分を生成し、ファイルメタデータ用バッファ211のファイルメタデータを更新する。デバイスドライバ210は、ファイルメタデータ用バッファ211内のファイルメタデータを記録装置107に書き込む。ステップS412において、デバイスドライバ210は、書き込みデータ用バッファ参照テーブル212を介して書き込みデータ用バッファ208に書き込みデータがあるか判定する。書き込みデータがある場合、YESとなり、ステップS413に遷移し、ない場合、NOとなりステップS417に遷移する。ステップS413において、デバイスドライバ210は、書き込みデータ用バッファ参照テーブル212を介して書き込みデータ用バッファ208内の書き込みデータにアクセスし、書き込みデータを記録装置107に書き込む。書き込み後、ステップS417に遷移する。なお、本実施形態では先にステップS411においてファイルメタデータの書き込みを、後にステップS412とS413において書き込みデータの書き込みを行ったが、順序は逆でも問題ない。ステップS414において、デバイスドライバ210は、記録装置107からファイルメタデータを読み込み、ファイルメタデータ用バッファ211に書き込み、ファイルシステム204はファイルメタデータ用バッファ211内のファイルメタデータを参照する。ステップS415において、記録装置107内のファイルの内容である、読み込みデータを読み出す処理かどうか判定する。読み込みデータを読み出す処理の場合、YESとなり、ステップS416に遷移し、読み込みデータがない場合、NOとなり、ステップS417に遷移する。ステップS417において、ファイルシステム204内の関数実行が終了したか判定する。例えば1つの関数内に、readもしくはwriteのデバイスファイルアクセスを複数実施する場合がある場合、処理の繰り返しをここで判定する。まだreadもしくはwriteを要する処理が残存している場合、NOとなり、ステップS409に遷移する。残存していない場合、YESとなり、ステップS418に遷移する。ステップS418において、図5のステップS501に遷移する。図5のステップS501は、図4のステップS418からのフローの続きである。ステップS502において、通信デーモン202内の通信ライブラリ203は、管理データ用バッファ207内の管理データを更新する。ステップS503において、通信ライブラリ203は、管理データの更新を通信モジュール206に通知する。ここで通知方法は特に問わない。ステップS504において、通知を受信した通信モジュール206は、読み込みデータ用バッファ209に、ファイルの内容である読み込みデータがあるか判定する。ある場合、YESとなり、ステップS505に遷移し、ない場合、NOとなり、ステップS506に遷移する。ステップS505において、読み込みデータ用バッファ209からアプリケーション201に、読み込みデータを空間間コピーする。コピー終了後、ステップS506に遷移する。ステップS506において、通信モジュール206は、アプリケーション201が図4のステップS402において実行したシステムコールの結果を作成し、それをアプリケーション201にコピーする。ステップS507において、アプリケーション201にシステムコールの結果が戻り、システムコールの実行は終了となる。ステップS508に遷移し、一連の処理は終了となる。以上説明した方法で、通信モジュールと通信デーモン、通信デーモンとデバイスドライバ間で行われていた、ユーザ空間とカーネル空間間のコピー量は削減される。ところで、本実施形態においては、管理データ、ファイルメタデータ、ファイルの内容である書き込みデータ、読み込みデータの全てを、ユーザ空間とカーネル空間間でコピーしないようにした。しかし、一部だけを従来のようにコピーするようにしても本発明を適用できる。次に、本発明の第2の実施形態について説明する。第2の実施形態では、アプリケーション201から複数の読み書き、または、アプリケーション201が複数あり複数の読み書きが発生する場合に対処する方法として、IDで管理する方法を説明する。また同時に、書き込みデータ用バッファ208、読み込みデータ用バッファ209に格納したデータの管理についても補足する。第2の実施形態について、図2、図6、図7を参照しながら説明する。図6は、図4を改変したものであり、図7は図5を改変したものであり、太線で囲んだステップが、元の図面と異なる。太線で囲った箇所以外は、元と同じ処理となる。例えば、図4のステップS402と図6のステップS602とは同じ処理である。本実施形態では、上記の太線で囲った、改変された箇所のみ説明する。図6のステップS604において、管理データを管理データ用バッファ207に作成する際、IDも作成する。このIDは一意なものである。例えばプロセスID等は、同一プロセスからの複数アクセスを区別不可能となるため、本IDとして用いてはならない。ステップS606において、アプリケーション201の書き込みデータを、書き込み用データバッファ208にコピーする際、そのコピーされたデータに対し、ステップS604で作成されたIDを付与する。また、マークを作成する。このマークは、書き込み用データバッファ208にある書き込みデータが、記録装置107に書き込まれていないことを示す。マークを作成する処理は、例えば、特定にビットを立てる処理でも問題ない。ステップS608において、通信デーモン202内の通信ライブラリ203がファイルシステム204の関数を実行する際、管理データ用バッファ207を参照した際に得たIDも渡す。このIDは、ステップS604にて作成されたものである。渡し方は、例えば、関数の引数として渡してもよいし、通信デーモン202上に通信ライブラリ203とファイルシステム204がアクセスできる配列等を用意して渡してもよい。ステップS611において、ファイルメタデータを更新する際、ファイルシステム204はIDもファイルメタデータ用バッファ211に書き込む。なお、IDは記録装置には書き込まない。ステップS612において、書き込みデータを比較する際、ステップS611にてファイルメタデータ用バッファ211に書き込まれたIDと書き込みデータ用バッファ参照テーブル212からポイントされた書き込みデータ用バッファ208内のIDとを比較する。そして書き込みデータ用バッファ208内のどの書き込みデータが、記録装置107への書き込み対象か決定する。ここで、ファイルメタデータ用バッファ211のIDは固定である。ステップS613において、書き込みデータ用バッファ208内の書き込みデータを記録装置107に書き込む。その際、ステップS606において作成されたマークを消去する。ステップS614において、ファイルメタデータを参照する際、IDをファイルメタデータ用バッファ211内で付与する。このIDは、ステップS608においてファイルシステム204が通信ライブラリ203から渡されたものである。ステップS616において、読み込みデータを格納した読み込みデータ用バッファ209に、IDを付与し、マークを作成する。このIDは、ステップS614においてファイルメタデータ用バッファ211に付与されたものである。またマークは、ステップS606と同様に、ビットを立てる処理でもよい。次に、図7のステップS704において、読み込みデータを比較する際、図6のステップS616にて読み込みデータ用バッファ209に書き込まれたIDと、管理データ用バッファ207内のIDを比較する。そして、読み込みデータ用バッファ209内のどの読み込みデータが、アプリケーション201への読み込み対象か決定する。ここで、管理データ用バッファ207内のIDは固定である。ステップS705において、読み込みデータ用バッファ209内の読み込みデータをアプリケーション201にコピーする。その際、図6のステップS616において作成されたマークを消去する。以上説明した、IDを用いる方法で、複数の読み書きに対応できる。また、マークを作成、削除することで、書き込みデータ用バッファ208内の書き込みデータ、読み込みデータ用バッファ209内の読み込みデータを削除するタイミングの決定が容易になる。ところで、本実施形態では、IDを用いる方法、マークを作成、削除する方法を記したが、それぞれの役割は独立しているため、別々に実施されても、それぞれの効果に変化はない。第1、第2の実施形態では、書き込みデータ用バッファ208、読み込みデータ用バッファ209を通信モジュール206内に配置したが、通信モジュール206およびデバイスドライバ210から参照可能なカーネル内であれば、配置場所は特に問わない。デバイスドライバ210に両バッファが配置される場合、そのバッファを参照するバッファ参照テーブルは、通信モジュール206に配置される。また、両バッファが通信モジュール206、デバイスドライバ210の外に配置される場合、バッファ参照テーブルは通信モジュール206、デバイスドライバ210の両方に配置される。さらに、管理データ用バッファ207、書き込みデータ用バッファ208、読み込みデータ用バッファ209は、ページ機構の一部として確保してもよいし、専用のメモリ領域例えば他の用途に使用しない、予約領域に確保してもよい。また、実施例2において、マークを作成、削除したが、このマークは、ページ機構使用時は、ページのダーティビットでもよい。また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。