JFSまたはXFSまたは他の何か？
サーバーでボリュームマネージャーとしてLVM2を使用することを決定した後、オンラインでサイズ変更可能なファイルシステムも必要でした。いくつかの記事を読んだ後、XFSを優先してJFSを使用することにしました。
今日、オフィスサーバーで停電が発生し、JFSボリューム上の1つのファイルが完全に破損していることがわかりました。これが発生する可能性がありますが、システムは、電源障害後の起動中にファイルシステムの問題を示さないことで、すべてが大丈夫だと信じ込ませました。ジャーナルを再生した後、すべてのファイルシステムはクリーンでした。
これは私に悪い味を残します。停電後にうまく回復しないファイルシステムは必要ありませんが、問題がある可能性があることを通知しないファイルシステムは本当に必要ありません。
それで、私はそれを試してみて、どのファイルシステムが好きか尋ねると思いました。どちらが好きですか、そしてその理由は何ですか？私は次の機能を探しています：
- 壮健
- オンラインで成長可能
- 通常のワークロードで良好なパフォーマンス（通常のファイルサイズ-何百万もの小さなファイルなどの特別なものはありません）
- centOS 5.4ディストリビューションで利用可能ですが、それはオプションです
また、JFSを使用したことがあり、悪い経験をしたことがあるかどうかも知りたいです。もちろん、JFSを使用したサクセスストーリーもあります。そして最終的には、JFSよりもXFSを好むのか、またはその逆を好むのか（特定のワークロードではなく、日常の使用について述べたように）
XFS。
JFSは基本的に死んでいる/維持されていない。
現在、ほとんど/すべてのXFS開発者はRedhatで作業しており、XFSのカーネルサポートはRHEL5.4ですぐに利用できます。
ジャーナルを再生するということは、メタデータがクリーンな状態に戻ることを意味します。データ自体を保証するものではありません。これは、ジャーナリングファイルシステム、少なくともCOW（Copy On Write）のような他のトリックも実行しないすべてのファイルシステムに当てはまります。したがって、選択したファイルシステムに関係なく、サーバーが不潔にシャットダウンされると、このようなデータ破損の可能性があります。あなたのファイルシステムはその仕事をし、データの損失/破損を最小限に抑えてファイルシステムをクリーンな状態に戻すことができました。
したがって、これから学んだ教訓は、バッテリーが少なくなったときにサーバーをクリーンにシャットダウンするようにサーバーに指示できるUPS上にサーバーを常に配置することです。そして、常に適切なバックアップをとってください。
データの整合性が本当に心配な場合は、OpenSolarisやBSD上のZFSなどのより堅牢なファイルシステムに移行する必要があります。これは、現時点で私が知っている唯一の製品対応の無料ソリューションです。 Linux上のBTRFSは、成熟してテストされれば、数年以内にまともなソリューションになるでしょう。ただし、現時点では、実稼働環境での使用はお勧めしません。これらのより堅牢なファイルシステムでさえ、バックアップの代わりにはなりません。
上記の「敗者」の中に、JFSをあきらめる前にfsckを使ってみた人はいないでしょうか。 JFS @ Linuxにはカーネル組み込みのジャーナル回復コードがないため、そのために適切なユーザースペースツールを使用する必要があります。
標準のLinuxext3ファイルシステムはオンライン拡張をサポートし、他の要件も満たしています。他に特別なニーズがない限り、それは本当に正しい答えです。 XFSは長い歴史と評判がありますが、それを使用すると特別なケースに陥ります。これは問題ありませんが、複雑さが増すという固有のコストが伴います。なぜ、不要なものに「支払う」のでしょうか。
ここでブラッドと同じ経験。
JFSは、パフォーマンスと機能の面で非常に優れていましたが、強制シャットダウン後に3パーティション分のデータが失われました。
したがって、私はJFSをビンに入れ、将来XFSを使用します（Linux上のZFSとBTRFSを待ちます）。
大規模なプロの環境でJFSを使用しましたが、やけどを負いました。すぐには表示されない大規模な破損の問題。クリーンな再起動だけですべてのファイルがlost + foundになる場合があります。
XFSに切り替え、振り返ることはありませんでした。何百ものマルチテラバイトシステムで5年間使用しています。