…今のところね。Linuxの方針は、外部モジュールやドライバーには全く関心がないから、もしbcachefsが必要とするものを削除し始めたら、また痛い目に戻ることになるよ。（例外を作ることがあれば別だけど、ZFSにはそんな例外はないし。）

でも、DKMSの使用を妨げる変更が合理的だったら、bcachefsとは無関係にマージされてたんじゃないかな？もっとドラマや混乱も少なかったかもね？雲の中に銀の裏地がないとは言わないけど、結果が関わってる誰にとっても中立（ましてやポジティブ）とは思えないよ。

これがメインラインから削除された理由なの？

不安定だから削除されたわけじゃなくて、メンテナが他人が定めたガイドラインを尊重できなかったからだよ。これが問題になったのは初めてじゃないし、そのメンテナは以前から行動を変える意志を見せてないし。

何と比べてもっと安定してるの？俺は古いHDDとちょっと怪しいPCI-SATA拡張カードで構成されたマルチデバイスファイルシステムを使ってるんだ。これ、2019年に組み立てたもので、書き込み不可の時期もあったけど、今も動いてるしデータも失ってないよ。5年以上経って、いろんなFSのバージョンアップやデバイスの交換もあったけど、データの避難や再複製もしたんだ。[1] 技術的には、壊れかけのデバイスがゴミを書き込むようになって、我慢できずに破壊的なfsck（fix_errors付き）を実行した時にいくつか失ったけどね。ほかのソリューションと比べるつもりはないけど、これだけでもすごいと思うよ。

もっと安定したら、また戻ってきてほしいな。うん、俺もそう思う。 > ZFSの代わりにカーネル内で使える選択肢があれば最高だね。そうだね。 > パリティRAID用に。いや、それは違うよ。パレートの法則を考えてみて。80%の人は機能の20%しか使わないんだ。でも、みんなが同じ20%を使うわけじゃないから、全体としては80%の機能が必要なんだよ…それ以上もね。ZFSはその競合の一つだし、Btrfsもそう。Stratisも、HAMMER2も、MDRAIDも、LVMもそう。みんなその20%の一部または全部を提供していて、長所と短所がある。要するに、ZFSはRAIDに優れていて、MDRAIDや他のものよりずっと簡単なんだ。Btrfsもそれができるけど、ZFSとBtrfsはCOWスナップショットもできる。それも重要なんだ。OpenSUSEやGaruda Linux、siductionなどはBtrfsのCOWに依存してる。まあ、いいけど、君の使い方はRAIDなんだね。俺もそれを使うよ。いいね。でもCOWも同じくらい重要なんだ。整合性も同じくらい重要で、Btrfsはそれに失敗してる。それがBcachefsのスローガン「データを食べないCOWファイルシステム」なんだ。Btrfsは4年間で年に2〜3回、俺のデータを食べた。称賛する人がどれだけいても、重要なのは失敗した被害者たちなんだ。彼らがそれが失敗することを証明してる。ポイントは「mdraidでext4を使える」とか「LVM2でできる」とか「Btrfsは俺には問題ない」じゃなくて、_これらすべて_をできて、_より良く_できるものなんだ。ここでの「より良く」は「より簡単に」という意味も含む。ここでの簡単さは「設定が簡単」だけでなく、「実装が簡単」という意味もあるんだ（例えば、LVM2上のBtrfsやmdraid上のBtrfs、mdraid上のLVM、RAID上のLVMのext4などと比べて）。全体のスタックの層を取り除いて同じ機能を残せるものは価値がある。設定ステップの90%を取り除いて同じ機能を残せるものは重要なんだ…だって、いろんな人がそのステップを違う順番でやったり、いくつかをスキップしたりするから、それを文書化する必要があるんだけど、誰も十分に文書化してないからね。RAID上のLVMのリカバリステップは、LVM上のRAIDとは全然違う。mdraid上のBtrfsのリカバリは、ただのBtrfs RAIDとは全然違う。だから、これを排除するツールが重要なんだ。1 - 2 - 3 - 4 - 5と1 - 2 - 4 - 3 - 5のどちらが重要かが問題になるから。ここでのゴルディウスの結び目を切る剣は、1-5を一度のステップで実行できるツールなんだ。たとえ1と5、または2と3だけを使っても、4だけをやっても、それはまだ重要なんだ。

俺も戻ってくることを願ってるけど、ケントがリードデベロッパーじゃないことを願ってる。

あのベンチマークはおかしかったね。bcachefsだけが512bのブロックサイズを使ってるのに気づいた？それがオーバーヘッドを大きくしちゃうんだよ。

あのベンチマークを真剣に受け止めるのは難しいね。ZFSやbtrfs、そして多分bcachefs（使ったことないから意見はないけど）は、XFSやEXT4ができないことをやってるんだ。ZFSについては他より詳しいけど、ここではZFSがashift=9か12かは指定されてなかった。自動検出を試みるけど、それがうまくいかないこともある。ashift=9だと、ZFSは512バイトで物理I/Oを行っていることになるから、nvmeのエミュレーションモードになる。もしかしたらashift=12かもしれないけど、分からない。次に、ZFSはデフォルトで128kのレコードサイズを持ってる。大きなファイルを書いたら、128kサイズの「チャンク」で書かれるんだ。それから4kのブロックサイズでランダムな読み書きI/Oベンチマークを実行すると、ZFSは毎回4kのI/Oに対して128kを読み書きすることになる。これは大きな増幅係数だよ。もしZFSをランダムブロックI/Oに似た負荷で使うなら、アプリのI/Oに合わせてrecordsizeを調整した方がいい。ZFSはこれを簡単にしてくれるし、子ファイルシステムの作成は非常に安価で、ファイルシステムごとにrecordsizeを調整できるんだ。それに、ZFSがやることはXFSやEXT4ができないこともある。例えば、5分ごとにスナップショットを取ること（ほぼ無料）、ストリーミング増分スナップショットバックアップ、スナップショットのクローン作成など、RAIDの柔軟性に入る前に。

https://www.phoronix.com/review/bcachefs-617-dkms/2 にはdkmsモジュールのベンチマークが載ってるよ。

DKMSパッケージが整ったら、エンドユーザーにとってはほとんど変わらないはずだ それって、セキュアブートを使ってる全ての作業用ワークステーションでMOKキーを登録しなきゃいけないってこと？そうなると、200台以上のマシンで大変なことになるよ。NVIDIAドライバーの時と同じで、自動化できないし。

btrfsはどう？君が探している条件をすべて満たしているように見えるし、主要なLinuxディストリビューションではデフォルトのファイルシステムとして使われているくらい成熟してるよ。

自分もPatreonのサポーターだけど、bcachefsがカーネルに統合されるまで意図的に切り替えなかったよ。結局、リーナスがユーザースペースを壊すことはないよね？この騒動には自分もイライラしてるけど、資金提供はやめないつもり。bcachefsはbtrfsのしっかりした代替手段だからね。何が本当に起こったのか、ドラマの原因が全然わからない。機能的なものが含まれたPRがあって、それが原因でモジュールがカーネルから排除されたの？でも、DKMSがそんなにひどい解決策でないことを願ってる。これがあると、ブートが壊れるから。Linuxカーネルには安定したモジュールAPIが必要だと思う。bcachefsのような外部モジュールが信頼性を持ってブートできないのは困るよね。

「本当にLinuxにはネイティブでモダンなCOWファイルシステムが欲しかった」 btrfsはその説明に合わない？問題がいくつかあるのは知ってるけど、確かにネイティブなCOWファイルシステムだし、私の知る限りでは「モダン」だよ。

「本当にLinuxにはネイティブでモダンなCOWファイルシステムが欲しかった」 btrfsはダメなの？（正直な質問。）