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を使った方が依存関係ができなくていいかも？

permalink · 2021-02-09 20:28 · Decomo · 0 Comments · Tags:

FreeBSD
PC

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を使う方向で。そのうち安定版が出るのは間違いないだろうし。

permalink · 2021-02-02 20:59 · Decomo · 0 Comments · Tags:

Proxmox VE 6.3とConnectX-3を使って、ゲストのWindows 10 ProfessionalでSR-IOVのVirtual Functionが動いたぞー！デバイスマネージャで認識させるところまでは楽勝だったが、何度ドライバ当て直してもエラーコード43で動かなくて随分苦労した。結局、PVEのビルトインドライバが古かったのが原因だったけど、それはまた後日。

見せてもらおうか、SR-IOVの性能とやらを！

物理マシンのWindows 10と、PVE上の仮想マシンのWindows 10をConnectX-3の40GBASE-SR接続した環境で、MS謹製ネットワーク性能測定ツールNTttcpを使い速度を測った。物理マシンが送信側、VMが受信側とした結果は下図のとおり。

右下のアクティブなタスクマネージャが物理側で、他のウィンドウはリモートデスクトップ経由のVM側だ。26Gbpsほど出ているのがわかる。同じ条件でVM側をvirtio-netとすると12Gbps程度だった。速度も然ることながらPVEのCPU負荷が段違いなので、さすがSR-IOV。

なお、最大瞬間風速で32Gbps程度出ることは確認した。

permalink · 2021-01-16 23:04 · Decomo · 0 Comments · Tags:

LinuxでGPTを作ると、First usable LBAの値が512バイトセクタドライブで2048、4kセクタドライブで256となる。すなわち、LinuxはGPTとして1MiBを確保する。

GPTの情報を格納するのに必要なサイズは16.5KiBなので、本来は33セクタ@512Bまたは5セクタ@4KiBで事足りる。FreeBSDの39セクタ@512Bに慣れた身からすると、無駄とも思えるサイズである。

この理由を調べてみると、どうもWindowsとの互換性のためっぽい。

WindowsではVistaとWindows Server 2008から、パーティションを1MiBアライメントで揃えるようになったそうだ。Linuxはこれに倣ったとのこと。1MiBアライメントなら、512バイトと4kBの倍数なので所謂AFTアライメント問題が解消でき、将来、より大きなセクタサイズが登場した時に対応できる可能性も高まる、というのが狙いらしい。

言われてみれば納得の理由で、逆にFreeBSDが20KiBしか確保しないことが不安になってくる…。パーティション追加時にgpart create -a 1Mとすればパーティションを1MiB境界で揃えることはできる。一方で、First usable LBAを弄るものではないので、パーティション一覧を出したときにGPTと第1パーティションの間に“未使用領域”が計上されてしまうのが、ちょっとカッコ悪い。

どうでもいいけど調査の過程で、今更ながらCHSやらセクター63やらシリンダ境界規定やらを調べてしまった。

（2021-01-16 追記）

Linuxのfdiskで切ったパーティションをFreeBSDで見てみた。

> gpart show
=>        6  234423115  nvd0  GPT  (894G)
          6     131072     1  efi  (512M)
     131078   26214400     2  freebsd-zfs  (100G)
   26345478  208077643        - free -  (794G)

=>      256  468843345  nvd1  GPT  (1.7T)
        256     131072     1  efi  (512M)
     131328   26214400     2  freebsd-zfs  (100G)
   26345728  375914496     3  !6a898cc3-1dd2-11b2-99a6-080020736631  (1.4T)
  402260224   13107200     4  !6a898cc3-1dd2-11b2-99a6-080020736631  (50G)
  415367424   53476177        - free -  (204G)

nvd0がFreeBSDのgpart、nvd1がLinuxのfdiskで作成したもので、どちらも4kセクタである。

FreeBSDのgpartもFirst usable LBAをちゃんと見ているようで、nvd1のESPの開始セクタ256セクタ＝1MiB地点を正しく認識している。

将来のことを考えると、GPTを作るところまではLinuxまたはWindowsでやった方がいいかもしれないなぁ。

permalink · 2021-01-13 08:27 · Decomo · 0 Comments · Tags:

FreeBSD 12.0-RELEASEあたりから、UEFIのブートローダとして従来のboot1.efiに代わりloader.efiが使われるようになった。

どちらもZFSまたはUFSからシステムを起動する役割を持つが、boot1.efiは複数のストレージからファイルシステムを探すのに対し、loader.efiは自身が読み込まれたストレージのみが対象となる。簡単に言えば、loader.efiだと別HDDのFreeBSDシステムを起動できないというわけ。まぁ、ブートローダのプロンプトで手動で起動デバイスを指定してやれば出来るんだけど、毎度行うのは現実的ではないよね。

どうにか自動化できないかと各種文献あさりとGooglingをしてみるも、それらしい情報はなく…。仕方なくソースコードを眺めてみると、loader.envでrootdev変数を指定してやれば行けそうと分かった。

loader.efiにせよboot1.efiにせよ、最終的に起動対象はcurrdev変数の値が使われるが、loader.efiの場合rootdev変数の値が問答無用でcurrdevとして採用される。

でもって、rootdevの設定はEFIシステムパーティションの/efi/freebsd/loader.envファイルで行う。これは比較的最近作られた機能で、12.2-RELEASEから使えるようだ。

同ファイルに以下の一行を追加。ルートディレクトリとなるファイルシステムを指定する。UFSならdisk0p1という具合。末尾のコロンは誤字じゃないのでござる。