blog:2021:2021-08-06

差分

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

この比較画面にリンクする

次のリビジョン 両方とも次のリビジョン
blog:2021:2021-08-06 [2021-08-06 15:21]
Decomo 作成 		blog:2021:2021-08-06 [2021-08-06 17:50]
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が作られた模様。 今まで気づかなかったが、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あたりと見込まれている。まぁ、かなり大きい変更なのでレビューもテストも時間がかかるだろうしね、仕方ないね。 コードレビューは始まったばかり、というかまだ進んでない？ようでリリースはまだまだ先っぽい。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的にはそんなカツカツ運用するなよって感じ？+使っていく中で既存データも新しいストライプ幅に置き換わり、このオーバーヘッドは徐々に解消されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい！という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか？そもそもZFS的にはそんなカツカツ運用するなよって感じ？
  
-拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の容易性とRAIDZ1/2/3の冗長性担保のためらしい。+拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の簡便さとRAIDZ1/2/3の冗長性担保が理由とのこと。
  
 このまま無事マージされて欲しいところ。 このまま無事マージされて欲しいところ。
行 23: 行 23:
   * [[https://wiki.freebsd.org/DevSummit/202106|DevSummit/202106 - FreeBSD Wiki]]   * [[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]]   * [[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/|
  • blog/2021/2021-08-06.txt
  • 最終更新: 2021-08-10 10:59
  • by Decomo