diary/Kojima/2007-06-22
の編集
http://sv5.linet.gr.jp/index.php?diary/Kojima/2007-06-22
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
-- 雛形とするページ --
diary/Template
[[diary/Kojima]] ・reiser4 fs Plamo-4.22 へのテストのついでに,reiser-fs の新しいバージョン reiser4 の 2.6.21 用のパッチが公開されていたのをテスト. とりあえず[[カーネルへのパッチ:ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.21/reiser4-for-2.6.21.patch.gz]]と [[reiser4 fs を作るためのツール:ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz]], この[[ツールが使うライブラリ:ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz]] あたりを入手してビルド&インストール. reiser4 対応カーネルで起動して /proc/filesystems を見ると,reiser4 とい う名称で登録されている模様 kojima@vmathlon[~]% cat /proc/filesystems nodev sysfs nodev rootfs ... nodev devpts reiserfs reiser4 ext3 ext2 nodev ramfs ... テストのつもりで VMware Server 環境で,4GB ほどの SCSI HDD を追加して, そこに 2 つのパーティションを切り,それぞれを ext3 と reiser4 でフォー マットしてマウントしてみるとこんな感じ. Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sda1 5791176 3383800 2407376 59% / none 362816 60 362756 1% /dev /media 362816 0 362816 0% /media /tmp 362816 32 362784 1% /tmp /dev/sdb1 2055600 35880 1915300 2% /ext3 /dev/sdb2 1999700 188 1999512 1% /reiser4 ext3 の方がビットマップデータの予約領域とかを取る分,初期状態でも使用量 は多め. ここに /dev/sda1 (このパーティションは古いバージョンの reiserfs)にある linux-2.6.21.5 のディレクトリをコピーしてみる. コピー元のサイズはこんな感じで 516MB くらい. % du -h ~/Linux/Build/linux-2.6.21.5 516M Linux/Build/linux-2.6.21.5/ ext3 なファイルシステム上にコピーしてみると % time cp -a Linux/Build/linux-2.6.21.5/ /ext3/tmp/ 0.111u 11.633s 4:49.79 4.0% 0+0k 0+0io 1pf+0w reiser4 なファイルシステムだと % time cp -a Linux/Build/linux-2.6.21.5/ /reiser4/tmp 0.036u 10.906s 3:56.03 4.6% 0+0k 0+0io 0pf+0w という感じで,コピーの速度はやや reiser4 の方が速いかな,って感じ. 一方,コピー後のディスク使用量を見ると % df -h Filesystem サイズ 使用 残り 使用% マウント位置 ... /dev/sdb1 2.0G 563M 1.4G 30% /ext3 /dev/sdb2 2.0G 469M 1.5G 24% /reiser4 という感じで,元の reiserfs 上では 516MB なデータが,ext3 上では 563MB に増加している一方で,reiser4 上では 469MB と減少している. あまり詳しくは調べてないけど,ext3 はブロックアルゴリズムを使っているか らブロックサイズ(4KB)単位で使っていくため,小さなファイルが多ければ無駄 が多くなるのに対し,reiser4 だとブロックサイズ以下のファイルをまとめる ような処理をするので,ディスクの使用効率がよくなるらしい. そういう複雑な処理をしていると,クラッシュした際に大変だろうなと思って しまうけど,そもそも最近の HDD がクラッシュしたら,どんなに単純なファイ ルシステムだろうと手動でリカバリーすることは(サイズ的にも)不可能だから, そういう状況を気にする必要はないのだろうな. HDD のベンチマークである bonnie++ のデータとかも取ってはみたけど, VMware 上だからファイルシステムの性能よりもディスクキャッシュの性能を計っ ているような感じなので,今回は省略. ざっと見,結構興味深いファイルシステムではあるのだけど,旧バージョン (3.6)との互換性はないらしいし,元々の開発者の Hans Reiser 氏が妻の殺害 容疑の被疑者になって開発から外れている状況だから,将来性とかを考えると 不確定な部分が多すぎるかな. 個人的には,古典的なブロックアルゴリズムにあれこれ継ぎ木して機能や性能 を無理やり向上させている ext3/ext4 よりは,新しい B*-tree 等のアルゴリ ズムを使っている reiser fs の方が好みではあるのだけど,reiser4 の採用は もう少し先な感じかなぁ. そうこうしているうちに,OpenSolaris の方から ZFS が移植されてきそうな風 向きではあるのだけれど.. #comment
タイムスタンプを変更しない
[[diary/Kojima]] ・reiser4 fs Plamo-4.22 へのテストのついでに,reiser-fs の新しいバージョン reiser4 の 2.6.21 用のパッチが公開されていたのをテスト. とりあえず[[カーネルへのパッチ:ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.21/reiser4-for-2.6.21.patch.gz]]と [[reiser4 fs を作るためのツール:ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz]], この[[ツールが使うライブラリ:ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz]] あたりを入手してビルド&インストール. reiser4 対応カーネルで起動して /proc/filesystems を見ると,reiser4 とい う名称で登録されている模様 kojima@vmathlon[~]% cat /proc/filesystems nodev sysfs nodev rootfs ... nodev devpts reiserfs reiser4 ext3 ext2 nodev ramfs ... テストのつもりで VMware Server 環境で,4GB ほどの SCSI HDD を追加して, そこに 2 つのパーティションを切り,それぞれを ext3 と reiser4 でフォー マットしてマウントしてみるとこんな感じ. Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sda1 5791176 3383800 2407376 59% / none 362816 60 362756 1% /dev /media 362816 0 362816 0% /media /tmp 362816 32 362784 1% /tmp /dev/sdb1 2055600 35880 1915300 2% /ext3 /dev/sdb2 1999700 188 1999512 1% /reiser4 ext3 の方がビットマップデータの予約領域とかを取る分,初期状態でも使用量 は多め. ここに /dev/sda1 (このパーティションは古いバージョンの reiserfs)にある linux-2.6.21.5 のディレクトリをコピーしてみる. コピー元のサイズはこんな感じで 516MB くらい. % du -h ~/Linux/Build/linux-2.6.21.5 516M Linux/Build/linux-2.6.21.5/ ext3 なファイルシステム上にコピーしてみると % time cp -a Linux/Build/linux-2.6.21.5/ /ext3/tmp/ 0.111u 11.633s 4:49.79 4.0% 0+0k 0+0io 1pf+0w reiser4 なファイルシステムだと % time cp -a Linux/Build/linux-2.6.21.5/ /reiser4/tmp 0.036u 10.906s 3:56.03 4.6% 0+0k 0+0io 0pf+0w という感じで,コピーの速度はやや reiser4 の方が速いかな,って感じ. 一方,コピー後のディスク使用量を見ると % df -h Filesystem サイズ 使用 残り 使用% マウント位置 ... /dev/sdb1 2.0G 563M 1.4G 30% /ext3 /dev/sdb2 2.0G 469M 1.5G 24% /reiser4 という感じで,元の reiserfs 上では 516MB なデータが,ext3 上では 563MB に増加している一方で,reiser4 上では 469MB と減少している. あまり詳しくは調べてないけど,ext3 はブロックアルゴリズムを使っているか らブロックサイズ(4KB)単位で使っていくため,小さなファイルが多ければ無駄 が多くなるのに対し,reiser4 だとブロックサイズ以下のファイルをまとめる ような処理をするので,ディスクの使用効率がよくなるらしい. そういう複雑な処理をしていると,クラッシュした際に大変だろうなと思って しまうけど,そもそも最近の HDD がクラッシュしたら,どんなに単純なファイ ルシステムだろうと手動でリカバリーすることは(サイズ的にも)不可能だから, そういう状況を気にする必要はないのだろうな. HDD のベンチマークである bonnie++ のデータとかも取ってはみたけど, VMware 上だからファイルシステムの性能よりもディスクキャッシュの性能を計っ ているような感じなので,今回は省略. ざっと見,結構興味深いファイルシステムではあるのだけど,旧バージョン (3.6)との互換性はないらしいし,元々の開発者の Hans Reiser 氏が妻の殺害 容疑の被疑者になって開発から外れている状況だから,将来性とかを考えると 不確定な部分が多すぎるかな. 個人的には,古典的なブロックアルゴリズムにあれこれ継ぎ木して機能や性能 を無理やり向上させている ext3/ext4 よりは,新しい B*-tree 等のアルゴリ ズムを使っている reiser fs の方が好みではあるのだけど,reiser4 の採用は もう少し先な感じかなぁ. そうこうしているうちに,OpenSolaris の方から ZFS が移植されてきそうな風 向きではあるのだけれど.. #comment
テキスト整形のルールを表示する