激しくかきかけ
上の図について↑↑ †
- FS FRONTの役割
- パスの一部を解析して動的にマウントされたコンクリートFSに処理をお願いする。
- ファイル-プロセスの関連を管理する。
- コンクリートFSの動的な追加・削除をサポート
MonAPIの提供するFS API（案） †
- コンクリートFSの追加
- コンクリートFSの削除
- ディレクトリ情報の取得
- ディレクトリ操作
- ディレクトリ作成
- ディレクトリ削除
- ディレクトリ移動(上二つの組み合わせではなくて本当に移動)
- ファイル情報の取得
- ファイル操作
- ファイル作成
- ファイル削除
- ファイル移動(上二つの組み合わせではなくて本当に移動)
- ファイルオープン
- 追加書き込み
- ファイルがない場合新規作成
- ファイルがある場合エラー
- 読み/書き
- 読み取り専用（複数のプロセスが同時に開ける)
- 読み書き
- 書き込み専用
- アクセス権の操作（今はいらないか？）
キーワード †
- FAT16/FAT32/etcの種々のファイルシステムをマウントできること
- ディスクドライバと結合が疎であること
- アプリから見てファイルシステムの違いを意識しなくて良いこと
- キャッシュは？
- 複数スレッドでパフォーマンスアップ？
FATロジック作成に当たって注意すべき点 †
- ファイルを同時にオープンできるように考慮する
- 1ファイルオープンにつき何らかの情報構造体を保持する。FATFSに対する操作のための情報か？(プロセスに結びつくかどうかは現時点では微妙)
- 読み込み･書き込み中クラスタとか
- 書き込み用同期オブジェクト
- ファイルポインタ的なもの？
実装ロードマップ †
- FATロジックの作成(Windows上)⇒流用できるものがあれば流用したい
- ファイルシステムフロントを作成。
read †
- MonAPIでファイルオープン
- FS FrontでどのFSサーバーに振るかを決定する(パスにより判定)
- FS Front内でファイル管理情報構造体を割り当てる(FS Front分とｘｘFS分)⇒xxFS分はサイズを問いかける
- xxFS#openを呼び出す(xxFS側は情報構造体を引数で受取り、複数ファイルをopen出来るような仕組みで実装する。⇒どう実装しよう？)
メモ †
- 「このファイルのオフセットxxのデータをここのバッファへ読んでくれ」ということを複数ファイル同時進行で出来なければならない
- ひょっとしてxxFSがマルチスレッドじゃなきゃいけないのか？(ループにして1アクセスごとに切り替えるか？)
コメント †
コメントはありません。 コメント/議論/ファイルシステム/サーバー化?
- 元ねたのファイルなくしてしまいました・・・orz -- ひげぽん 2005-01-02 (日) 13:05:07
- 画像はPNGにすると文字の周りの微妙なゴミが出なくて良い感じです。 -- 2004-10-26 (火) 20:21:13
MonaFS.jpg