うわ、ZFSやDKMSの面倒から解放されて楽しんでたのに、今度はbcachefsも同じ状況になりそうだね。DKMSのトラブルや時々の不具合に対処するか、どんどん古くなるカーネルバージョンに留まるかって感じ。 君のディストロは、希望があればbcachefsを簡単に含められるんじゃない？ZFSとLinuxの状況はほとんどLinuxの宗教的なこだわりが暴走してると思うけど、その特有の問題はbcachefsにはないんじゃない？bcachefsの問題はbtrfsの問題でもある。結局、bcachefsはZFSがすでに解決している問題を解決するためにはほとんど機能していないんだよね。

参考までに、DKMSだけがアウトオブツリーのモジュールを配布する方法じゃないよ。https://github.com/chimera-linux/ckms

記事によると、bcachefsはメインラインカーネルから削除されないみたい。これは主に、Linusや他のカーネル開発者がKentと直接やり取りしなくて済むようにするための対策っぽいね。

btrfsは6.1以前のカーネルではマルチディスク環境では使えなかった。そこからは試してないけど、今のbtrfsはそういう環境で安定してるの？あと、https://www.phoronix.com/news/Josef-Bacik-Leaves-Metaも見てみて。

最近、いろんな関係者の間で摩擦があったから、この最新のニュースはその決定の直接的な結果じゃないと思うよ。例えば、これを見てみて：https://news.ycombinator.com/item?id=44464396

カーネル開発だけじゃないよね。lwnのスレッドでも、Debianの開発者たちとのやり取りが難しいって言ってたし。俺の意見だけど、彼のコミュニケーションからは、他のプロジェクトが彼の仕事を含んでいても、焦点や優先事項、方針が彼のプロジェクトとは違うって認めたくない感じがする。さらに、他のケースでは例外が認められてるから、自分のケースでも例外を期待してるみたい。俺は、彼が発表用のメーリングリストで別に開発した方がいいと思う。緊急の変更があったら、そのリストに送信して、他の関係者がその変更をカーネルやディストリビューションに取り込むプロセスを整理すればいい。もし他の人が配布した古いバージョンからバグレポートを持ってきたら、最新のバージョンを彼のリポジトリからどうやって入手するか教えてあげて、ディストリビューターにも優しく促してあげればいい。そうなると、ユーザーは古いバージョンを使うことになって、修正がすぐには来ないけど、今のやり方だってユーザーにすぐ修正を届けることはできてないからね。

ケントは間違ってると思うけど、リーナス以下のカーネルの人たちが問題を説明できないのは本当に助けにならないよね。代わりに遊び場の罵倒に走っちゃってるし。プロフェッショナルじゃないし、敵対的な作業環境を作るだけで、ケントの行動がなぜ問題なのかを伝えられてないから、彼がそれを信じられないのも少し同情する。

このシーンの外部者として見ると、スレッド全体が全然違って見える。ケントは自分の立場（他の人が彼のコードにバグを入れることから来るフラストレーション）を説明するのにとても忍耐強いし、カーネルやDebianの人たちは、彼が見ているプロセスの本当の問題に対して返答するのではなく、悪口を言ってるだけに見える。ユーザーparavoidが引用してる部分は、俺の意見では文脈を無視してると思う（提供されたリンクを読んで判断した結果）。もっと歴史があるかもしれないけど、そのスレッドを見た限りでは、悪者に見えるのはケントじゃないね。

自閉症は時々、すごく社会的な障害だよね。

彼はユーザーの報告に過剰に反応してると思う。誰かが来ると、データ損失の危機にあるからね。だから、すべてをできるだけバグフリーにしようと必死になってるし、違う視点の人たちが修正を早く広めないことにイライラしてる。ディストロが名前を変えるために軽くフォークして（IceWeaselスタイル）、サポートリクエストが彼に届かないようにするのが助けになるかも…でも、多分無理だろうね。結局、データを取り戻したいからみんなそこに行くし。

これはBTRFSじゃないよ。

Suse Linux EnterpriseはまだBtrfsをルートファイルシステムとして使ってるから、そんなに悪くはないんじゃない？クリス・メイソンは最近何をしてるんだろう？ちょっとググってみたけど、「rsched」っていうツールに取り組んでるみたいだね。

俺はZFS使ってるよ。Canonicalが提供してるし、個人のマシンにはそれで十分だね。

まさにZFS-on-linuxがあって、すごくうまく動いてるよ。LinusがZFSについて何度も間違ったことを言ってるけど、彼がそれを使ったことも、機能や特徴を調べることも全然してないのが明らかだね。 https://zfsonlinux.org/

俺もそういう状況だよ。リビングの隅にあるSynologyのユニットを見ながら、これがここにいる最後のユニットになるんだろうなって思ってる。代わりのものがどんな感じになるのか気になる。FreeBSDにはお世話になってるし、そろそろ再会する時期かもね。

やってみて！俺は約10年前に切り替えたけど、全然後悔してないよ。ZFSの統合が一流で、しっかりしてる。データを何度も守ってくれたからね。

ZFSをほぼファーストクラスの市民として扱ってるLinuxディストロもあるよ。NixOSがその一つで、Alpineもそうだと思う。

FreeBSDは、サードパーティのパッケージも含めて、すごく簡単にアップデートできるよ。特別な理由がない限り、LinuxよりFreeBSDを選ぶべきだと思う。

ちなみに、俺はbtrfsでNASを運用してる（mdadm RAIDの上に、btrfs RAIDは完全には信頼してないし、リカバリツールもひどいみたいだから）。今のところうまく動いてるよ。スナップショットを簡単に取れるのが本当にいい。毎時スナップショットを作って最新のN個を保持するスクリプトがあって、これで俺のやらかすペブカックエラーから守ってる。ただ、定期的にbtrfs以外のストレージにバックアップもしてる。結局バックアップは必要だから、リスクを減らす簡単な方法だと思ったんだ。

いや、問題はルールに従わなかったことじゃないよ。今の対立を引き起こしたのは「journal_rewind」パッチで、最近（6.15）最悪のバグが発生したんだ。サブボリュームが全部消えちゃうっていう。3回目の報告で、デバッグに必要なメタデータダンプをもらえて、ほんと助かった。今はこういうバグが二度と起こらないように、かなりの強化をしたよ。それから新しい修復コードを書いて、バグに影響を受けた3人目のユーザーのファイルシステムを完全に復元した（最初の2人はバックアップがあったからね）。そしたらLinusがキレちゃって、プルリクエストに「機能」として載ってたから。元のバグに影響を受けたユーザーが知っておくべきだと思ってそうしただけなのに。データを維持できないのはファイルシステムのバグで、修復コードはバグフィックスだよ。プライベートなメンテナンススレッドでも、公の場でも、LinusとTedが「どのbcachefsパッチが回帰リスクか知ってる」とか言って完全に話が逸れちゃった。Linusが俺の判断を信じてないって1ページ半も愚痴ってたし、もっと色々あった。バグフィックスに関してはこういう議論が何度も繰り返されてる。で、その後、他のサブシステムのプルリクエストを見てみたら、実は俺がクリティカルなバグフィックスを考えるのが他のサブシステムよりも保守的だったみたい。bcachefsで普通じゃないのはバグフィックスの量だけで、これは新しいファイルシステムが急速に安定して、ユーザーのバグ報告を閉じていくのに期待されることだよ。だから、仲介者がいても何も解決しないと思う。

それくらい良いよ。

ノートパソコンとRaspberry Piには使ったけど、あんまり気にしてなかったんだ。KentとIRCで問題を解決できたのは良かったし、彼が実際に手伝ってくれるときはすごく助かるけど、bcachefsにはまだまだ課題があるって気づいた。バスファクター1は長期的には避けたいなって思った。

みんな自分たちが違うって分かってるけど、もしbcachefsが出たら、btrfsが唯一のモダンなインツリーファイルシステムになるよね。でも、どうやら重要なデータを預けるのは信頼できないみたい。