差分

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

--- blog:2022:2022-02-24 [2022-02-24 18:40]
Decomo 作成
+++ blog:2022:2022-02-24 [2022-05-08 09:17]
Decomo
@@ 行 1: / 行 1: @@
-====== ZFSのスペシャルvdevを試してみる ======
+====== ZFSのSpecial vdevを試してみる ======
 階層化ストレージのZFS版ともいえるSpecial vdevとSpecial Allocation Classについて、[[blog:2020:2020-12-08|1年程前に当サイトでも解説]]した。いつか試そうと思いつつ延び延びになっていたが、いよいよ導入の機運が高まってきたので簡単にテストした。
@@ 行 32: / 行 32: @@
 # sudo zpool remove ztest da6p1
 </code>
+<WRAP alert>
+OpenZFS 2.1.4の時点において、RAIDZプールに追加したスペシャルvdevは削除できないので注意!!（トップレベルvdev削除の制限事項）。
+スペシャルvdevデバイスの増減（''zpool attach/detach''）は可能だが、いざ''zpool remove''しようとすると''invalid config; all top-level vdevs must have the same sector size and not be raidz.''エラーとなり削除できない。
+slogやL2ARCは削除できるのにどうして……
+</WRAP>
 ただし、remove後にスペシャルvdevからノーマルvdevへ、データの退避が行われる。
@@ 行 129: / 行 137: @@
 |  128k |     - |  284 |  17.8 |  539 |      - | Special vdevなし |
 | :::   |     0 |  281 |   2.5 |  493 |    319 | メタデータのみSpecial vdevを利用 |
+| :::   |    4k |    - |     - |    - |    320 | sdev容量のみ測定 |
+| :::   |    8k |    - |     - |    - |    321 | |
+| :::   |   16k |    - |     - |    - |    322 | |
+| :::   |   32k |    - |     - |    - |    336 | |
 | :::   |   64k |  279 |   2.6 |  433 |    684 | |
 | :::   |  128k |  280 |   2.8 |  203 |  13824 | 全データがSpecial vdevに行く |
 |    1M |     - |  280 |  17.6 |  400 |      - | Special vdevなし |
 | :::   |     0 |  285 |   2.5 |  358 |     34 | |
+| :::   |    4k |    - |     - |    - |     35 | sdev容量のみ測定 |
+| :::   |    8k |    - |     - |    - |     36 | |
+| :::   |   16k |    - |     - |    - |     37 | |
+| :::   |   32k |    - |     - |    - |     52 | |
 | :::   |   64k |  274 |   2.7 |  352 |    400 | |
 | :::   |  128k |  276 |   2.8 |  286 |   3102 | |
 {{ :blog:2022:zfs_special_vdev_comparison.png |}}
+※special_small_blocks=4k～32kは後から測定したため、スペシャルvdevの容量のみ。グラフには加えていない。1MBずつ増えてて本当かよ？と思ったが、再度試しても同じだったので間違ってるわけではなさそう。
 スペシャルvdevの有無でファイルコピー（書き込み。赤線）時間に有意な差は見られなかった。ただし、これはコピー元の読み込みで律速してる可能性が否定できない。コピー先の書き込み状況をiostatを眺めてみると間欠動作となっていた。
@@ 行 161: / 行 179: @@
 さらに1MiBレコードではファイル読込が明らかに速くなっており、[[blog:2022:2022-02-21|圧縮率の観点]]等も考慮すると積極的に128KiB以上のレコードサイズを使っていくのが良さそう。
-''special_small_blocks''の設定をどうするかは悩ましいところ。扱うデータの種類やワークフローはもとより、TXG関連の設定やその時々の負荷量などで、書き込みがスペシャルvdev行きとなるかどうかが変わってくると思われ、見積もるのが難しい。今回は64k/128kの2パターンしか見なかったが、運用においては、より小さな設定値も検討に値するだろう。むしろ、とりあえず4kあたりから始めて様子を見るのがいいのかもしれない。
+''special_small_blocks''の設定をどうするかは悩ましいところ。扱うデータの種類やワークフローはもとより、TXG関連の設定やその時々の負荷量などで、書き込みがスペシャルvdev行きとなるかどうかが変わってくると思われ、見積もるのが難しい。<del>今回は64k/128kの2パターンしか見なかったが、運用においては、より小さな設定値も検討に値するだろう。むしろ、とりあえず4kあたりから始めて様子を見るのがいいのかもしれない。</del> → 気になったので4k～32kを追試したけど、32k以下は殆ど効果がなさそう。スペシャルvdevの運用としては、容量が見積もりやすいメタデータのみとするか、ある程度余裕を持たせて64kで始めるの2択になるかも。
 メタデータだけでもスペシャルvdevの効果は期待できそうなので、SSDに余裕があるならL2ARCよりも優先的に割り当てて良さそうに思う。