RAIDZ ExpansionのPR作成の報を打ってから早2年、今度こそRAID-Z Expansionが来そうな雰囲気？である。

当時のPRは閉じられており、6月末にどういう訳か新しいPRに移行して作業が行われている。見てないけどOpenZFSリーダー会議で移行議論の概要が見られるようだ。

今回は着々とレビューとコミットが積み上げられている。RAIDZ Expansion自体は問題なく動いているようで、既に自前ビルドで使っている勇者もいるっぽい。今度こそマージされてほしい。

Proxmox VEの仮想ディスクは、仮想マシンから512バイトセクタのストレージとして見える。正確にはQEMUのデフォルト挙動で、仮想環境における極々一般的な挙動なので普通に使う分には困らないし、意識すらしないだろう。

じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合や、4Kn環境をそのままP2Vした時のディスクイメージとかで困る。例えばパーティションテーブルなんかはLBA（セクタ番号）で管理されているので「パーティション1はセクタ1～262144」という設定は、4kセクタ環境なら1GiB、512バイトセクタ環境なら128MiBのパーティションを表すことになり、だいぶマズいわけですよ。（そもそも、GPTの配置自体が“LBA 1”と規定されているのでセクタサイズが合ってないとパーティションテーブル自体が正しく認識されない。）

というわけで、仮想ディスクを4Knとして認識させるには、/etc/pve/qemu-server/VMID.confをエディタで直接編集し、args:に下記の設定を追加してやればよい。

args: -set device.scsi0.physical_block_size=4096 -set device.scsi0.logical_block_size=4096

scsi0の0の部分はSCSI IDなので任意に読み替え可能で、複数のデバイスも同様に設定が可能。SATAやvirtio-blkも行けると思うけど未確認。

説明するまでもないだろうが、物理と論理のセクタサイズをそれぞれ4096に指定してあげればよい。物理4096, 論理512にすれば512e扱いになるかも？

上記設定を行った4KnのSSD×3、512eのHDD×5をRDMしてる当方の仮想環境では、想定通りに認識されている。

$ dmesg | grep sectors
da0: 2969600MB (760217600 4096 byte sectors)
da1: 2969600MB (760217600 4096 byte sectors)
da2: 2969600MB (760217600 4096 byte sectors)
da3: 17166336MB (35156656128 512 byte sectors)
da4: 17166336MB (35156656128 512 byte sectors)
da5: 17166336MB (35156656128 512 byte sectors)
da6: 17166336MB (35156656128 512 byte sectors)
da7: 17166336MB (35156656128 512 byte sectors)
cd0: 998MB (511254 2048 byte sectors)

また一つ、どーでもよいノウハウがたまってしまった。

• Change of sectorsize | Proxmox Support Forum

東芝とSeagateの14TB SATA HDD、MN08ACA14TとExos X16 ST14000NM001G-2KJ103のベンチマーク。実家に設置しているサーバの6TB×4のRAID-Z2ストレージを置き換えようと購入し、1年近く死蔵しているという。なお、先日ようやく実家に持っていきはしたものの、未だ交換には至らず…

例によってUSB 3.0変換での計測なので参考程度に。

	MN08ACA14T	ST14000NM001G
CrystalDiskInfo
CrystalDiskMark
	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 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): 271.152 MB/s [ 258.6 IOPS] < 27833.35 us> SEQ 1MiB (Q= 1, T= 1): 270.276 MB/s [ 257.8 IOPS] < 3873.33 us> RND 4KiB (Q= 32, T= 1): 1.785 MB/s [ 435.8 IOPS] < 72642.48 us> RND 4KiB (Q= 1, T= 1): 0.658 MB/s [ 160.6 IOPS] < 6194.17 us> [Write] SEQ 1MiB (Q= 8, T= 1): 255.845 MB/s [ 244.0 IOPS] < 32572.05 us> SEQ 1MiB (Q= 1, T= 1): 83.587 MB/s [ 79.7 IOPS] < 12506.20 us> RND 4KiB (Q= 32, T= 1): 1.137 MB/s [ 277.6 IOPS] <112710.49 us> RND 4KiB (Q= 1, T= 1): 0.619 MB/s [ 151.1 IOPS] < 6603.23 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 12:07:56 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: TOSHIBA MN08ACA14T (14TB/USB 3.0)	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 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): 281.158 MB/s [ 268.1 IOPS] < 29734.37 us> SEQ 1MiB (Q= 1, T= 1): 279.057 MB/s [ 266.1 IOPS] < 3753.59 us> RND 4KiB (Q= 32, T= 1): 2.137 MB/s [ 521.7 IOPS] < 60793.95 us> RND 4KiB (Q= 1, T= 1): 0.721 MB/s [ 176.0 IOPS] < 5668.58 us> [Write] SEQ 1MiB (Q= 8, T= 1): 270.648 MB/s [ 258.1 IOPS] < 30823.96 us> SEQ 1MiB (Q= 1, T= 1): 274.467 MB/s [ 261.8 IOPS] < 3816.19 us> RND 4KiB (Q= 32, T= 1): 13.794 MB/s [ 3367.7 IOPS] < 9487.38 us> RND 4KiB (Q= 1, T= 1): 8.230 MB/s [ 2009.3 IOPS] < 496.55 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 20:48:46 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: SEAGATE ST14000NM001G (14TB/USB 3.0)
ゼロフィル(512kBブロック)	14000504438784 bytes (14 TB, 13 TiB) copied, 70020 s, 200 MB/s	14000490807296 bytes (14 TB, 13 TiB) copied, 71015 s, 197 MB/s

MN08ACA14Tが電源投入2回、使用時間28時間にもかかわらず、代替セクタが計上されてるのが非常に嫌な感じなんですけど…。ネット上でも代替セクタでまくりとか、振動に弱いとかの報告が目につくので、然もありなんではある。が、NAS向けを謳ってるHDDで大丈夫なのこれ。

似たようなスペックの両HDDだけれども、全体的にST14000NM001Gの方が速いと言ってよさそう。この辺は流石のExosブランドってとこっすかね。Seagate絶対許さんマンのワタクシではありますが、Exosブランドに関してはだいぶ信頼している。いやまぁ、コンシューマ向けのラインを24/365で使って壊れて文句言ってる自分が悪いっちゃ悪いんですけども。

CDMのドライブ容量が50GBなのはクイックじゃないフォーマットで、ドライブ作ったためであり他意はない。

OpenZFS 2.1.4時点で、冗長性レベルを問わずRAID-Zプールに追加したスペシャルvdevを削除することは出来ないようだ。恐らく、トップレベルvdev削除の制限に起因する仕様と思われる。

次のようなRAID-Z1とスペシャルvdevから成るプールがあるとする。

# zpool status ztank
  pool: ztank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        zdata       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
        special
          mirror-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0

errors: No known data errors

ここで、スペシャルvdevを削除しようとzpool removeすると、次のようにエラーとなる。

# zpool remove ztank mirror-1
cannot remove mirror-1: invalid config; all top-level vdevs must have the same sector size and not be raidz.

トップレベルvdevのmirror-1を一気に削除するのがマズいのかと思い、次のように構成メンバを個別に削除してってもダメ。

# zpool detach ztank da5
# zpool remove ztank da4
cannot remove .....

なお、RAIDZ以外の構成なら特に制限なく削除可能で、同じトップレベルvdevであるslogやL2ARCの場合は、RAIDZでも（以前から）削除可能である。

家鯖でスペシャルvdevを本格運用すべく色々準備してたけど、削除できないのはちょっと厳しいなぁ…VMであらかじめ実験しといて良かったぜ……slog/L2ARCは削除できるんだから、将来的にできるようになるのかなぁ………スペシャルvdevの場合、明示的に本体プールの方にデータを書き戻す必要があって難しいのかなぁ…………

当面はpL2ARCを使うとするかー。

プールのメタデータを丸っと引き受けるというZFSのSpecial vdevの特性から、対応する物理デバイスの故障などでSpecial vdevが死ぬと、プールそのものが使えなくなりそうってのは容易に想像ができる。

実際どうなるか仮想マシンベースで確認してみると、やはり使えなくなった。それもzpool listの結果にプール自体が出てこなくなるという、割と重篤な扱い。プール名を指定 or プール探索でインポートしようとすると、以下のようになってインポートできない。

# zpool import -a -N
cannot import 'ztest': I/O error
        Destroy and re-create the pool from
        a backup source.

存在しないプールのインポートではcannot import 'znotexists': no such pool availableって感じなので、明らかに扱いが違う。

Special vdevが消失したプールの復旧は基本的に無理っぽい感じ。

一応man zpool-importを見てみると、（いつの間にか）プール回復に関するオプション-F, -X, -Tが追加されていた。それぞれの効果を抄訳してみた。

-F < -X < -Tの順で強力（危険）になる雰囲気。で、それぞれを指定して、先のSpecial vdevが無くなったプールのインポートを試みたのが以下。

# zpool import -F ztest
cannot import 'ztest': I/O error
        Destroy and re-create the pool from
        a backup source.

# zpool import -FX ztest
cannot import 'ztest': one or more devices is currently unavailable

# zpool import -T ztest
invalid txg value
usage:
        import [-d dir] [-D]
        import [-o mntopts] [-o property=value] ...
            [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]] -a
        import [-o mntopts] [-o property=value] ...
            [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]]
            [--rewind-to-checkpoint] <pool | id> [newpool]

-Tはtxgを指定してやらないとダメな予感。usageにもmanにもそれらしいことは書いてないんだけど…実際にどんな値を指定したらいいのか皆目見当もつかない。

その後、Special vdev用の仮想ディスクを戻してみると、問題なくプールのインポートができた。ただし自動インポートはされず、手動で行う必要があるようだ。（上記の-Fとかでプールを操作したためかもしれないが未確認。）scrubで健全性に問題がないことも確認。

そんなわけでSpecial vdevの冗長性には十分気を付ける必要がありそうだ。