2と4のリビジョン間の差分 (その間の編集: 2回)

LVM再考

ZFS(on Linux)とLVM2を比較する

LVMとは

複数のディスクにまたがるファイルシステムを作ったり出来るようにするもの
構造としては、物理ボリューム(PV)を物理エクステント(PE)という単位に分割して、物理エクステントの組み合わせで論理ボリューム(LV)を構成するようになっている。
物理ボリュームの追加・削除や論理ボリュームのサイズ変更は後から可能
ついでにストライピングやミラーリングも出来たりする

ZFS?

ZFSでもファイルシステムのサイズは可変だし、プールにパーティションを追加できるじゃない。

ZFSがあればLVMは要らない…………

そんな風に考えていた時期が私にもありました

あるシナリオ(1)

今、300GBのHDD(sda)と500GBのHDD(sdb)と2TBのHDD(sdc)がある。
300GBと2TBの間、500GBと2TBの間でミラーリングして連結すれば、ミラーリングされた800GBの領域が出来るはず。

expected structure

ZFSを使ってミラーリングされた800GBの領域を作りましょう。

あるシナリオ(2)

sdaとsdbは一つのパーティションにして、sdcには300GBと500GBのパーティションを作成すればいいよね。

# zpool create ztank mirror /dev/sda1 /dev/sdc1 mirror /dev/sdb1 /dev/sdc2

expected structure

本当にそれで良いのか？

あるシナリオ(3)

zpoolは複数のディスクをaddすると問答無用でストライピングするらしい。
つまりsdc1とsdc2でストライピングすることに……

actual structure

シーケンシャルアクセスもランダムアクセスになってるぞこれ

ZFSの他の問題点

さらに、ZFSは一旦追加したパーティションを縮小・削除できない(交換は出来るが)。
- なお、attachと間違えてaddするとpoolごと作り直し。

要するにZFSは基本的に台数を減らせない設計

-  ⇤ ← 2011-07-19 02:03:27時点のリビジョン2 → 
  サイズ: 1534
  編集者: ytoku
  コメント:
+   ← 2011-07-19 03:52:15時点のリビジョン4 → ⇥
  サイズ: 2559
  編集者: ytoku
  コメント:
-削除された箇所はこのように表示されます。
+追加された箇所はこのように表示されます。
 行 14:
+ * 複数のディスクにまたがるファイルシステムを作ったり出来るようにするもの
 * 構造としては、物理ボリューム(PV)を物理エクステント(PE)という単位に分割して、物理エクステントの組み合わせで論理ボリューム(LV)を構成するようになっている。
 * 物理ボリュームの追加・削除や論理ボリュームのサイズ変更は後から可能
 * ついでにストライピングやミラーリングも出来たりする
-行 15:
+行 20:
+ZFSでもファイルシステムのサイズは可変だし、プールにパーティションを追加できるじゃない。
-行 16:
+行 23:
+<<BR>><<BR>><<BR>>
-行 25:
+行 34:
-{{attachment:ZFS-expected.png|expected structure|align="middle"}}
+{{{#!wiki center
{{attachment:ZFS-expected.png|expected structure}}
}}}
-行 35:
+行 46:
+{{{#!wiki center
-行 36:
+行 48:
+}}}
-行 40:
+行 53:
- * zpoolは複数のディスクをaddすると問答無用でストライピングする。
+ * zpoolは複数のディスクをaddすると問答無用でストライピングするらしい。
-行 43:
+行 56:
+{{{#!wiki center
-行 44:
+行 58:
+}}}
-行 46:
+行 61:
+= ZFSの他の問題点 =
 * さらに、ZFSは一旦追加したパーティションを縮小・削除できない(交換は出来るが)。
  * なお、attachと間違えてaddするとpoolごと作り直し。

要するにZFSは基本的に台数を減らせない設計