ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 今度こそRAIDZ Expansionが来る? RAIDZ ExpansionのPR作成の報を打ってから早2年、今度こそRAID-Z Expansionが来そうな雰囲気?である。 当時のPRは閉じられており、6月末にどういう訳か新しいPRに移行して作業が行われている。見てないけどOpenZFSリーダー会議で移行議論の概要が見られるようだ。 今回は着々とレビューとコミットが積み上げられている。RAIDZ Expansion自体は問題なく動いているようで、既に自前ビルドで使っている勇者もいるっぽい。今度こそマージされてほしい。 Proxmox VEで仮想ディスクを4Knデバイスとして扱う 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 MN08ACA14TとST14000NM001Gのベンチマーク 東芝と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なのはクイックじゃないフォーマットで、ドライブ作ったためであり他意はない。 RAIDZプールに追加したスペシャルvdevは削除できない 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を使うとするかー。 Special vdevが消失したプールとzpool -Fオプション プールのメタデータを丸っと引き受けるという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 インポート不可能なプールのための回復モード。最後のわずかなトランザクションを破棄することで、プールがインポート可能状態への復帰を試みます。このオプションを使うことで、損傷を受けたすべてのプールが回復するとは限りません。成功した場合、破棄されたトランザクションに関連するデータは、回復不能なほどに失われます。プールがインポート可能またはインポート済みの場合、このオプションは無視されます。 -n 回復オプション(-F)と共に使用します。インポート不可能なプールが再びインポート可能になるかどうかを判定しますが、実際にプール回復は行いません。プール回復モードの詳細は、上記の-Fオプションをご覧ください。 -X 回復オプション(-F)と共に使用します。有効なtxgを見つけるための非常手段を取るか否かを指定します。これは、もはや一貫性が保証されていないtxgへ、プールがロールバックされることを許可します。矛盾したtxgでインポートされたプールは修復不能なチェックサムエラーを含むかもしれません。プール回復モードの詳細は、上記の-Fオプションをご覧ください。警告:このオプションはプールの健全性に対し極めて危険な可能性があり、最終手段として用いるべきです。 -T ロールバックに使用するtxgを指定します。暗黙的に-FXオプションを含みます。プール回復モードの詳細は、上記の-Xオプションをご覧ください。警告:このオプションはプールの健全性に対し極めて危険な可能性があり、最終手段として用いるべきです。 -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の冗長性には十分気を付ける必要がありそうだ。 start.txt 最終更新: 2022-07-27 15:26by Decomo