fast_commitほとんどのext4ファイルシステムであまりにも早くアクティブになったようで、それ以降FSの破損が頻繁に発生しました。私はext4でそのような問題を経験したことがなく、長年にわたって非常に頑丈でした。
e2fsckデータを失うことなく問題を解決することは常に可能であるため、それほど悪いわけではありませんが、起動できないシステムはすぐに役に立ちません。
fast_commit今は無効にしましたが、設定tune2fs -O "^fast_commit" /dev/partitions時に見逃した部分があるかどうか疑問に思います。
これは既知の問題ですか？たとえば、ジャーナルの注文方法を変更してみますか？私はそれを変更していないので、変更したり関係のないものにしない限り、orderedまだデフォルトモードになっているようです。fast_commit
ベストアンサー1
ただ「私も」と言いたかったです。私のシステムにfast_commitを入れて、手動でfsckが必要で、システムが起動しないため、最終的に削除しました。
私考えるfsckがいくつかの不一致を見つけ、fast_commitがその内容をファイルシステムにコミットする機会を得られない場合（停電、クラッシュ、父親が電源ボタンを押してデスクトップを終了することを決定するなど）、fsckは信頼できます。この問題を解決することは問題ではありませんが、fsckはこれらの状況を認識し、これが正常であることを認識するように更新されていないため、「手動でfsckを実行して手動で決定する」状況に入ります。
fast_commitが出たときにそのデザインを見てみると、とても保守的でした。まず、そのコミットを新しいログに書き込み、次に便利なときにファイルシステムに書き込みます。したがって、最悪のシナリオは、完全なファイルシステムの競合とデータの損失ではなく、ファイルシステムの変更の最後の数秒が失われることです。