ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 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」の構成デバイスだった、ということが推測できる。 1) pathのadaXから推定 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に移行してみた。 参考資料は↓このへん: Warner's Random Hacking Blog: FreeBSD Subversion to Git Migration: Pt 2 Primer for Users Warner's Random Hacking Blog: FreeBSD Subversion to Git Migration: Pt 1 Why? GitHub - bsdimp/freebsd-git-docs: Draft copies of the FreeBSD git transition documents リポジトリは↓ここ: https://git.freebsd.org/src.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を使った方が依存関係ができなくていいかも? < Newer Posts 1 2 ... 8 9 10 11 12 13 14 ... 83 84 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo