FreeBSD開発への1年間の支援
(daemonology.net)- FreeBSD/EC2のメンテナンスとリリースエンジニアリングが1人のボランティア時間の中で競合していた状況で、Amazonによる1年間の支援により、リリース運用とEC2プラットフォーム改善を同時に進められるようになった
- 支援はGitHub Sponsors経由で名目上は月40時間規模だったが、実際の作業は平均で月50時間で、EC2の課題・リリース進行・その他のリリースエンジニアリングが概ね20/20/10時間に分かれた
- 1年間でFreeBSD 13.4、14.2、13.5、14.3のリリースを管理しながら、AWS Gravitonの電源終了シグナル処理やEC2のデバイスホットプラグといった優先作業も並行して行った
- 起動性能のリグレッションを突き止めるため、2018年以降の週次EC2 AMIビルドをベンチマークし、ルートディスクサイズ、EFIエントロピーシーディング、ZFSトランザクショングループ、IMDSv2 IPv6変更に遅延原因を見つけて修正した
- 支援終了後も役割は継続するが、リリース直前の問題を自ら修正したり、EC2機能リストを継続的に前進させたりするために投入できる時間は減る
支援前のボトルネックと時間配分
- FreeBSD/EC2のメンテナンスは、2010年にAmazon EC2でFreeBSDを初めて起動して以来続いており、2023年11月にはFreeBSDリリースエンジニアリングリードの役割も追加された
- AntithesisとFreeBSD/EC2 Patreonからの少額支援だけでは、2つの役割を担うのは難しかった
- 実装すべき機能リストが停滞した
- 異常を見つけても調査する時間がなく、先送りが増えた
- 2024年初頭には、FreeBSD/EC2プラットフォームの「良いオーナー」としての役割を果たすのが難しいという懸念が大きくなった
- 2024年4月、Amazonで予算を持つ担当者が見つかったことで、スケジュール・範囲・手続きの議論が進み、AmazonがGitHub Sponsorsを通じて1年間支援することになった
- 支援対象は、FreeBSDリリースエンジニアリングとFreeBSD/EC2開発を合わせた月40時間規模だった
- 2つの作業は相互に依存しており、どちらか一方だけを支援する方式は現実的ではないと伝えた
- 実際の投入時間は平均で月50時間ほどに増えた
- 平均するとEC2専用の課題が20時間、FreeBSDリリース進行が20時間、その他のリリースエンジニアリング関連作業が10時間だったが、月ごとのばらつきは大きかった
四半期リリース運用とビルド改善
- 2024年7月に発表したFreeBSDの四半期リリーススケジュールに従い、1年間で4つのリリースを管理した
- FreeBSD 13.4: 2024年9月
- FreeBSD 14.2: 2024年12月
- FreeBSD 13.5: 2025年3月
- FreeBSD 14.3: 2025年6月10日リリース予定
- 各リリースには、コードマージの促進、マージリクエストの承認・却下、他チームとの調整、イメージのビルド・テスト、告知文の作成、リリースビルド問題の修正が含まれる
- 通常は3つのBeta、1つのRelease Candidate、最終Releaseをビルドする
- 作業の大半はリリース前月、つまり各四半期の2か月目である「Beta Month」に集中する
- FreeBSD 13.5は33.5時間、FreeBSD 14.2は79時間かかった
- 安定ブランチの後半に進むほど壊れる項目が減り、リリース作業量も減る傾向がある
- FreeBSD 14.1は追跡していないが、リリースエンジニアリング時間は100時間近かったと見られ、FreeBSD 15.0はそれを大きく上回る可能性が高い
- 一般的なリリースエンジニアリングでは、リリースビルドの並列化も進めた
- EC2 AMIの数が増えたことで、実際のビルドよりもVMイメージにFreeBSDをインストールする時間が大きな割合を占めるようになった
- リリースコードを並列化したが、散発的なビルド失敗が発生し、リリースビルド全体に約24時間かかるため原因の切り分けが難しかった
- 最終的な原因は、ファイルをインストールする前にディレクトリを作成する必要があるMakefileの1行が欠けていたことだった
- 修正後、リリースビルドは約22時間から約13時間に短縮され、ビルド時間のために先送りしていたEC2 AMI flavourの拡張も可能になった
- ビルドの再現性問題は、EC2を活用して定期的に確認し始めた
- 週次スナップショットイメージのテスト過程でEC2インスタンスを起動し、自分自身のAMIをビルドさせた
- diffoscopeで生成されたディスクイメージと元のイメージを比較した
- 定期テストを通じて複数の課題を発見し、一部は自分で修正し、一部は他の開発者に引き継いだ
FreeBSD/EC2におけるGravitonの電源処理とホットプラグ
- AmazonがFreeBSD/EC2で優先事項として求めた主要機能は、AWS Gravitonインスタンス向けのpower driverとデバイスホットプラグだった
- Gravitonの電源ドライバは、EC2 APIがオペレーティングシステムへ終了を通知する経路を処理する
- この機能がないと、FreeBSDは終了シグナルを無視し、数分後にEC2がタイムアウト後に仮想電源を切る
- Gravitonシステムの「電源ボタン」はGPIOピンであり、詳細情報はACPI
_AEIオブジェクトに入っている - ACPIからその情報を見つけ、PL061 GPIOコントローラドライバへ構成情報を渡すコードを追加した
- GPIOピンがassertされるとコントローラが割り込みを生成し、ACPIの「power button」イベントが発生してシステム終了につながる
- EC2が提供するACPIテーブルは当該GPIOピンを「Pull Up」に設定するよう指定しているが、PL061コントローラにはpullup/pulldown抵抗がない
- LinuxはGPIO構成失敗を静かに無視するため、問題が表面化しなかった
- FreeBSDは構成失敗後にデバイスを無効化した
- 今後GravitonシステムでEC2のバグは修正されると見ているが、現時点ではFreeBSD/EC2 AMIに
ACPI_Q_AEI_NOPULLquirkを入れ、_AEIオブジェクトのGPIO PullUpフラグを無視している
- ホットプラグ、とりわけホットアンプラグは、複数のEC2インスタンスタイプで異なる問題が重なっており、より多くの作業が必要だった
- 一部のGravitonシステムでは、PCI attach中に仮想IRQ予約がリークし、EBSボリュームを67回attach/detachした後にIRQが枯渇してFreeBSDカーネルパニックが発生した
- 原因はレガシーPCI割り込みルーティングコードであり、EC2でそのコードを無効にするブートローダ設定を追加した
- 一部のGravitonシステムでは、OSがデバイスの使用を終えeject準備ができたかどうかを判断するシグナルとして、PCIデバイスの電源状態を使っていた
- これはEC2のバグと判断されており、現在は
ACPI_Q_CLEAR_PME_ON_DETACHquirkで、eject前にPCI電源管理レジスタの一部ビットを変更している
- これはEC2のバグと判断されており、現在は
- 最新世代EC2インスタンスのx86とGravitonでは、PCIe unplug後にFreeBSDの
nvmeドライバがパニックを起こす- この問題は
nvmeドライバのメンテナに引き継いだ
- この問題は
- 一部のx86・Graviton EC2インスタンスでは、eject後にPCIバス上に「ghost」デバイスが残り、新しいデバイスのattachを妨げた
- NitroファームウェアがPCIバス管理とPCIデバイス管理を非同期に行うため、デバイスはunplugされたがPCIバスは数msの間まだ存在すると報告される時間窓があった
- Linuxはバスを定期的にスキャンするため通常この競合に負けるが、FreeBSDはdetach直後にPCIバスを即座に再スキャンするため、ghostを見ることが多かった
- 現在は
ACPI_Q_DELAY_BEFORE_EJECT_RESCANquirkで、ejectシグナル後、PCIバス再スキャン前に10msの遅延を追加している
- 一部のGravitonシステムでは、PCI attach中に仮想IRQ予約がリークし、EBSボリュームを67回attach/detachした後にIRQが枯渇してFreeBSDカーネルパニックが発生した
- PCIeはデバイスeject要求用の「attention」ボタンを押した後に5秒の遅延を要求し、2回目のボタン入力があるとeject要求をキャンセルする
- EC2には物理ボタンを押す人がおらず、仮想ボタンを再度押す仕組みもないため、この遅延は不要である
- ブートローダtunableを追加し、EC2ではタイムアウトを0に設定した
- ホットプラグテストスクリプトでEC2インスタンスを起動した後、EC2 APIでEBSボリュームを繰り返しplug/unplugし、FreeBSDが300回連続でattach/detachできるかを確認できるようにした
- 将来EC2インスタンスタイプに事前アクセスできるなら、ホットプラグ動作の確認に活用できる
起動性能リグレッションの追跡とAMI拡張
- Amazonの最優先作業2つ以外にも、EC2専用時間のおよそ半分は他のFreeBSD/EC2問題に使われた
- 2023年末から2024年初頭にかけて、FreeBSD/EC2インスタンスが時折想定より長く起動に時間を要し、週次スナップショットテストでインスタンス起動後、SSH接続を試みる前の待機時間を延ばす必要があった
- 性能問題に対処するため、2018年以降の週次EC2 AMIビルドの起動時間をベンチマークした
- この過程で1万個以上のEC2インスタンスを実行した
- FreeBSDのboot performance plotsを生成し始めた
- 新しいデータ収集とプロット更新は週次スナップショットテストの過程に組み込まれた
- 複数の起動遅延原因を見つけて修正した
- 2024年の第1週からFreeBSDの起動が約3倍遅くなり、原因はルートディスクサイズを5GBから6GBに増やしたコミットまで追跡された
- Amazon側の確認の結果、ルートディスクサイズを8GBに増やすと以前の水準の性能が回復した
- Graviton 2系では、カーネルエントロピーシーディング問題により起動が長くなっていた
- FreeBSDカーネルは、セキュアな乱数生成のためのエントロピーが不足すると、より多くのエントロピーを集めるまで起動を停止する
- EFIブートローダ経由でNitroファームウェアからセキュアなシードを受け取るコードがあったが、EC2では実行されず、Graviton 2では2048バイトの要求が非常に遅かった
- ブートメニューのLuaコードにあった要求を適切なブートローダLua位置へ移し、メニューの有効・無効に関係なく実行されるようにした
- 64バイトのEFIエントロピーを受け取り、PBKDF2で2048バイトのAPI入力に合うよう拡張するよう変更したことで、FreeBSD
arm64/base/UFSの起動時間は約25秒から約8秒に短縮された
- ZFSイメージはUFSより起動が長く、遅延幅はディスクサイズではなくディスク上のデータ量によって変わっていた
makefsがすべてを単一のトランザクショングループに入れ、ZFS attach時に最近のトランザクショングループを走査して検証する中で、ディスク上の全ファイルメタデータを読み取って処理していた- Mark Johnstonがファイルシステムにより高いトランザクショングループを記録させることで、単一のトランザクショングループが「最近」と見なされないようにして解決した
- ZFSイメージの起動時間は約22秒から約11秒に短縮された
- 2024年12月、
net/aws-ec2-imdsv2-getポートのIPv6対応追加後、起動問題が素早く検出された- このポートはEC2 Instance MetaData Service向けのコマンドラインインターフェースを提供する
- IPv6を先に試したが、デフォルトのIMDSインスタンス構成はIPv4-onlyであり、デフォルトのTCPタイムアウト75秒もそのままだった
- 修正後はIPv4を先に試し、タイムアウトを100msに短縮した
- 2024年の第1週からFreeBSDの起動が約3倍遅くなり、原因はルートディスクサイズを5GBから6GBに増やしたコミットまで追跡された
- FreeBSD AMI flavourも拡張した
- 既存は
baseとcloud-initだけだった smallAMIはdebug symbol、LLDB、32ビットライブラリ、FreeBSDテスト、Amazon SSM Agent、AWS CLIを削除し、ディスク使用量を約5GBから約1GBに減らしたbuilderAMIは、ユーザーがカスタムFreeBSD AMIを簡単に作れるFreeBSD AMI Builder AMIsを提供する
- 既存は
- 4つのAMI flavour、2つのファイルシステム、2つのアーキテクチャ、3つのFreeBSDバージョンの組み合わせにより週次スナップショットビルドが増えたため、古いイメージと関連するEBSスナップショットを整理した
- FreeBSDリリースエンジニアリングのAWSアカウントはAmazonの支援を受けているが、誰かの費用は発生している
- シェルスクリプトを作成し、336TBのEBSスナップショットを削除できた
支援終了後に残る作業と制約
- 大きなプロジェクト以外にも、複数の小さな作業が続いた
- 週次スナップショットビルドで見つかったビルド破損の修正
- ENAドライバパッチのレビュー
- Dave CottlehuberがOCI Containerをビルドしてリポジトリにアップロードする機能を追加するのを支援
bsdec2-image-uploadツールが内部AWSエラーをより穏やかに処理するよう改善- 偶然発見したAWSセキュリティ問題の報告
- 支援終了後も、FreeBSDリリースエンジニアリングリードとFreeBSD/EC2プラットフォームメンテナの役割は続く
- FreeBSD 15.0は12月に到着予定
- 2026年には14.4、15.1、14.5、15.2が続く予定
- 投入できる時間が減ることで、リリース直前の問題を自ら修正する方式は難しくなる
- 遅れて入ってくる機能は、リリースに合わせて修正されるよりも削除される可能性が高くなる
- FreeBSD 14.2からOCI Containersを含められたのは、支援された時間により必要なピースがきちんと入るよう確認できたためである
- EC2側では起動性能リグレッションテストが整備されており、関連問題を捕捉できる可能性はあるが、追加時間がなければ機能実装リストは停滞する可能性がある
- EBSボリューム拡張時のファイルシステム自動拡張
- 複数ネットワークインターフェースとネットワークインターフェースホットプラグの自動構成改善
- ローリング「pre-patched」AMI
- パッケージインストールやデーモン実行などのためのEC2 user-dataファイル生成Webサイト
- FreeBSD/Firecracker作業の再開と対応プラットフォーム化
- Amazonの支援は、ほとんどのオープンソース開発者が受けるものよりはるかに大きな機会であり、支援が終わる寂しさとともに、これまでの作業成果への感謝が残る
1件のコメント
Hacker News のコメント
いいですね。今日から ziglang.org のダウンロードページに FreeBSD を追加したので、FreeBSD ユーザーは CI で自動ビルドされた master ブランチのビルドを入手できるようになりました
これで libc リンクまで含めて第一級のクロスコンパイルターゲットとしてサポートするため、
zig cc -o hello hello.c -target riscv64-freebsdのようなことも可能ですC/C++ の依存関係があれば Zig ビルドシステムに取り込んでビルドできるので、かなり複雑なプロジェクトでも FreeBSD 向けに簡単にクロスコンパイルできるようになると思います。より多くのプロジェクトが FreeBSD サポートと CI テストを追加する助けになればと願っています
公式に認められた C の代替があるといいですね
ここには面白い箇所がかなりあります
「2024年の第1週から FreeBSD の起動プロセスが突然およそ3倍遅くなった。コミットを二分探索してみると、原因はルートディスクのサイズを 5GB から 6GB に増やしたコミットだった。なぜそうなったのか？ Amazon の知人に尋ねると、答えは『魔法』と『本当に知りたくないこと』の間のどこかで、重要なのはルートディスクを 8GB に増やすと性能が以前の水準に戻ったという点だった」
これが観測された性能の崖と関係しているかは分かりません
ノートPC方面でも多くの作業があり、BSD Foundation がここに 75万ドルを投資したと読みました
S0ix 省電力状態のような実装も含まれており、プロジェクトはこちらで見られます: https://github.com/FreeBSDFoundation/proj-laptop
cperciva には本当に敬意を抱きます
これらすべてと Tarsnap をどうやって両立しているのか分かりません
公平に言えば、ここに費やした時間の一部は Tarsnap から抜け出たものですが、思っていたよりはずっと少ないです
Amazon にはもっと支出して貢献してほしいと思っていましたが、基本的には最低限の FreeBSD サポートにだけお金を払いたいように見えます
Amazon は FreeBSD の支援者リストにもなく [1]、Google は昨年 9千ドルだけ支援しており、Apple もありません。Microsoft は少なくともリストに載っているので評価できます。Meta/Facebook も抜けています
これらの企業は FreeBSD と OpenBSD を使い続け、その恩恵を受けているのだから、基本的に毎年支援するものだと期待していました
[1] https://freebsdfoundation.org/our-donors/donors/?donationYea...
たとえば私に支払われたお金は Foundation を経由していません。推測ですが、企業資金による FreeBSD 開発のうち、Foundation が支援する開発はおそらく10%程度でしょう
その10%は、とくに「会社 X に必要なもの」ではなく「FreeBSD に必要なもの」に集中できるので重要ですが、それでも小さな割合です
第一に、特定年の Foundation への寄付のスナップショットだけを示しているため、寄付履歴は当然分かりません
第二に、開発貢献も示していません。こうした内容は通常、各リリースノートで要約として確認できます [1]
[1] https://www.freebsd.org/releases/
クラウドかどうかに関係なく、Microsoft のサービスが *BSD で動いている例も思い浮かびません
自宅のゲートウェイ/ファイアウォール/DNS/DHCP サーバーとして FreeBSD を使いたかったのですが、自分の 10GbE NIC にはドライバーがないようだったので、結局 Nix を選びました
ずいぶん前に FreeBSD をワークステーションとして使っていて、かなり印象に残る経験でした。今も着実に動き続けているのを見るとうれしいです
Realtek は、ドライバーを保守している FreeBSD エンジニアたちが懸命に努力していても、負荷がかかると壊れるようです。不満を言っているわけではなく、彼らの努力を尊重しています
これは小さな代償で、より安定性の低い OS をインストールせずに済むようにしてくれます
FreeBSD 7 や 8 のころには、Atheros Wi-Fi カードのようなものでは FreeBSD ドライバのほうが Linux より優れていた時代があったのを覚えている
2021年ごろまでは FreeBSD を好んでいたが、異なる CPU コアが混在するコンピュータが一般的になるにつれて変わった。最初は big コア2個と little コア4個を搭載した RockPro64 を買い、その後 Intel Alder Lake を買った
私の理解では、FreeBSD のスケジューラはまだこうした構成を適切に扱えず、システムを遅いコア基準の最小公倍数的なところに引きずってしまうように見える
素朴な疑問だが、FreeBSD/EC2 の主なユーザーは誰なのだろう？
EC2 で誰が FreeBSD を使っているのか本当に知りたい
企業によるオープンソース支援がどのように機能するのかを、とてもよく示している記事だ
FreeBSD を使っている人は、Unix の領域で FreeBSD が埋めているニッチが何なのか説明してくれないだろうか？ なぜ、より単純で一貫した OpenBSD や NetBSD ではなく FreeBSD なのか？
答えが ZFS、Nvidia ドライバ、ELF のようなサポートだとしたら、なぜ Linux ではないのか？ GNU の問題はよく分かるが、Musl Void のようなものでも問題があるのだろうか？
本当に気になっている。FreeBSD は私にとって一種の影の領域のように存在していて、動き続けさせている中核的なアイデンティティを正確には捉えられていないが、どこかにあることは分かっている
各サービスは分離のために自分の jail 内で実行され、さほど強力でもないサーバー1台ですべてのサービスを動かせたので、コスト効率は非常に高かった
ある時点でハイブリッド構成にするためクラウド移行を行い、Linux（k8s）と FreeBSD を混在させるとコストが急騰した。データセンターではディスクを自分で購入・交換しなければならず、火災のような状況にも対応しなければならず、1つの国にしかないという欠点があるが、AWS はマルチリージョンや多くの優れた機能を提供しており、その分価格も付いてくる
ZFS を非常に深く活用していたわけではないが、本番 DB でテーブルを誤って削除したとき、直前の ZFS スナップショットに即座にロールバックして一度大いに救われた。多少のデータ損失はあったが、そのアプリケーションでは稼働時間のほうが重要だったので大きな問題ではなかった。バックアップにも ZFS を使っていたと記憶している
本番環境のトラブルシューティングに dtrace を何度か使ったし、FreeBSD サーバー群に Linux を導入すると、チームごとに自然と別々のディストリビューションを選ぶようになり、一種の動物園になった。サーバーで FreeBSD を使うと、変種は1つだけだ
どちらも今でも使っていて好きだが、FreeBSD がカーネルとオペレーティングシステムが統合された形である点が本当に気に入っている
歴史的に FreeBSD は Intel CPU を優先し、NetBSD は移植性がより強く、FreeBSD もセキュリティは堅牢だったが OpenBSD はセキュリティにより集中していた
FreeBSD の ZFS サポートは本当にゲームチェンジャーと言える。Nvidia は最近になってようやくネイティブ FreeBSD ドライバを提供したと理解しており、長い間 FreeBSD の Linux カーネル互換機能が必要だった
つまり FreeBSD は、ほかの BSD が提供する機能をうまく組み合わせながら、私が主に使うハードウェアプラットフォーム上で非常に安定していた
NetBSD は移植性で勝負していて、ネットワークスループットを高く保つことに多くの時間を費やしている感じではない
どの BSD も総じて変化がずっと少なく、長所短所はあるが、統合対象のプラットフォームとしてはより良いと思う
ソフトウェアの一覧もはるかに大きく、現代的なデスクトップの日常利用 OS としても使える。他の2つについてはそうは言いにくい
なぜ Linux ではないのかと言えば、私は Linux を望んでいない。企業の利害にあまりにも押しつぶされている