このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

デグレった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まわりは情報があまりなくて、よう分からん。

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を加えて他のブランチ情報を取得するようにする。

# git clone -o freebsd --depth 1 --no-single-branch https://git.freebsd.org/src.git src/

なお、当方の環境では/usr/srcが独立したZFSデータセットとなっており、中身を空にしても.zfsディレクトリは常に存在する。「ディレクトリが空じゃないよ」エラーでクローンできなかったため、以下のように細工した。

# git clone -o freebsd --depth 1 --no-single-branch https://git.freebsd.org/src.git src
# mv src/* .
# mv src/.* .
# rmdir src

クローン完了後、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を使った方が依存関係ができなくていいかも?

pfSense 2.4.5 on PVE 6.3でConnectX-3のVFが認識されない

SR-IOVでつよつよルータ大作戦始動!

というわけで、Proxmox VE 6.3-2にpfSense 2.4.5-p1のVMを作り、ConnectX-3のSR-IOVのVFをPCIパススルーしてみたが、うまく認識されなかった😇

dmesgに「pcib1: failed to allocate initial I/O port window: 0xd000-0xdfff」「pcib1: Failed to allocate interrupt for PCI-e events」といったログが記録され、pciconf -lvしてもデバイスが出てこない。そもそもデバイスプローブでこけてるっぽい。

pfSense 2.4はFreeBSD 11.3-RELEASEベースなので、より新しいFreeBSD 12なら動くんじゃね?と12-STABLEベースの2.5開発版を試してみる。

相変わらずエラーの前者は出ているものの、無事PCIデバイスとして認識されmlxenが生えてきた。2つのVFを連番でパススルーしてるのに、なぜかmlxen0とmlxen2と識別されてて少々気持ち悪いが、まぁ良しとしよう。

mlx4モジュール自体は、pfSense 2.4.5でも2.5でもカーネルに組み込まれているようだ。

NICが使えないんじゃ話にならんので、とりあえず2.5を使う方向で。そのうち安定版が出るのは間違いないだろうし。

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0