差分

このページの2つのバージョン間の差分を表示します。

--- blog:2021:2021-08-06 [2021-08-06 15:21]
Decomo 作成
+++ blog:2021:2021-08-06 [2021-08-10 10:59] (現在)
Decomo
@@ 行 1: / 行 1: @@
-====== OpenZFSにRAIDZ Expansionのプルリクが立てられた！ ======
+====== OpenZFSにRAIDZ Expansionのプルリクができてた ======
 今まで気づかなかったが、2か月ほど前の6/11に、待望の[[https://github.com/openzfs/zfs/pull/12225|RAIDZ Expansionのプルリク]]がOpenZFSに立てられていた！！[[blog:2019:2019-05-14|2018年のプリアルファコード]]以来目立った動きがなく、どうなっとんじゃーいって感じだったが、[[https://wiki.freebsd.org/DevSummit/202106|June 2021 FreeBSD Developer Summit]]での報告の翌日、PRが作られた模様。
@@ 行 5: / 行 5: @@
 コードレビューは始まったばかり、というかまだ進んでない？ようでリリースはまだまだ先っぽい。OpenZFSプロジェクトの状況としては、現在は2.1リリース作業の真っただ中で、取り込まれるのはどんなに早くとも来年リリースのOpenZFS 2.2あたりと見込まれている。まぁ、かなり大きい変更なのでレビューもテストも時間がかかるだろうしね、仕方ないね。
-PRの議論を見るに、拡張時の動作である「既存データのストライプサイズは変更しない＝データ/パリティ比率は変わらない」という点が、結構引っかかってるっぽい雰囲気。
+PRの議論を見るに、拡張時の挙動である「既存データのストライプサイズは変更しない＝データ/パリティ比率は変わらない」という点が、結構引っかかってるっぽい雰囲気。
-RAIDZ ExpansionでRAIDZにストレージを追加した場合、RAIDの物理ストライプ幅は拡張後のサイズとなる。対する論理ストライプ幅については、既存のデータは拡張前のサイズ、再書き込みを含む新規データは拡張後のサイズとなる。具体的な数値を当てはめると、HDD 5本のRAIDZ2プールをHDD 6本に拡張した場合、既存データは論理5ストライプ（データ/パリティ比=3:2）のままで、新規データは論理6ストライプ（データ/パリティ比=4:2）が割り当てられる。データによってストライプ幅が異なること自体は、RAIDZの元からの仕様なので問題ないらしい。
+RAIDZ ExpansionでRAIDZ vdevにストレージを追加した場合、vdevの物理ストライプ幅は拡張後のサイズとなる。対する論理ストライプ幅については、既存のデータは拡張前の幅、再書き込みを含む新規データは拡張後の幅となる。具体的な数値を当てはめると、HDD 5本のRAIDZ2プールをHDD 6本に拡張した場合、既存データは論理5ストライプ（データ/パリティ比=3:2）のままで、新規データは論理6ストライプ（データ/パリティ比=4:2）で記録される。データによってストライプ幅が異なること自体は、RAIDZの元からの仕様なので問題ないらしい。
-一方で、この仕様のため既存RAIDZプールの使用率が高ければ高いほど、RAIDZ Expansionでプールを拡張しても見かけの空き容量は増えにくくなる。例えば、1TB×4のRAIDZ1プールに1TB書き込むとプール使用率は33%なのに対し、1TB×3のRAIDZ1プールに1TB書き込んだあと（この時点での使用率は66%）で1TBのHDDを追加しても使用率は66%のままとなる。既存データのデータ/パリティ比が変わらない以上、この容量オーバーヘッドは避けられない。
+一方で、この仕様のため既存RAIDZプールの使用率が高いほど、RAIDZ Expansionでのプール拡張後の実効空き容量は増えにくくなる。例えば、1TB×4のRAIDZ1プールに1TB書き込むとプール使用率は33%なのに対し、1TB×3のRAIDZ1プールに1TB書き込んだあと（この時点での使用率は66%）で1TBのHDDを追加しても使用率は66%のままとなる。既存データのデータ/パリティ比が変わらない以上、この容量オーバーヘッドは避けられない。
-使ってくうちに既存データも新しいストライプ幅に置き換わっていくので、徐々に効率は改善されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい！という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか？そもそもZFS的にはそんなカツカツ運用するなよって感じ？
+RAIDZ ExpansionでRAIDZプールは何度でも拡張可能だが、こんな感じゆえに、最小構成で始めて必要に応じて後からディスクを追加する、という戦略は取りにくいのは否めない。
-拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の容易性とRAIDZ1/2/3の冗長性担保のためらしい。
+使っていく中で既存データも新しいストライプ幅に置き換わり、このオーバーヘッドは徐々に解消されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい！という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか？そもそもZFS的にはそんなカツカツ運用するなよって感じ？
-このまま無事マージされて欲しいところ。
+拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の簡便さと拡張中のRAIDZ1/2/3の冗長性担保が理由とのこと。
+このまま無事マージされて欲しい。
 ===== 参考サイト =====
@@ 行 23: / 行 25: @@
   * [[https://wiki.freebsd.org/DevSummit/202106|DevSummit/202106 - FreeBSD Wiki]]
   * [[https://louwrentius.com/zfs-raidz-expansion-is-awesome-but-has-a-small-caveat.html|ZFS RAIDZ expansion is awesome but has a small caveat]]
+  * [[http://storagegaga.com/raidz-expansion-and-draid-excellent-openzfs-adventure/|RAIDZ expansion and dRAID excellent OpenZFS adventure - Storage Gaga]]