色々と事情があって、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を行き来したが為の特殊挙動なのかは分からない。
もし正式挙動だとしたら、プール修復中にマシンが壊れるとプールが死ぬわけだから、正式挙動ではないとは思うんだけど、実際に起こった事象として記録しておく。
2020年12月末にFreeBSDのソースコード管理がSubversionからGitへと移った。将来的に/usr/srcの更新にもgitを使うことになると思われる。現状、Handbookの解説はsvnを使った方法のままだが、そのうち更新されるだろう。一足先にreleng/13.0を使いたいのでgitに移行してみた。
参考資料は↓このへん：
リポジトリは↓ここ：
以下の方法はオレオレ式で、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を使った方が依存関係ができなくていいかも？
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を使う方向で。そのうち安定版が出るのは間違いないだろうし。
LinuxでGPTを作ると、First usable LBAとして512バイトセクタドライブで2048、4kセクタドライブで256が設定されることに気づいた。これだと、パーティショニングツールからは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境界に揃えてやればいいんだけではあるが、これだとパーティション一覧に“未使用領域”として計上されてしまうのが、ちょっとカッコ悪い。
どうでもいいけど調査の過程で、今更ながら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でやった方がいいかもしれないなぁ。
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という具合。末尾のコロンは誤字じゃないのでござる。
rootdev=zfs:zroot/ROOT/default:
2021-01-09現在、これらはドキュメント化されてないので、将来変わるかもしれないし動作の保証も致しかねる。
ま、こんな面倒なことしなくても、従来どおりboot1.efi使えばいいんだけどね！
