男e2fsckが言った。
マウントされたファイルシステムでe2fsckを実行することは通常安全ではありません。唯一の例外は、-c、-l、または-Lオプションなしで-nオプションを指定した場合です。ただし、これが安全であっても、ファイルシステムがマウントされている場合、e2fsckによって印刷された結果は無効です。 e2fsckがマウントされたファイルシステムを確認する必要があるかどうかを尋ねる場合、唯一の正しい答えは「いいえ」です。自分が何をしているのかを知っている専門家だけが、この質問に異なる方法で答えることを検討する必要があります。
ファイルシステムにエラーが発生していること（少なくともext4では）がわかりますjournalctl -k。表面上、Journalctlはdmesgユーティリティによって報告されたのと同じカーネルメッセージを受け取ります。 fsckは各ファイルシステムで異なる動作をしますが、通常は実際のfsログをチェックし、各inode（iirc）でいくつかの異なるエントリを見つけます。 man dmesgの読み込み中に、特別なブロックデバイス/ dev / kmsgと/ proc / kmsgファイルへの言及を見ました。cat /dev/kmsgメッセージを読むことができます。これはjournalctl -kデータを取得したソースと同じですか？これは何の関係ですかe2fsck -n？
答え1
journalctl -kログにカーネルからのメッセージを表示します。dmesgカーネルリングバッファの内容を表示します。両方とも、ファイルシステムドライバのエラーメッセージを含むカーネルのエラーを表示します。
これらのどれもe2fsck.fileシステムログからは出ておらず、.access "log"とは関係ありませんjournalctl。マウントされたファイルシステムで実行すると、ファイルシステムドライバが維持するデータが実行e2fsck時に必ずディスクに配置される必要はなく、実行時に変更される可能性があるため、誤った結果が生じる可能性があります。e2fscke2fsck
答え2
追加の状況に関する注意事項：起動中に、一部構成は、ルートファイルシステムでsystemdコマンドを実行します。fsck読み取り専用でインストールされている場合。の警告によると、man e2fsckこれは理想的ではありません。好ましい設定は、一般的なタスクを実行するinitramfsを使用することです。fsck 今後ルートファイルシステムを完全にマウントします。
（これを説明する既存のQ&Aがありますが台無しです。）
e2fsck -n 読み取り専用でマウントされたファイルシステムで有効な結果を印刷します。
e2fsck外部が-n完全に「安全」であるかどうかは別の問題です。 （安全でない場合、誤った結果が出る危険もあります。）注意してください:-)。しかし、現在行われている作業が以前の世代のsystemdスクリプトよりも「安全性が低い」わけではないことは信頼できると思います。
私の考えでは減らすfsck危険です。変更が必要な場合は、システムをすぐに再起動する必要があることが規則です。