Supermicro SuperWorkstation 7048A-Tのファンの一覧
SuperWorkstation 7048A-T (SuperChassis 743TQ-1200B-SQ)で使われているファンの備忘録。
- CPUファン (SNK-P0050AP4)
- Nidec UltraFlo T92T12MS3A7-57T07
- 92mm角 25mm厚
- 12V 0.35A
- 7枚羽
- 型番の命名規則から読み解くと、NBRXタイプの回転数カスタム仕様のSupermicro向け特注品っぽい。
- 背面ファン
- Nidec UltraFlo T92T12MHA7-57T071
- 92mm角 25mm厚
- 12V 0.14A
- 7枚羽
- NBRXタイプ/高回転数/特注品
- 前面ファン
- FAN-0104L4
- SanAce 80 9S0812P4F051
- 80mm角 25mm厚
- 12V 0.13A
- 7枚羽
- 2800RPM/24dBA/32.9CFM
- コネクタはMolex 51191シリーズの4ピン（51191-0400）
デグレったZFSプールは他マシンでのインポートが制限されるっぽい？
色々と事情があって、FreeBSDで作ったHDD×4台からなるRAIDZプールを、HDD×3でデグらせた状態でZoL環境でインポートした。
すると自動scrubが走るわけだが、処理途中で一旦エクスポートし、FreeBSDの方でHDD×4の状態でインポートしようとしたら出来なかった。
# zpool import zdata cannot import 'zdata': no such pool available
こんなエラーが出るわけ。プールをFreeBSDとLinuxの間で、あまつさえデグレった状態で行き来させたせいで壊れた！？と超焦るわけ。
ZoL環境だと正常にインポートできたのでプールの無事は確認でき、HDD×4に戻してRAID修復が終わるのを待ったところ、FreeBSDの方でも何事もなくインポートできるようになった。
ここから分かることは、どうやらデグレった状態のプールを一度でもインポートすると、プールの健全性が回復するまで別のシステムでのインポートができなくなるらしい？これがZFSの正常な挙動なのか、FreeBSD (Legacy ZFS)とZoLを行き来したが為の特殊挙動なのかは分からない。
もし正式挙動だとしたら、プール修復中にマシンが壊れるとプールが死ぬわけだから、正式挙動ではないとは思うんだけど、実際に起こった事象として記録しておく。
ディスクがどのzpoolに所属していたか調べる
複数のHDDを抜き差ししてると、どのHDDがどのzpoolの構成員か分からなくなる事がある。ちゃんと管理しとけって話だが、そんな時はzdb -lでZFSのラベル情報を表示すればよい。
ProxmoxVE (ZFS on Linux)での実行なので、デバイス名はsdXになっている。
# zdb -l /dev/sdh1
------------------------------------
LABEL 0
------------------------------------
version: 5000
name: 'zdata' ★これ
state: 0
txg: 23527188
pool_guid: 15920220212014191793
hostid: 1525007054
hostname: 'hostname.example.com'
top_guid: 1118325231086088749
guid: 9773797371878116701
vdev_children: 1
vdev_tree:
type: 'raidz'
id: 0
guid: 1118325231086088749
nparity: 1
metaslab_array: 34
metaslab_shift: 37
ashift: 12
asize: 31989740601344
is_log: 0
create_txg: 4
children[0]:
type: 'disk'
id: 0
guid: 3334618698730764157
path: '/dev/ada5p1'
phys_path: 'id1,enc@n3061686369656d31/type@0/slot@3/elmdesc@Slot_02/p1'
whole_disk: 1
DTL: 291
create_txg: 4
children[1]:
type: 'disk'
id: 1
guid: 4503436449772901953
path: '/dev/ada3p1'
phys_path: 'id1,enc@n3061686369656d31/type@0/slot@1/elmdesc@Slot_00/p1'
whole_disk: 1
DTL: 290
create_txg: 4
children[2]:
type: 'disk'
id: 2
guid: 9773797371878116701
path: '/dev/ada2p1'
phys_path: 'id1,enc@n3061686369656d30/type@0/slot@3/elmdesc@Slot_02/p1'
whole_disk: 1
DTL: 289
create_txg: 4
children[3]:
type: 'disk'
id: 3
guid: 1033141966906037929
path: '/dev/ada4p1'
phys_path: 'id1,enc@n3061686369656d31/type@0/slot@2/elmdesc@Slot_01/p1'
whole_disk: 1
DTL: 288
create_txg: 4
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
labels = 0 1 2 3
注目すべきはnameの項目で、プール名がそのまんま入っている。さらに他の項目からプールの詳細がわかる。
- name:
- プール名
- hostname
- プールを作成したホスト名
- vdev_tree: type
- プールの構成方法
- vdev_tree: children
- vdevを構成するストレージの数
- vdev_tree: children: path
- プール構成ストレージとして最後に認識された時のデバイスパス
これらを読み解くと、/dev/sdh1は「FreeBSDマシン1)hostname.example.comで作られた4台構成のRAID-Zプールzdata」の構成デバイスだった、ということが推測できる。
PVEとConnectX-3とWindowsでSR-IOVが使えないのはMLNX_OFEDが古いせい
Proxmox VE 6.3のWindows 10ゲストでConnectX-3のSR-IOVが機能しないのは、PVE内蔵のmlx4ドライバが激古なのが原因のようだ。正確にはLinuxのインボックスドライバだが。
この状態だと、SR-IOVは有効でWindows側にVirtual Functionが生えているにもかかわらず、コード43となって、どうあがいてもデバイスが動かない。PVE側では以下のようなログが出る。
mlx4_core 0000:01:00.0: vhcr command:0x43 slave:1 failed with error:0, status -22 mlx4_core 0000:01:00.0: Received reset from slave:1
“Mellanox OFED for Linux Archived Bug Fixes”を眺めると、Internal Ref 1178129に、まさにそれっぽいバグが載っていた。
Description: Fixed an issue that prevented Windows virtual machines running over MLNX_OFED Linux hypervisors from operating ConnectX-3 IB ports.
When such failures occurred, the following message (or similar) appeared in the Linux HV message log when users attempted to start up a Windows VM running a ConnectX-3 VF:
“mlx4_core 0000:81:00.0: vhcr command 0x1a slave:1 in_param 0x793000 in_mod=0x210 op_mod=0x0 failed with error:0, status -22”
バグはIBポート、うちはEthポートという違いがあるが、状況としては極めて近い。この問題はMLNX_OFED v4.2-1.2.0.0で修正済みで、2021-02-10現在の最新版はv4.9-2.2.4.0 LTSであるから、とっくの昔に解決済みのハズである。
そんなバグに何で今更遭遇するの～？と思いきや、Linuxのインボックスドライバはなんとv4.0相当という事実が判明／(^o^)＼ Kernel.orgのBugzillaでも指摘されてるが、ガン無視の模様…。
しゃーないので自前ビルドしたら無事動いた。なんだよもう、めっちゃハマったやんけ！
それでも完全解決とはいかず、デバイスは動いているように見えるものの、なぜかパケットが流れない事がある。初期化系の何かっぽくて、何度かVMを再起動して一度通信できる状態になれば、途中で途絶する事はないのが不幸中の幸いではあるが。
もう1つ気になるのは「イーサネットの状態」のパケット数カウントが何かおかしいこと。受信パケットが常に0で、これが原因かわからんがVF経由だとiTunesでGracenoteへの接続に失敗する。virtio-netの方だと大丈夫なので、うちのネットワークがおかしい訳ではない。
SR-IOVまわりは情報があまりなくて、よう分からん。
(2021-12-07 追記)
WinOF v5.50.5400のKnown Issuesを眺めてたら、Internal Ref. 1297888にパケット数カウントがおかしい問題が思いっきり載っていた……というわけで、Windowsドライバのバグで確定。
回避策がN/Aなのでドライバ修正を待つしかないが、果たして更新されることはあるのだろうか。もうConnectX-3はLTSフェイズだしなぁ。ConnectX-4がお安く手に入ればいいんだけど。
FreeBSDの/usr/srcをGitに移行する
2020年12月末にFreeBSDのソースコード管理がSubversionからGitへと移った。将来的に/usr/srcの更新にもgitを使うことになると思われる。現状、Handbookの解説はsvnを使った方法のままだが、そのうち更新されるだろう。一足先にreleng/13.0を使いたいのでgitに移行してみた。
参考資料は↓このへん：
リポジトリは↓ここ：
- cgit.freebsd.orgにリダイレクトされるけど、cなしの方が公開ミラーという扱いっぽい。cなしURLを使っといたほうが良さそう？
以下の方法はオレオレ式で、FreeBSDプロジェクトの公式方法ではないので注意。
何はともあれgitをインストール。
# pkg install git
/usr/srcの中身を消す。過去にmake worldしたことがある人は、オレオレカーネルコンフィグファイルとかがあると思うので間違って消さないよう気をつけて下さい。.svnフォルダの削除も忘れずに。
# cd /usr/src # rm -rf * .*
Gitリポジトリからソースコードを取得する。
何もせずに取得（クローン）すると変更履歴をローカルに全て持つことになる。いち利用者としては過剰なので、–depthで取得範囲を制限する。同オプションを使うと、mainブランチ―FreeBSDで言うところのCURRENTしか取得されないので、–no-single-branchを加えて他のブランチ情報を取得するようにする。
# pwd /usr/src # git clone -o freebsd --depth 1 --no-single-branch https://git.freebsd.org/src.git .
なお、当方の環境では/usr/srcが独立したZFSデータセットとなっており、中身を空にしても.zfsディレクトリは常に存在する。Gitの「ディレクトリが空じゃないよ」エラーでクローンできなかったため、いったん/usr/src/gitsrcにクローンし中身を/usr/srcに移す方法を採った。
# pwd /usr/src # git clone -o freebsd --depth 1 --no-single-branch https://git.freebsd.org/src.git gitsrc # mv gitsrc/* . # mv gitsrc/.* . # rmdir gitsrc
クローン完了後、git branch -rでreleng/13.0などのブランチがだらら～と表示されればOK。
13.0-RELEASEブランチに切り替える。
# git checkout releng/13.0
実のところ特定ブランチだけなら、-bオプションでgit clone -o freebsd -b releng/13.0 –depth 1 https://git.freebsd.org/src.git /usr/srcとすれば良い。こっちの方がディスクの消費量も少ないし。
ただまぁ、どうせgit使うならブランチ情報込みで持っといた方が、今後13.1-RELEASEなどが出てきた時もgit pullしてgit checkoutするだけで良くなるので、面倒がないかなーと。
(2021-02-18 追記)
他のライブラリなどに依存しない、軽量gitクライアントとしてnet/gitupが用意されている。名前のとおりnet/svnupのGit版の位置づけっぽので、ソースコードのクローンしかできなさそう。
ソースコードを取ってくるだけなら、gitupを使った方が依存関係ができなくていいかも？