Micron 9200 MAX 1.6TBのベンチマーク
MicronのU.2接続なSSD、9200 MAX 1.6TB (MTFDHAL1T6TCU)を買ったので恒例のベンチマーク。
公称スペックは以下のとおり。
- シーケンシャル
- 読み込み 3500 MB/s
- 書き込み 1900 MB/s
- ランダム
- 読み込み 680000 IOPS
- 書き込み 255000 IOPS
- TBW: 17.5PB
もちろん中古購入でS.M.A.R.T.はこんな感じ。
使用時間10047時間≒418日で、電源投入回数45回ってことは間違いなくどこかのサーバに積まれてたものだろうけど、その割に投入回数が多いような気がしなくもない。単純計算で10日に1回でしょ?読み書き量が少なめなのも謎。
CrystalDiskMark 8.0.0 x64
設定:デフォルト
設定:NVMe
AS SSD Benchmark 2.0.6485.19676
気になった点
ベンチしてて気になったのは、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.0リリース!!
本日、ついにOpenZFS 2.0がリリースされた!!
リリースノート:Release OpenZFS 2.0.0 · openzfs/zfs · GitHub
Today we released OpenZFS 2.0, based on the unified code for Linux and FreeBSD. New features include sequential resilver, persistent L2ARC, zstd compression, and lots of performance improvements! https://t.co/SOHgzMln94
— OpenZFS (@OpenZFS) November 30, 2020
ZFS環境的には、なんといってもLinuxとFreeBSD向けの実装が統合され、1つのソースツリーからビルドされるようになったのが大きい。実態としては、以前から書いてきたとおり、ZFS on LinuxプロジェクトがOpenZFSプロジェクトとなり、FreeBSD向けの修正が行われたという感じで、“統合”って感じではないんだけど、いずれにせよZFSを取り巻く環境は今後ますます発展していくことだろう。
機能面では、永続的L2ARCと圧縮アルゴリズムとしてZStandardが追加されたのが大きいかな。
これを書いている時点で、PortsのOpenZFSの方はまだ更新されてないが、遅かれ早かれ2.0になると思われる。FreeBSDのベースシステムのZFS実装が置き換わる具体的な時期は不明だが、当初の計画では13.0-RELEASEで置き換わることになってたはず。こちらも無事に進んでくれることを祈りたい。
FreeBSD 12.1のvirtioドライバはバグってるっぽい?
FreeBSD 12.1-RELEASEのvirtioドライバは何かしら不具合があるようだ。仮想環境のゲストとして動かした際に、virtio経由のデバイスが認識されなかったり正しく動かなかったりする模様。もしかすると、12.0-RELEASEや11.3でも同様かも。
このところProxmox VEにお熱で、自宅のFreeBSDサーバをP2Vすべく調査や実験を行っている。P2Vと言ってもPCIパススルーやRaw Device Mappingなどを使い、本来の仮想化とは少々毛色が違うのだが、この構成にしとけばいつでもV2P出来るというメリットがある。
そんなわけで、起動ディスクのNVMe SSDをPCIパススルーし、VMを起動して無事FreeBSDの起動シーケンスが流れてktkrと思ってたら、忌まわしき「Mounting from zfs:zroot/ROOT failed with error 5.」で止まってしまった。
ZFSでこのエラーになってしまったら、ここから復旧できる見込みはまずない。
仕方ないのでProxmoxやVMの設定、KVMのパススルーまわりのあれこれの見直し、FreeBSD側の/boot/loader.confのチェックにzpool.cacheの再生成など、知る限りのあらゆることを試しても症状は変わらず。
起動メッセージをよーく確認すると「ptnetmap-memdev0: cannot map I/O space」「device_attach: ptnetmap-memdev0 attach returned 6」がチラホラ出ていた。
それらしい単語でググるとVirtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTSがヒットした。試したVMは確かにQ35で作ってるし、自分と同じくルートプールが見つからなくて起動できない報告もあるし、このバグを踏んだか?
スレを読んでも修正されたんだかされてないんだか分らなかったが、ふと、先行実験でパススルーしたNVMe SSDにインストールした12.2-RELEASEは問題なく起動してたのを思い出した。それならばってことで、いったん通常環境でFreeBSDを起動し、12.2-RELEASEに更新。その後、改めてVMの方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)
参考サイト
Proxmox VE 6.2とX10DRiとR7 430でGPUパススルーできた
念願のGPUパススルーができたので、記録として書き止め。環境は以下のとおり。
- Proxmox VE 6.2-4
- X10DRi
- Xeon E5-2648Lv3 (VMに4コア割り当て)
- Radeon R7 430
- Windows 10 (20H2/x64)
ググれば出てくる方法で、何の苦労もなくできた。記念にDQXベンチVer.1.51の結果をペタり。
最高品質、1920×1080の設定でスコア7256のとても快適の評価となった。Twitterから同スコアを拾ってくると4700、7800、8000、8600、9400って感じでバラついてて何とも言えない所ではあるが、GPUパススルーのオーバーヘッドはそれほど大きくはなさそう。
ついでにリモートデスクトップ経由でベンチした結果はこちら。
これでメインマシンをサーバに収容する計画が一歩前進だなー。実現した場合、Ryzen 3.0GHzおじさんからHaswell-EP 1.8GHzおじさんへと大幅退化することになるわけだが…。H11SSL-iとEPYCほすぃ……。
XigmaNASの設定XMLで無理やりマウントポイントを指定する
XigmaNASの設定XMLファイルを書き換えて、無理やりマウントポイントの設定を行っちゃおうっていう、完全なるバッドノウハウ記事。
WebGUIの「ディスク > マウントポイント > マネージメント」で追加しろよって話なんだが、XigmaNAS 12.1.0.4 (Ingva/revision 7743)ではバグってるようで、マウント対象のディスクに何も表示されないのよ…。
過去のバージョンで設定したものは問題のバージョンに更新後も正常に動いている。となれば、どうにか設定を流し込んで永続化できれば動くハズ。で、苦肉の策で思いついたのが、設定のバックアップ&リストアを使えば行けるんじゃね?っていう。
試してみたら上手くできたので、記録として残しておく。
1. XigmaNASのWebGUIの「システム > 設定のバックアップ」から設定XMLを書き出す。
2. 設定XMLのmounts要素の中にマウントポイント情報を書く。
<mounts> <mount> <uuid>fe8974cf-548c-4aa9-91bf-80bb542cf153</uuid> <type>disk</type> <mdisk>/dev/da0</mdisk> <partition>p4</partition> <fstype>ufs</fstype> <gpt type="bool">1</gpt> <rawuuid>781bae78-8c56-11e7-b005-000c29de16ba</rawuuid> <devicespecialfile>/dev/ufsid/59a4be63ab3efa3e</devicespecialfile> <fsck type="bool">1</fsck> <sharename>sys</sharename> <desc>usb</desc> <accessrestrictions> <owner>root</owner> <group>wheel</group> <mode>0777</mode> </accessrestrictions> </mount> </mounts>
| タグ | 意味 | 備考 |
|---|---|---|
| <uuid> | たぶんXigmaNASがマウントポイントを管理するのに使うUUID | |
| <type> | デバイスの種類 | |
| <mdisk> | マウント対象のデバイスファイル | |
| <partition> | デバイファイルのパーティション識別文字列 | |
| <fstype> | ファイルシステムの種類 | |
| <gpt> | たぶん対象のディスクがGPTであることを表す | |
| <rawuuid> | デバイスのUUID。gpart list デバイスで表示されるマウント対象のrawuuidを指定する。 | |
| <devicespecialfile> | UFSの場合はdumpfs -l デバイスで表示されるパスを指定する。 | |
| <fsck> | たぶん起動時にfsckするかどうかのフラグ | |
| <sharename> | /mntのマウント先ディレクトリ名 | |
| <desc> | XigmaNASのマウントポイントの詳細情報 | |
| <accessrestrictions> | アクセス制御 | |
| <owner> <group> <mode> | 字面のとおり |
4.「システム > 設定のリストア」で書き換えた設定XMLでリストアする。
とりあえず、目先の回避だけできればいいので、各要素の詳細は調べてない。重要なのはmdisk, partition, fstype, rawuuid, sharenameかな?devicespecialfileは指定しなくても動きそうな気もするけど、わかんにゃい。
早くバグが直りますように。
















