重新啟動/關機時，核心會確保文件系統處於乾淨狀態嗎？
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL)syscall 究竟對文件系統做了什麼？我知道一些仍然記憶體在記憶體中的數據會失去，但是如果我之前從未呼叫過
umount()（或 umount 失敗）reboot()，是否有可能我最終得到一個不能mount()直接再次作為 rw 的損壞的文件系統？我知道這取決於文件系統類型，所以我想了解更多關於日誌文件系統和更簡單文件系統（如 ext2）的詳細資訊。
解除安裝文件系統將同步所有相關的記憶體記憶體數據。reboot() 呼叫可能會失去數據，這正是因為它沒有完全解除安裝文件系統。（lennart 對此很討厭 :-)。
但是，如果文件系統不使用日誌（或等效），我只會將其稱為“損壞”。除了這種情況，例如 ext4/xfs/btrfs 應該使用日誌 100% 可靠地修復。這可以（並且是）自動執行。與全面檢查/修復不同，它不涉及掃描整個文件系統，因此非常快。除非您有大量未同步的元數據更改需要整理。
您可以在此處查看來自 ext4 的一些範例消息：Does “recovering journal” proof an unclean shutdown/unmount?
在連結的範例中，似乎
fsck.ext4恢復了日誌。但是，我認為核心也可以在掛載文件系統時自動恢復 ext4 日誌。對於 xfs/btrfs，fsck從不做任何事情（參見相關man頁面），所以它總是由核心處理。相比之下，
ext2沒有期刊。fsck.ext2有很好的聲譽，但據我了解，它並沒有涵蓋日記可以涵蓋的所有可能情況。它最終可能會失去文件名並將其內容放入lost+found目錄中。或者正確的修復可能不是 100% 明確的，因此在應用其最佳猜測之前需要詢問使用者許可。以上假設您的儲存設備滿足文件系統的期望。例如，有一個關於電源故障會中斷寫入操作的已知案例：某些 SD 卡式儲存可能會失去整個 128KB 快閃記憶體擦除塊，其中包含您正在寫入的磁碟塊（例如 4KB）。上述文件系統並非旨在避免此類數據失去:-)。