LinuxでGPTを作ると、First usable LBAとして512バイトセクタドライブで2048、4kセクタドライブで256が設定されることに気づいた。これだと、パーティショニングツールからはGPTとして1MiBが確保されたかのように見える。
GPTの実際のサイズは16.5KiBであるから、本来は33セクタ@512Bまたは5セクタ@4KiBで事足りる。FreeBSDの39セクタ@512Bに慣れた身からすると、無駄とも思えるサイズだ。
理由を調べてみると、どうもWindowsとの互換性のためっぽい。
WindowsではVistaとWindows Server 2008から、パーティションの先頭を1MiBアライメントで揃えるようになったそうだ。Linuxはこれに追従したとのこと。1MiBアライメントなら、512バイトと4kBの両方の倍数なので所謂AFTアライメント問題が解消でき、将来、より大きなセクタサイズが登場した時に対応できる可能性も高まる。
言われてみれば納得の理由だ。逆にFreeBSDが20KiBしか確保しないことが不安になってくる…。パーティション追加時にgpart create -a 1Mで1MiB境界に揃えてやればいいんだけではあるが、これだとパーティション一覧に“未使用領域”として計上されてしまうのが、ちょっとカッコ悪い。
どうでもいいけど調査の過程で、今更ながらCHSやらセクター63やらシリンダ境界規定やらを調べてしまった。
（2021-01-16 追記）
Linuxのfdiskで切ったパーティションをFreeBSDで見てみた。
> gpart show
=> 6 234423115 nvd0 GPT (894G)
6 131072 1 efi (512M)
131078 26214400 2 freebsd-zfs (100G)
26345478 208077643 - free - (794G)
=> 256 468843345 nvd1 GPT (1.7T)
256 131072 1 efi (512M)
131328 26214400 2 freebsd-zfs (100G)
26345728 375914496 3 !6a898cc3-1dd2-11b2-99a6-080020736631 (1.4T)
402260224 13107200 4 !6a898cc3-1dd2-11b2-99a6-080020736631 (50G)
415367424 53476177 - free - (204G)
nvd0がFreeBSDのgpart、nvd1がLinuxのfdiskで作成したもので、どちらも4kセクタである。
FreeBSDのgpartもFirst usable LBAをちゃんと見ているようで、nvd1のESPの開始セクタ256セクタ＝1MiB地点を正しく認識している。
将来のことを考えると、GPTを作るところまではLinuxまたはWindowsでやった方がいいかもしれないなぁ。
SSDをSpecial VDEVとしてZFSプールに追加すれば性能向上が見込めそうなのは分かった。続いてSpecial VDEVに必要な容量を見積もってみる。
Special VDEVに格納されるデータは大きく2つに分けられる。
zdbコマンドでプールのこれらの現在量を確認し、Special VDEVの容量を見積もることができそうだ。
実際に、稼働中の家鯖のプールで実際に確認してみよう。対象プールの下表のとおり。
| 用途 | システム用プール (zroot) |
|---|---|
| 種類 | ミラー |
| 使用量/容量 | 37.2/99.8GiB |
| 特記事項 |
|
なお、zdb実行時はメモリの空きに注意すること。プールの使用量がテラバイト級だと数ギガ単位で消費する。メモリ不足でzdbが落ちるようなら、Special VDEVより先にメモリを追加しましょう。何はなくともZFSはメモリが重要なので。
メタデータの使用量は簡単に確認できる。
Allocation Classにおける「メタデータ」とは、ファイルデータとzvolデータを除いたデータである。正確に言うと、レベル0のZFS plain file（いわゆる普通のファイルのデータ）とレベル0のzvol object（zvolのデータブロック）を除いた全てのデータがSpecial VDEVに載るとのこと。
zdb -bbb プール名を実行するとプールの詳細情報がズラズラ出るが、このうちTypeがTotalのASIZEからL0 ZFS plain fileとL0 zvol objectのASIZEを引いた値がメタデータサイズとなる。
$ zdb -bbb zroot
Traversing all blocks to verify nothing leaked ...
loading concrete vdev 0, metaslab 398 of 399 ...
36.3G completed (1522MB/s) estimated time remaining: 0hr 00min 00sec
No leaks (block sum matches space maps exactly)
bp count: 1693872
（省略）
Dittoed blocks on same vdev: 147925
Blocks LSIZE PSIZE ASIZE avg comp %Total Type
- - - - - - - unallocated
2 32K 8K 24K 12K 4.00 0.00 object directory
（省略）
- - - - - - - ZFS V0 ACL
85 3.62M 222K 688K 8.09K 16.76 0.00 L2 ZFS plain file
25.2K 2.85G 103M 214M 8.50K 28.36 0.56 L1 ZFS plain file
1.43M 47.3G 33.9G 35.9G 25.0K 1.40 96.63 L0 ZFS plain file ★これ
1.46M 50.1G 34.0G 36.1G 24.7K 1.48 97.19 ZFS plain file
4 64K 16K 32K 8K 4.00 0.00 L2 ZFS directory
1.02K 118M 4.26M 8.61M 8.47K 27.60 0.02 L1 ZFS directory
86.2K 237M 120M 456M 5.29K 1.97 1.20 L0 ZFS directory
87.2K 355M 125M 464M 5.32K 2.84 1.22 ZFS directory
- - - - - - - zvol object ★これ
（省略）
1.62M 51.6G 34.4G 37.2G 23.0K 1.50 100.00 Total ★これ
この例だと、37.2G - 35.9G - 0 = 1.3G がメタデータサイズとなる（zvolは使っていないのでL0 zvol objectは出てこない）。
必要となる小ブロック用の領域は、データセット毎に指定するspecial_small_blocksプロパティの値で変わってくる。
このプロパティはSpecial Allocation Classとして扱うブロックサイズ、すなわちSpecial VDEVへの読み書きとなる閾値で、512～128kの2の累乗値で指定する。この値以下の読み書きがSpecial VDEV行きとなるので、recordsizeと同じ値にするのは危険。基本的には64k以下を指定することになるだろう。
zdb -bbbb プール名を実行すると、データの種類ごとにレコードサイズの使用状況が表示される。
ここでも注目すべきはL0 ZFS plain fileとL0 zvol objectの分布である。非常に長いログのため、L0 ZFS plain fileの一部のみ掲載。
1.43M 47.3G 33.9G 35.9G 25.0K 1.40 96.63 L0 ZFS plain file
psize (in 512-byte sectors): number of blocks
0: 36843 *******
1: 213506 ****************************************
2: 139110 ***************************
3: 137030 **************************
4: 98715 *******************
5: 70100 **************
6: 56304 ***********
7: 43444 *********
8: 158789 ******************************
9: 13123 ***
（省略）
255: 36 *
256: 179774 **********************************
0:, 1:, …, 256: はブロックサイズを、その後ろはブロック数を表す。1ブロック512バイトなので、上記の8:の行は4096バイトブロックが158789個で約620MiBと読める。
各レコードサイズ以下のデータ量は下表の通りだった。
| レコードサイズ | データ量 |
|---|---|
| 4KiB以下 | 1.69GiB |
| 8KiB以下 | 2.53GiB |
| 16KiB以下 | 3.40GiB |
| 32KiB以下 | 4.60GiB |
| 64KiB以下 | 7.9GiB |
ここではSpecial VDEVをフル活用するとして、全部盛りの7.9GiBを採用する。
以上より、メタデータ量1.3GiBと小ブロックデータ量7.9GiBの合算、9.2GiBが現時点のSpecial Allocation Classのサイズとなる。
プールの使用量とメタデータ量/小ブロック量の関係は読み切れない部分があるけど、今後も同じ割合でSpecial Allocation Classが増えるとすれば、Special VDEVに必要なサイズは25GiB程度となる。
プールサイズの25%というと結構な割合となるが、細々とした大量のファイルの影響が考えられる。実際、このプールでは4KiB以下のファイルが全ファイル数の8割を占めており、中でも特に1KiB以下が5割を占めている。
Special VDEVの必要量は、プールの使われ方にも大きく依存すると考えられる。
そこで、手元の6つのプールについてSpecial VDEVの容量に影響しそうな項目を調査した。
| プール名 | 種類 | 使用量/容量 | ファイル数 | 平均ファイルサイズ | メタデータ | 64kB以下のレコード総量 | 使われ方 |
|---|---|---|---|---|---|---|---|
| システムプール | ミラー | 37.2/99.8GiB | 1286414 | 0.029MiB | 1.3GiB (3.5%) | 7.9GiB (21.2%) | FreeBSDのシステム格納用。 見積作業で使ったプール。小粒で大量のファイル成分強い。 |
| データプール1 | ミラー | 2.54/7.12TiB | 1003104 | 2.654MiB | 20GiB (0.8%) | 31.7GiB (1.2%) | ホームディレクトリ用のプール。 日常生活での書類データ、数MB～数十MBの音楽ファイル、数十MBオーダーの写真などが主。 |
| データプール2 | RAIDZ1 | 20.2/20.4TiB | 229356 | 92.351MiB | 700MiB (0.003%) | 6.74GiB (0.03%) | データプール1より重要度が下のデータ群。 数GB級の動画ファイル、数百KBクラスの画像、アプリのアーカイブ（ISO, zipなど様々）など。 |
| データプール3 | 単体 | 6.49/7.1TiB | 1099395 | 6.190MiB | 10GiB (0.2%) | 64.5GiB (1.0%) | データプール2より重要度が下のデータ群。 バックアップデータ、Time Machineのスパースバンドル、～2GB程度の動画、数百KBクラスの画像など。 |
| 業務用プール1 | RAIDZ1 | 5.09/8.93TiB | 2674793 | 1.995MiB | 30GiB (0.6%) | 120.2GiB (2.3%) | 業務で使われているプール、その1。 主に間接部門の書類、資料性の高いデータ、流動性の低いデータなど。 |
| 業務用プール2 | ミラー | 0.954/1.99TiB | 183582 | 5.451MiB | 2GiB (0.2%) | 1.04GiB (0.1%) | 業務で使われているプール、その2。 数十KB～数百KBの多数の画像、数MBのアセットなど。 |
ファイル数が多いほど、またファイルサイズが小さいほど、メタデータと小ブロックの量は増える傾向にあるものの、一概にプール容量の何パーセントと言える感じではなさそうだ。
システムプールが少々特殊な気がするので除外すると、多くの場合、Special VDEVのサイズはプールサイズの5%あれば十分と言えなくもない？が、断定するにはサンプルが不足してるかな…。少々時間はかかるけど、今のところ都度zdbで計算する方がよさげ。潤沢な資金があるならともかく、20TiBの5%は1TiBになるので、丸ごとSpecial VDEVにおごるのは勿体ない気も…。
ファイルサイズの分布。
用途ごとにプールを分けてることもあって、ファイルサイズはプールごとにそれなりにバラつきが見られる（目論見通り）。
続いてレコードサイズの分布。
ZFSのトランザクショングループ（txg）のおかげか殆どが128KiBレコードとなっており、グラフにする意味もなかった。txgって予想以上に効くんだね…。これでは何も読み取れないので、各プールの使用率上位3位のレコードサイズを表にまとめた。
| プール名 | 1位 | 2位 | 3位 |
|---|---|---|---|
| システムプール | 512 (14.2%) | 128k (11.95%) | 4k (10.54%) |
| データプール1 | 128k (88.1%) | 4k (0.98%) | 512 (0.89%) |
| データプール2 | 128k (99.6%) | 512 (0.11%) | 4k (0.02%) |
| データプール3 | 128k (90.7%) | 4k (0.98%) | 8k (0.54%) |
| 業務用プール1 | 128k (63.6%) | 1 (8.34%) | 112k (2.10%) |
| 業務用プール2 | 128k (97.7%) | 512 (1.75%) | 11k (0.02%) |
ZFSの書き込みは、ほぼほぼ128k/4k/512バイトに集約されると言っても過言ではなさそう。
OpenZFS 2.0リリースの陰でひっそりと、FreeBSD 12.2-RELEASEのZFS実装にSpecial Allocation Class（以下、SACと略すことがある）が追加されていた。
時系列的にはOpenZFS 2.0が2020年12月1日、FreeBSD 12.2Rが10月27日リリースなので、まったく陰ってはないんですけどね、インパクトありそうな機能の割にはリリースノートに記載がなく、zpool statusしたら「プールのアップグレードができるぜ！」と出たので調べてみたら追加されていたという。関連するコミットはこの辺→Rev.354382 Rev.354385 Rev.354941
Special Allocation Class自体はZoL 0.8.0で2019年5月24日にリリースされ、その後、illumosへのバックポートを経て、めでたくFreeBSDに取り込まれた模様。ZFS実装が新生OpenZFSベースに切り替わろうとしている中で、Legacy ZFSをきっちりメンテする姿勢には頭が下がります。
で、肝心のSpecial Allocation Classは何かというと、I/O性能に直結するデータを専用のvdevに格納して性能改善を図るもののようだ。多少正確さを欠く表現だが、階層化ストレージのZFS版といえる。
ZFSでは扱うデータの種類に応じてvdevをAllocation Classという概念で分類しており、OpenZFS 2.0時点では以下の5種類となっている。ちなみにAllocation Classは、元はdRAIDで導入されたもので、その後、開発コミュニティによって汎用化され現在の形となったそうだ。
| クラス | SAC | 用途 | 専用vdevを割り当てた時の効果 |
|---|---|---|---|
| Normal | × | 通常のデータを扱うvdev。ミラーとかRAIDZとか。 | |
| Log | × | ZILのレコード。いわゆるSLOG。 | 同期書き込みの高速化 |
| Dedup | ○ | 重複排除テーブル(DDT)のデータ | 重複排除パフォーマンスの向上とDDTのメモリ使用量の削減 |
| Metadata | ○ | プールとファイルシステムのメタデータ | メタデータ操作（ファイル一覧の取得など）パフォーマンスの向上 |
| Small Blocks | ○ | レコードサイズ以下のブロック | 小さなサイズの膨大なI/O性能の改善。詳細は後述 |
表で〇を付けたAllocation ClassがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは劇的な性能改善の可能性(PDF)を秘めている。
ZFSのファイルI/Oは原則的に128KiB単位1)で行われ、それに満たないデータは、より小さなレコードが使われる。この小さなレコードがI/O性能にそれなりに影響するようで、Small Blocksは指定サイズ以下のブロックの読み書きをSpecial vdevにオフロードするようなイメージとなる。つまり、Special vdevとしてSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになる、というわけだ。
ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、あくまでブロックサイズベースで行われるということ。なので、小さなファイルの全体がSpecial vdevに格納される訳ではない2)。そもそも、ZFSの書き込みは一旦メモリにキャッシュされ、トランザクショングループ（txg）にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル＝小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、これらのtxgでレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。
Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせて使うと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。
Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。
Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうなので、その辺は特に気にしなくてもよい模様。
もし試す場合は、プール（普通のvdev）とSpecial vdevのashift量を一致させること。もう修正済みかもしれないが、異なるashiftでプールに追加するとSpecial vdevの取り外せなくなるバグがあるっぽい。ashift量はvdevごとに独立してて、プール作成時は気にするもののvdev追加時はついつい忘れちゃうんだよね…。
MicronのU.2接続なSSD、9200 MAX 1.6TB (MTFDHAL1T6TCU)を買ったので恒例のベンチマーク。
公称スペックは以下のとおり。
もちろん中古購入でS.M.A.R.T.はこんな感じ。
使用時間10047時間≒418日で、電源投入回数45回ってことは間違いなくどこかのサーバに積まれてたものだろうけど、その割に投入回数が多いような気がしなくもない。単純計算で10日に1回でしょ？読み書き量が少なめなのも謎。
| 1GB | |
|---|---|
| MB/s |  |
| IOPS |  |
| レイテンシ |  |
------------------------------------------------------------------------------
CrystalDiskMark 8.0.0 x64 (C) 2007-2020 hiyohiyo
Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
[Read]
SEQ 1MiB (Q= 8, T= 1): 2638.535 MB/s [ 2516.3 IOPS] < 3175.35 us>
SEQ 1MiB (Q= 1, T= 1): 1357.518 MB/s [ 1294.6 IOPS] < 771.60 us>
RND 4KiB (Q= 32, T= 1): 339.511 MB/s [ 82888.4 IOPS] < 373.57 us>
RND 4KiB (Q= 1, T= 1): 25.252 MB/s [ 6165.0 IOPS] < 161.80 us>
[Write]
SEQ 1MiB (Q= 8, T= 1): 2011.884 MB/s [ 1918.7 IOPS] < 4159.85 us>
SEQ 1MiB (Q= 1, T= 1): 1875.930 MB/s [ 1789.0 IOPS] < 558.13 us>
RND 4KiB (Q= 32, T= 1): 293.463 MB/s [ 71646.2 IOPS] < 432.32 us>
RND 4KiB (Q= 1, T= 1): 132.838 MB/s [ 32431.2 IOPS] < 30.53 us>
Profile: Default
Test: 1 GiB (x5) [H: 0% (0/1490GiB)]
Mode: [Admin]
Time: Measure 5 sec / Interval 5 sec
Date: 2020/11/27 20:47:10
OS: Windows 10 Professional [10.0 Build 19041] (x64)
Comment: Micron 9200 MAX 1.6TB
|
| 1GB | 32GB | |
|---|---|---|
| MB/s |  |  |
| IOPS |  |  |
| レイテンシ |  |  |
------------------------------------------------------------------------------
CrystalDiskMark 8.0.0 x64 (C) 2007-2020 hiyohiyo
Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
[Read]
SEQ 1MiB (Q= 8, T= 1): 2672.030 MB/s [ 2548.2 IOPS] < 3131.79 us>
SEQ 128KiB (Q= 32, T= 1): 2520.132 MB/s [ 19227.1 IOPS] < 1661.55 us>
RND 4KiB (Q= 32, T=16): 1474.630 MB/s [ 360017.1 IOPS] < 1416.91 us>
RND 4KiB (Q= 1, T= 1): 23.020 MB/s [ 5620.1 IOPS] < 177.46 us>
[Write]
SEQ 1MiB (Q= 8, T= 1): 2009.463 MB/s [ 1916.4 IOPS] < 4157.97 us>
SEQ 128KiB (Q= 32, T= 1): 1999.890 MB/s [ 15257.9 IOPS] < 2093.33 us>
RND 4KiB (Q= 32, T=16): 1074.929 MB/s [ 262433.8 IOPS] < 1890.13 us>
RND 4KiB (Q= 1, T= 1): 125.642 MB/s [ 30674.3 IOPS] < 32.28 us>
Profile: Default
Test: 1 GiB (x5) [H: 0% (0/1490GiB)]
Mode: [Admin]
Time: Measure 5 sec / Interval 5 sec
Date: 2020/11/27 20:53:28
OS: Windows 10 Professional [10.0 Build 19041] (x64)
Comment: Micron 9200 MAX 1.6TB (NVMe SSD)
| ------------------------------------------------------------------------------
CrystalDiskMark 8.0.0 x64 (C) 2007-2020 hiyohiyo
Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
[Read]
SEQ 1MiB (Q= 8, T= 1): 3559.011 MB/s [ 3394.1 IOPS] < 2354.13 us>
SEQ 128KiB (Q= 32, T= 1): 3562.092 MB/s [ 27176.6 IOPS] < 1174.93 us>
RND 4KiB (Q= 32, T=16): 1965.045 MB/s [ 479747.3 IOPS] < 1032.14 us>
RND 4KiB (Q= 1, T= 1): 35.869 MB/s [ 8757.1 IOPS] < 113.71 us>
[Write]
SEQ 1MiB (Q= 8, T= 1): 1989.156 MB/s [ 1897.0 IOPS] < 4205.01 us>
SEQ 128KiB (Q= 32, T= 1): 2013.703 MB/s [ 15363.3 IOPS] < 2078.83 us>
RND 4KiB (Q= 32, T=16): 1462.729 MB/s [ 357111.6 IOPS] < 1387.32 us>
RND 4KiB (Q= 1, T= 1): 130.202 MB/s [ 31787.6 IOPS] < 31.17 us>
Profile: Default
Test: 32 GiB (x5) [H: 0% (0/1490GiB)]
Mode: [Admin]
Time: Measure 5 sec / Interval 5 sec
Date: 2020/11/27 21:05:36
OS: Windows 10 Professional [10.0 Build 19041] (x64)
Comment: Micron 9200 MAX 1.6TB (NVMe SSD)
|
| 1GB | 10GB | |
|---|---|---|
| MB/s | |  |
| IOPS |  |  |
ベンチしてて気になったのは、S.M.A.R.T.が報告する温度が高めということ。
最初、バラック状態でやってたら70℃近くまで上がったため、急遽ファンで直接風をあてた。本当に70℃まで上がってたら熱くて触れないハズだが、実際は多少熱いくらいの温度感だった。15mm厚のSSDかつゴツい金属製筐体なので放熱性は良さそうなんですがね…。
ドライブ内部の一番ホットな部分の温度を示してるのか、センサー故障で高めの値なのか真相は不明。
それと、PCIeのリンク状態が割とシビアな気がする。2台のマシンで、PCIeスロットにマウントするタイプの変換カード、PCIe→SFF-8643→SFF-8639ケーブルのそれぞれで接続したが、どちらとも最初はPCIe 2.0でのリンクアップとなってしまった。コネクタ抜き差しでPCIe 3.0で繋がったものの、少々気がかりではある。
OpenZFS 2.1で分散ホットスペアを実現する新たなプール構成「dRAID」がリリースされる見込みだそうだ。dRAIDによってホットスペアが抽象化され、障害発生時のプールのリビルドが高速化されるとのこと。実装の解説を見ると、Declustered RAIDそのものな気がするが、OpenZFSでは慎ましく“Parity Declustered RAIDZ”と言っているようだ。
現在のZFSでは、ホットスペアはプールの予備デバイスという扱いとなっている。伝統的なRAIDシステムと同じ考え方で、ホットスペアは障害が起きたvdevの物理デバイスを置き換え、vdev内でresilver（データの復元とパリティの再計算）が行われる。抽象化が進んでいるZFSシステムの中では珍しく、割と物理デバイスを意識させる実装となっている。
dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスがかかわり分散的にデータ/パリティとスペアブロックを読み書きするため、リビルド時間が短縮されるという構図のようだ。ちなみに、dRAIDのrebuildはチェックサムとパリティの検証を行わないため、resilverとは明確に違うらしい。
言葉だけだとイメージが付きにくいが、図を見れば簡単に理解できるかと。
「Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance」(Zhi (George) Qiao, Song Fu, Hsing-bung Chen, Bradley Wade Settlemyer) より編集して抜粋
HCIのストレージの挙動に近いかも？
RAID-Z同様、dRAIDのvdev構成を後から変えることは現時点では出来ないとされている。ただし、dRAIDのデータ構造からするに、いわゆるdRAID Expansionはそう難しくない気がするが果たして…？。コードソンで会おう！
