exofs designを読んでみる

http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=blob;f=Documentation/filesystems/exofs.txt;hb=refs/heads/exofs

 

* file system control block (on-disk superblock)はIDを振られたオブジェクトに格納されている(これはcommon.hにて定義される)

  file system control blockに含まれている情報はマウント時のインメモリsuperblock構造を埋めるために使われる。mkexofs.cからファイルシステムが使われる前にオブジェクトは生成される。そこに含まれる情報は以下のとおりである。

 - file systemのmagic number

 - 次に割り当てられるinode number

* 各ファイルに含まれるデータは個別のオブジェクトに格納されている。(そしていずれファイルを複数のオブジェクトにまたがって格納できるようになるが、これはまだ実装されていない)

* ディレクトリはファイルとして扱われ、そのディレクトリに含まれている<ファイル名, inode #>のペアのリストを含む。object IDはファイルのinode numberに対応しており、bitmapに従い、アロケーションされる。(このbitmapは別のオブジェクトに格納される)現在はカウンタを使用し、アロケーションされている

* 各ファイルのcontrol block(on-disk inode)はオブジェクトのattributeに格納される。これは通常のファイルおよびほかのtype(ディレクトリ、デバイスファイル、symlink)に当てはまる。

* 認証情報はメモリ上に生成される際に(つまりディスクから読み込まれるときや、作成されるときに)各オブジェクト(inodeとsuperblock)ごとに生成される。

* Async OSDオペレーションは可能なときに使用されるが、targetはout of order実行をしてもよい。ここではcreate, delete, readpage, writepage, update_inodeおよびtruncateのことについて記載する。以下のオペレーションペアは記載された順に実行されるべきであり、この順序が入れ替わることを防ぐ必要がある。

 - 以下のものはOBJ_CREATEDとOBJ_2BCREATEDフラグで処理される。オブジェクトがcreateのcallback functionのOSD上に存在しているとわかったときか read_inodeが成功したときにOBJ_CREATEDがにsetされる。

 OBJ_2BCREATEDはcreate functionの最初にsetされるのでこの場合は待つ必要があることがわかる。

   - create/delete: deleteはオブジェクトがOSD上に作成されるまで待つべきである。

   - create/readpage: readpageは0で埋められたpageを返すべきである。writeが実行されようとしている(create, writepage, readpage) 場合は)pageがロックされ create/writepageと同様である。