Device Mapper
現状では、ファイルシステムの構成方法は以下の通り。
- RootDisk(CDなど、物理的なディスク)から起動
RootDisk --マウント--> 暗号化ファイルシステムイメージ --ループバック・復号化(dm-crypt+LUKS)--> 圧縮ファイルシステム(Squashfs) --展開--> 2Gづつ分割されたext3ファイルシステムイメージ --ループバック・結合(dm-linear的)--> ext3ルートファイルシステム --Copy-on-Writeファイルと重ね合わせる(cowloop)--> 完成
- NBDから起動
NBDサーバー(複数) --multipathで結合(RAID Multipath)--> 暗号化ファイルシステム --復号化(dm-crypt+LUKS)--> 以下同じ…
となっています。
この内、暗号化ファイルシステムの復号化と、分割ファイルシステムイメージの結合にDevice Mapperを使っています。
で、Copy-on-Writeと、multipathもDevice Mapperでできるのではなかろうか、ということが今日のお題。
cowloopは結局LVM2のスナップショット機能と同じことをやっているわけで、そのスナップショット機能は結局Device Mapperを使っている。
ちなみに、KNOPPIXの使っているunionfsは、cowloopとは根本的に違うもの。cowloopが低レベルのブロックデバイスレベルでCopy-on-Writeしているのに対し、unionfsは高レベルのVFSレベル。
cowloopは単純に元デバイスに対するXORをCopy-on-Writeファイルに記録すれば良い(と思う)のに対し、unionfsはVFS上のファイル単位でCopy-on-Writeを行う必要がある。
cowloopはユーザースペースからほぼ完全に隠蔽されるのに対し、unionfsはかなりおおっぴら。
ただしcowloopでは、Copy-on-Writeしたブロックデバイスより上のレイヤはすべてのレイヤが書き込み可能でなければならない。つまり、このcowloopのレイヤより上にSquashfsを使えない。だから、cowloop -> Squashfs -> マウント はできなくて、Squashfs -> ext3イメージ -> ループバックマウント -> cowloop -> マウント でないといけない。
と、横道にそれた。で、cowloopはいまいちメジャーじゃないので、dm-snapshotを使おうと。
Multipath機能はソフトウェアRAIDのmultipath.koを使っているのだけども、これをDevice Mapperのdm-multipath.koにしようと。
で、誰かがそのうちdm-compressを作ってくれるだろうから…そのときにSquashfsもDevice Mapperにする、と。
以下リンク。
- dm-snapshotはどこ?
Device Mapper周りは全部英語ですよ。
0.3どうする
いつでも0から書き直したいですよ。まだ0.2ができていないですよ。
まず、/VIVER/dev/root.1やら、/VIVER/mapper/cryptroot、/VIVER/dev/linearizedrootだの、やたらと'root'がつくデバイスノードばかりだったりで、デバイスノードがもうワケワカラナイので、どうにかしたい。
dmsetupのあたりもワケワカラナイですよ。
その前にシェルスクリプトで書いているところをどうにかしたい。いちいちトリッキーな文字列処理を使うのもちょっと…。あと、変数が常にグローバル。
swapの検出ができていない。Sun OSのパーティションはどう検出すれば?無視?
全般に、例外処理がよろしくない。
そろそろNBDに認証を。(これは認証ゲートウェイ風味のものを使う予定)
正常にシャットダウンできない問題もそろそろ。
VIVER Pacsのinfo.xmlは記述性が低すぎる。仕様変更必至。Pacs、.pacという名前と拡張子も変えたい。.rcはどうだろう。(VIVER RCsなんて言ったら何の略だかさっぱりわからない)
NBD接続のRAID Multipathは、ちゃんとフェイルオーバーしてくれるんでしょうか。してくれないんじゃないでしょうか。負荷分散もしてくれないんじゃないでしょうか。
Zeroconfを全面導入。サービス(NBD含む)自動検出。
enbdってどうなんでしょう?
Squashfsは2GBを超えられない
2GB以上のファイルを含められないだけでなく、作成後のファイル自体も2GBを超えられない、という事実に気づく。どうする。
おとなしくcloopを使えば良いのだろうか。アルファシステムズ社がかなり注力して改良しているようだし。
特にAccelerated-KNOPPIX(SATAで実装されているNCQ:Native Command Queuing的な、cloopのソフトウェアレベルでの改良)は、かなりすごいと思う。mksquashfsでもmkisofsでもファイルの記録位置を制御できるから、かな〜りがんばれば同じようなことをできなくもないのだけども、そんなに張り合ってどうする。
SATA II接続のCD/DVDドライブって、NCQしているのかな?
上のページに、「ページキャッシュへの先読み」というところがあるけども、前から疑問なんだけど、これって
dd if=/disk/cryptroot of=/dev/null seek=*** count=***
で良いのだろうか?
Mandriva Linuxのカーネルには、''gzloop''という拡張が入っている。要調査。
(MandrakeMoveはコレらしいぞっ!)