システムコールはファイルシステムでどのように機能しますかreboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL)？
まだメモリにキャッシュされているデータの一部が失われていることを理解していますが、以前umount()にそのデータを呼び出さなかった場合、またはマウント解除に失敗した場合、再直接接続できない破損しreboot()たファイルシステムが発生する可能性はありますか？mount()
私はこれがファイルシステムの種類によって異なることを知っているので、ジャーナリングファイルシステムやext2などのより簡単なファイルシステムについてもっと知りたいです。
ベストアンサー1
ファイルシステムをアンマウントすると、関連するすべてのメモリキャッシュデータが同期されます。 restart（）呼び出しはファイルシステムを完全にアンマウントしないため、データが失われる可能性があります。 (lennartはこれに満足していません:-).
ただし、ファイルシステムがジャーナリング（またはそれに対応する機能）を使用していない場合にのみ「破損」と呼びます。さらに、ext4/xfs/btrfs はログを使用して 100% 安定して変更する必要があります。これは自動的に発生する可能性があります。フルスキャン/リカバリとは異なり、ファイルシステム全体をスキャンしないため、非常に高速です。一つ持っていない限りたくさんソートする必要がある同期されていないメタデータの変更。
ここでは、ext4のいくつかのサンプルメッセージを見ることができます。「回復ログ」は異常終了/削除を証明しますか？
リンクされた例では、fsck.ext4ログが復元されたように見えます。しかし、私は考えるカーネルは、ファイルシステムのマウント時に自動的にext4ログを復元することもできます。 xfs / btrfsの場合、fsck何もしないので（関連manページを参照）、常にカーネルによって処理されます。
それに比べてext2日記はありません。 fsck.ext2良い評判を持っていますが、私が知っているのは日記ができるすべての状況に対処することはできません。最終的にファイル名が失われ、その内容がlost+foundディレクトリに保存される可能性があります。または、正しい修正が100％明確ではない可能性があるため、最良の推測を適用する前にユーザー権限を要求する必要があります。
上記は、記憶装置がファイルシステムの期待を満たしていると仮定する。例えば、書き込み動作を中断する停電に関連する既知の状況がある。一部のSDカードベースのストレージでは、書き込んだディスクブロック（4KBなど）を含む128KBフラッシュ消去ブロック全体が失われる可能性があります。上記のファイルシステムは、この種のデータ損失に耐えるように設計されていません:-).