web-dev-qa-db-ja.com

起動時にfsckを無効にしても安全ですか?

サーバーを再起動すると、fsckが単独で実行されることがありますが、ほとんどの場合は実行されません。しかし、実行すると、終了するのに時間がかかりすぎます。これを永続的に無効にしても安全ですか?

4
IMB

これが本番サーバーの場合、起動時にfsckの自動的にスケジュールされたチェックを無効にすることはお勧めできません。

fsckは、Mマウント後またはN日後のいずれか早い方で、起動時に自動的に実行されます。 tune2fs を使用してこのスケジュールを調整できます。

自動チェックを有効のままにしておくことをお勧めしますが、必要に応じてtune2fsを使用してチェックスケジュールを調整し、都合のよいときにfsckを強制的に実行します。

Fsckが実行されると、Mount count0にリセットされ、Last checkedフィールドが更新され、次の自動チェックが効果的に再スケジュールされます。

fsckを手動で実行したくないが、次にスケジュールされた再起動時に便利であることがわかっている場合は、 次回の起動時にfsckを強制する

ルートファイルシステムのルートに空の「forcefsck」ファイルを作成することで、システムにfsckを実行させることができます。つまり、/ etc/fstabの6列目に0または何も指定されていないtouch/forcefsckファイルシステムはチェックされません。

fsckが次回の起動時に実行されるかどうかを確認します

Ext2、ext3、ext4で使用できます

dumpe2fs -h /dev/diskname

4
rob

私はしません。 fsckを定期的に手動で実行し、完全なジャーナリングファイルシステムを使用するポリシーがある場合は無効にできますが、それ以外の場合は、ファイルシステムの長期的な正常性にとって重要です。ブートチェックを無効にすると、ジャーナルがダーティとしてマークされている場合にのみfsckが自動的に実行されますが、不良セクタチェックなどは実行されず、まだ記録されていないファイルシステムの問題を手動で検索しません。

1
Frank Thomas

「ノーノーノー」の答えをいくつかの新しいアイデアで補完できることをうれしく思います。

サーバーの重要性によって異なります。

それが非常に重要である場合(たとえば、あなたの仕事はそれに依存しています):あなたが修正したいことはあなたの問題ではありません。あなたの問題は遅いfsckではなく、頻繁な再起動です。これはあなたが修正すべきものです。

それがそれほど重要でない場合:先に進んでください!再起動がクリーンな場合(常にクリーンなシャットダウンがあります)、ファイルシステムエラーが発生する唯一の方法は、重大なカーネルまたはハードウェアのバグです。しかし、それらにはほとんど別の症状もあります(dmesgを参照)。