リンク:
コメント (76)
_________________________________________________
lol、PhoronixがBtrfsの機能じゃなくてBcachefsのドラマについて何かを書くことに成功したみたい。 Re: [GIT PULL] bcachefsの変更について 6.17 - Josef Bacik
「BtrfsがMetaに数十億ドルを節約させた」ってのは、全然技術的な議論じゃない。
そうだね、これは完全に別のトピックに関するメールからの文脈なしの引用に過ぎない。悪い投稿だ。
そうだね。皮肉なことに、Kent Overstreetがbtrfsを攻撃するのと全く同じように、実際の問題はbtrfsじゃない（これがBacikのポイント）。実際の問題はKen Overstreetの行動であって、btrfsやbcachefsじゃない。
_________________________________________________
でも、10年前にデータを失ったランダムなredditユーザーがいるから、もう誰も信頼すべきじゃないよね。
/s
btrfsの問題は、電源喪失にうまく対処できないことだ。
Metaはどこにでも冗長電源のデータセンターがあって、ほとんどのサーバーには冗長電源供給装置がある。
電源喪失を経験すると良くない。
なんで？
理論的には、btrfsは電源喪失イベントに対して安全なんだけど、どうやら多くのドライブはデータの書き込みが完了したと嘘をついているみたい。つまり、電源喪失が起こると、ドライブは以前に保存されたと報告したデータを失ってしまう。
これが私が同じことを尋ねたときに得た説明だ。btrfsは、すべてがドライブ上の良好なデータ構造であることが確認されるまで、最新世代を指すメタデータの更新を待つから、理論的には何も問題が起こらないはずなんだ。でも、なぜか多くのドライブでは実際にはそうじゃない。次のブート時にメタデータが壊れたデータ構造を指してしまう。
おそらく、ドライブはパフォーマンスの理由でこうするんだろうね。書き込みを再配置するために少し作業を集めるためとか。電源喪失時に作業を完了させるために、電源が少し続くように十分なキャパシタを持っているドライブもある。
それがMetaが大規模に使っている理由かもしれない。彼らは電源喪失保護付きのエンタープライズフラッシュを使うべきだし、SANの上に使ったり、ECC RAMを使ったりするだろうし、btrfsがコピーオンライトであることは厳密な利点だ。
理論的には、リモートブロックストレージを使うと、書き込み場所のファイルシステムはより危険になる。SANは、書き込みバリアがないブロックの書き込み順序を保持することを保証しないから、これはext4/xfsに影響するけど、同じセクターに異なるデータを二度書き込まないCoWファイルシステムには影響しない。
ZFSやAPFSにも似たような問題があるんじゃない？両方ともCoWファイルシステムだし。両方とも重要なワークフローで広く使われてる - ZFSはAPFSよりもはるかに複雑な展開シナリオで使われてる。APFSは一般的にAppleがファームウェアを制御するデバイス（スマホやノートパソコンのSSDなど）で使われるけど、APFSもクソみたいなドライブに載せられることがある：USBインターフェースを使った外部ストレージ用の下位バイナリHDD。
俺はBTRFSを使ったことがないけど、FreeBSD 6（今はLinux）以来、NASでZFSを専用に使ってきたけど、過去16年間一度も裏切られたことはない。BTRFSで聞くような「ZFSがデータを食った」話は一度も聞いたことがない。
BTRFSとZFSは補完的だと思う。ZFSはランダム書き込みワークロードをはるかにうまく処理し、多くの状況でより良い/easier LVM+mdraidとしても機能する。
BTRFSは、書き込みが追加されるだけの読み込み重視のワークロードでパフォーマンスが良く、歴史的にoverlayfsやreflinksのサポートが良かったから、ルートファイルシステムとして有用だったけど、今はzfsもそれを持ってる。
アクティブにファイルシステムに書き込んでいるときに電源喪失が起こると、書き込みは部分的に完了していて、システムが再起動するとファイルシステムはその状態から回復しなきゃいけない。
それがどう行われるかはファイルシステムによって異なる。
btrfsは電源喪失イベントからの回復があまり良くなかった。
Metaは単に電源喪失イベントを避けているから、彼らには影響しない。
そうだね、その問題は知ってる。俺の「なんで」は主にbtrfsについてだった（質問があまり具体的じゃなかった）。
俺はbtrfsを使っていて、比較的頻繁に小さな電源喪失（数秒だけどPCをシャットダウンするには十分）を経験してる。btrfsには問題がなかったけど、もうかなりの間nobreakを使ってる。
電源が落ちることが必ずしも死を意味するわけじゃない。
電源喪失中にアクティブに書き込んでいる必要がある。
重要な何かを書き込んでいる必要がある。
回復が難しいポイントで失敗する必要がある。
この3つがなければ、失敗しない。
もし10000人が使っていて、10人のファイルシステムが壊れたら、それは問題だ。
単に運が良かっただけかもしれない。
すべてのファイルシステムは電源喪失のリスクにさらされているが、いくつかは他よりも優れている。
電源が落ちることが必ずしも死を意味するわけじゃない
…
もし10000人が使っていて、10人のファイルシステムが壊れたら、それは問題だ。
そうだね。btrfsを使っている人の数と、その中で文句を言っている人の数を考慮すべきだ。
最近では、btrfsのRAID 5/6を使ったときだけ大きな問題があって、RAID 1の問題は解決されたと思ってた。
btrfsを使っている人の数を考えてみて。Synologyのデフォルトの基盤ファイルシステムだし、Fedora Workstationのデフォルトファイルシステムでもある。OpenSUSEのデフォルトファイルシステムでもある。それは多くのユーザーだ。そして、あまり文句は聞かない。個人的には、Kentがbtrfsの10年前の傷を掘り返して自分を守ろうとしていると思う。
r/kubernetesに同じ視点で行って、btrfsがあまり使われていない理由や、btrfsを使っていたストレージドライブがなぜ移行したのかを尋ねたことがある。悪い経験を持つ人たちがたくさん出てきた。家庭用と企業用のLinuxコミュニティは全然違う。
君は逸話を提供してるだけだね。
家庭用と企業用のLinuxコミュニティは全然違う
そして、ここで他の人たちが主張していたことのほとんどが逆だということを指摘したい。彼らは、Metaがbtrfsで良い経験を持っているのは、企業だから（工業的な強度の稼働時間など）だと主張していた。
すべてが逸話で、または古い話だ。そして、俺の逸話は、RAID 5/6以外ではbtrfsは堅実だということだ。
家庭用と企業用のLinuxコミュニティは全然違う
これは覚えておくべき重要なことだ。家庭用にうまくいくものが企業用にはうまくいかないこともあるし、その逆もある。
Red Hatがbtrfsを全く出荷していないことも指摘する価値がある。Fedoraではデフォルトだけど、彼らはbtrfsが企業向けディストリビューションにとって十分に安定しているとは考えていないから。
Red Hatがbtrfsを全く出荷していないことも指摘する価値がある。Fedoraではデフォルトだけど、彼らはbtrfsが企業向けディストリビューションにとって十分に安定しているとは考えていないから。
それは正確ではない。btrfsはカーネルに含まれていて、RHELで使用できる。ただし、サポートはされていない。
RHELのデフォルトファイルシステムは、スナップショットと信頼性のためにLVM/stratisでバックアップされたXFSだ。後者の2つはRedHatの技術だ。XFSはext4やbtrfsよりも多くのリソースを必要とする。そして、ちなみに、その決定は2017年に行われた。8年前の話だ。
そうだね、RHELの話の一部は、企業環境では大規模なVMの群れを運用することが多く、ハイパーバイザーのレベルでスナップショットを持っていることだ。
そのVMスナップショットは、一貫性の観点からはゴミだと思う（ブロックレベルではホストで一貫しているが、ゲストレベルではそうではない）が、ホストOSがそれを調整してバックアップが中央の場所に行くようにするのは、VM内のゲストファイルシステムを使ってそれを行うよりもはるかに簡単だ。それと、VM内でのLVMの広範な使用とそのCLIへの親しみがあるから、btrfsは簡単な選択肢ではなく、高度な選択肢になる。
VMやKubernetesホストレベル（つまりproxmox）では、企業では通常SANやCephチームがあり、時にはローカルストレージを使用する場合はZFSもある。
もちろん、でもbtrfsの利点の一つは、問題があるときにそれを知らせてくれることだ。静かに失敗するのではなく。これは、ext4がただ失敗するのに対して、btrfsが実際に人々に問題があると知らせているように感じる。データが壊れていることを知らなくても、より信頼できるように見える。
この議論には非常に懐疑的だ。btrfsの災害について不満を持っている人々は、btrfsが問題があると知らせているから不満を持っているわけじゃない。彼らはすべてのファイルを失ったから不満を持っている。もし、すべてのファイルを失うほどの深刻な破損を経験しているなら、そのような事件はファイルシステムに関係なくすぐに気づくはずだ。
btrfsが問題があると知らせているから不満を持っているわけじゃない。彼らはすべてのファイルを失ったから不満を持っている。
それは推測だ。誰かがbtrfsについて不満を持っているのは、1つまたは少数のファイルを失ったからだと想像するのは簡単だ。すべてのファイルである必要はない理由はない。
俺が見たすべての不満は、全体のファイルシステムが失われたと明確に述べている。
書き込んでいるファイルが最初にファイルシステムに保存されていた場合、それが通常の問題であるべきではない。もし、タイムラインスナップショットをアクティブに取っているなら、電源喪失イベントで復元するのは簡単なはずだ。すべてがそこにあるとは期待しないけど、かなりの量がある方が何もないよりはいい。
これって親が話していることと全く同じじゃない？電源喪失の件は、多くの人が情報源なしに引用している噂のように思えるけど、BTRFSが何を保証しているか、電源喪失や他のデータ破損シナリオにどう対処するかについての情報はネット上にたくさんある。特に電源喪失に関するものがある：
Does BTRFS guarantee data consistency on power outages?
As ZFS states exclusively, ZFS is claimed to be invulnerable ZFS accepts that it might be vulnerable to power failures. I couldn't find such a statement for BTRFS. Is it (or designed/planned to be)
電源喪失に非常にうまく対処する。すべてのCoWファイルシステムと同様に。
それが対処できないのは、書き込みバリアを尊重しない壊れたファームウェアを持つドライブだ。これにより、順序が入れ替わった書き込みが発生し、トランザクションのセマンティクスが壊れる。もちろん、電源喪失時にのみ気づく。
俺の経験ではそうじゃない。ハードウェアを冷却電源オフにして（AMDやARM）VMを頻繁にオフにしているが、問題は一度もなかった。
俺も同じだ。Fedoraのインストールを何度も冷却電源オフにしたことがあるが、ロックアップの問題を修正する前にデータ損失の問題はなかった。
それは文字通り意味がわからない。CoWファイルシステムは電源喪失に対して耐性がある。
最近のBtrfsの唯一の本当の問題はRAID5と6だと確信していた。
とにかく、君のコメントから読んだことは、君が言及したすべてがすべてのファイルシステムに当てはまるということだ。
この場合、Btrfsが特別な理由は何だ？XFSやEXT4よりも回復率が低いのか？もしそうなら、どこでそんなデータを得たの？
俺はBtrfsを使っていないけど、考慮したことはあるし、君の情報は非常に興味深い。
実際の主な問題は、成熟していない機能が少し地雷原のようなところだ。正しく使えば非常に安定しているし、ドキュメントが警告している未検証の部分を使うとより危険になる。
記事で引用された話は、特に不変のコンテナに使用することについて話していて、それが強みを発揮する。Btrfsは読み込みと追加が重視されるワークロードに最適だけど、ext4/xfsやzfsに比べてランダム書き込みには遅く、尾書きのレイテンシが高負荷時のスループットボトルネックになる。だから、オーバーレイファイルシステムの基本レイヤーとしては非常に良いユースケースだ。
申し訳ないけど、君のコメントは俺の質問に答えていないし、そもそも君への質問じゃなかった。
最初の段落がこれに答えている：
Btrfsがこの場合特別な理由は何だ？XFSやEXT4よりも回復率が低いのか？もしそうなら、どこでそんなデータを得たの？
それは、現在非推奨とされているRAID 6の実装のような機能のせいで、少し不当な悪評を持っている。btrfsはmdraidを使うように言うのではなく、独自のRAID 6実装を持っているから、他のファイルシステムとは異なる。しかし、RAIDだけでなく、他にも多くの実験的な機能があるが、それを使う必要はない。
いいえ、そうじゃない。君はbtrfsについて一般的に話していた。
俺は特に「この場合」と言って、他の誰かに尋ねたんだ。
彼らはRAID 5/6だけでなく、RAID 5システムのメタデータをRAID 5/6として持つことについても警告している。Arch Wikiでは、RAID 5システムのメタデータにはRAID 1c3を使うように言っている。これで電源喪失の問題を回避できるはずだ。
ソースは？
俺は何度か電源喪失イベントを経験したが、それによる破損はゼロだった。逆に、ext4では何度か電源喪失イベントがあってデータを失ったことがある。
電源喪失を経験すると、メインマシンがバッテリーのあるノートパソコンだから、気づくのに数分かかる。デスクトップを使っていたらUPSを買うだろうし、それはファイルシステムのためではない。
それは真実ではない。btrfsはCOWを無効にしない限り、電源喪失に対して問題ない。
BTRFSが特に問題を抱えているのは、ドライブがデータの書き込みが完了したと主張するが、実際にはまだ書き込みが完了していない場合の全体のファイルシステムの損失だ。
これは多くのドライブに共通のバグだ。
エンタープライズグレードのドライブでは、バッファをフラッシュするために小さな内部電源を持っているため、これが発生することはない。
COWはOSに嘘をつくドライブを修正できない。
BTRFSは個々のファイルを失わないのが非常に得意だが、時には全体のファイルシステムを失うことがある。
ハードウェアがデータの書き込みが完了したと言っているが、実際には書き込まれていない場合、それはbtrfsの問題ではなくハードウェアの問題だ。実際、その場合はCOWのおかげでデータを回復するのが非常に簡単だ。
「ハードウェアがデータの書き込みが完了したと言っているが、実際には書き込まれていない場合、それはbtrfsの問題ではなくハードウェアの問題だ。」
これは、性能仕様を提供したいが安価にしたい予算ドライブの驚くべき数のハードウェアの問題だ。彼らは性能仕様を提供したいが、バッファをクリアするために十分な電源ストレージをドライブに追加しない。
これは至る所にある。
「驚くべき数の予算ドライブ」
証明できる？
この機能の目的はそれを解決することだ。
A Closer Look At SSD Power Loss Protection - Kingston Technology
The combination of firmware/hardware PFAIL protection are a highly effective method for preventing data loss in enterprise SSD applications, allowing important metadata information to be written to flash memory to ensure a successful recovery of the SSD on the next power up.
もしドライブにDRAM書き込みキャッシュがあり、PLPがない場合、それはこの影響を受ける。
修正は多くのキャパシタだ。
btrfsで2回の大きなデータ破損問題を経験したことがある。それらは両方ともハードウェアに関連していた。一つはクソなBIOSがディスクの終わりをBIOSのバックアップで上書きしたもので、もう一つはメモリビットのフリップ（ECC RAMなし）。
ランダムな馬鹿からの質問だけど、スクラブはビットフリップに役立つ？
ビットフリップが発生したタイミングによる。
インデックス内で発生した場合は、いいえ。（俺は21エクサバイトだと主張するツリー内のリンクを持っていて、手動でビットを元に戻して修正し、ファイルシステムをマウントできるようにした。）
データの一部をディスクに書き込む際にビットフリップが発生した場合、スクラブによって回復できるかもしれないが、両方のコピーがフリップしていたら無理だ。
まあ、今の時代にどれだけ安定しているかなんて誰が気にする？
10年以上前の「その人」の経験を無視することはできない。それは失礼だ！
/s
NASでRAID5システムを運用したかった。btrfsのドキュメントにはそれに問題があると書かれていて、お勧めしないと言っていた。だからZFSを使った。
開発者がこのユースケースが完全にサポートされると発表したら、喜んでBtrfsに移行するつもりだ。今は単に優先事項ではないと思うけど、それはもちろん全く問題ない。ファイルシステムを書くのは巨大なタスクで、すべての機能に同じ優先順位があるわけではない。
NASでRAID5システムを運用したかった。btrfsのドキュメントにはそれに問題があると書かれていて、お勧めしないと言っていた。だからZFSを使った。
btrfsは内部RAID5/6をお勧めしないと思う。ZFSを使うのは一つの解決策だ。もう一つはSynologyのアプローチだ。Synologyは基盤ファイルシステムとしてbtrfsをデフォルトにしているが、mdadmの上にbtrfsを使っている。mdadmがRAIDを処理する（標準のRAID5を含むが、SynologyのSHRも含む）が、彼らはbtrfsの信頼性（チェックサム+修復）やスナップショット機能を活用している。
Metaにとってうまくいくなら、それは素晴らしいことだけど、Metaは非常に特定の構成で使っているから、彼らの経験がほとんどのユーザーに適用されるわけではない。
「いくつかのredditユーザーがデータを失った」だけじゃない。俺はbtrfsに賭けて製品に使った会社で働いていた。問題は、btrfsが更新中にいくつかのデバイスを壊したことだった。どれだけパッチをバックポートしても、更新の前にリバランスを行っても、他の何をしても、問題は顧客の中で繰り返し発生した。
Metaは独自のbtrfsのバージョンを使っている。彼らはメインラインを使っていない。メインラインは庶民のためのものだ。
誰でも使えるよ。
Metaはbtrfsのために直接上流カーネルで作業する人を雇っている。彼らはカスタムフォークを運営しているわけではない。
彼らはそうではない。btrfsを使っている人たちがそんなことを言うのは変だ。何かを証明するために嘘をつかなければならないなら、それは真実ではない。
彼らはまだ上流にないパッチを持つカーネルブランチを使っている。CentOSカーネルではない。だから、彼らはほとんどの人が使うのと同じ方法でファイルシステムを実際に使っているわけではない。それが間違っているのはどこ？
すべて。彼らは上流カーネルで作業し、かなりバニラな形でパッケージ化し、CentOS Hyperscale SIGでビルドしている。
最新のメインラインではないが、最近の安定したツリーをベースにしており、バックポートが行われている。時々（テストの後）、ベースが移動する。正確なバージョンは知らないが、バグレポートやパッチで言及されているものからは、常に比較的最近のものだ。メインラインを追い続けることは、他のすべての改善のために良いことだ。FBのエンジニアが維持または開発している他の分野もある。
過去には、上流btrfsに対する大きな変更が、FB内で数ヶ月間テストされた大きなパッチセットとして提供された。上流統合は、ほぼマイナーまたはスタイルのことだけだった。非同期廃棄の例がある。時間が経つにつれていくつかの修正があり、discard=asyncは6.2以降デフォルトになっている。内部で使用されていたzstdが上流に提出された例もある。
_________________________________________________
残念ながら詳細はゼロ。
_________________________________________________
もっと吸って。
_________________________________________________
btrfsはRAID56を使わない限り素晴らしいと思う。Linuxにはカーネル内にCOW RAID56ソリューションが必要だ。btrfsを修正してくれればいいのに。
_________________________________________________
ああ、つまり専門知識や良い意思決定ではなく、ただbtrfsだけってことか。
_________________________________________________
Phoronixがひどい記事を配信したために禁止されていた時代を思い出す。
_________________________________________________
もし彼らがTEMUバージョンの代わりにZFSを使っていたらどうなっていたか想像してみて。
君はLinuxを使っているからといって、技術を理解しているわけではないという生き証人だ。
lol。技術に雇われている。
_________________________________________________
それは悲しい…企業を助けるのか :c
それは企業によって開発されたものだ lol
SUSEだよね？David Sterbaがメイン開発者か、間違ってる？
Oracleがbtrfs（とzfs）を開発した。
OracleはZFSを開発した会社を買収した。
いくつかの会社が大きく貢献していて、https://btrfs.readthedocs.io/en/latest/Contributors.html にリストされている。SUSE、FB/Meta、WDが大部分のパッチを提供していて、Oracleは他の会社に比べて少し少ないが、まだ定期的に貢献している。
君は特定の会社を挙げているが、開発はグループの努力であり、他にも多くの（< 5パッチの）貢献者がいる。メンテナの役割は、Linusに送るすべてを中央集権化し、直列化することで、開発者が開発に集中できるようにすることだ。異なる会社の「戦略」や目標にもかかわらず、うまく機能している。
悪党 :c
_________________________________________________
それは素晴らしい、ザッカーバーグと彼の犯罪者仲間にもっと数十億ドルを。
_________________________________________________
一部の人は、Metaを傷つけるためだけにbtrfsが存在しなければよかったと思っている :P
企業がLinuxを生かしているという主張もできるから、悪いことではない。
それは、君の一部が愚かだということを意味するだけだ。
Facebookは嫌いだが、BTRFSの利点を享受している。