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）。上述文件系统并非旨在避免此类数据丢失:-)。
迂腐，没有。重启和断电事件是用户空间概念，而不是内核概念。在大多数现代 Linux 发行版上，systemd 会处理正常关机或重启。它也是用户空间工具，它在启动时检查文件系统并在它们处于可用状态时挂载它们。
是的，文件系统驱动程序实现日志记录以保持文件系统一致，即使在不正常的关闭或重新启动的情况下也是如此。
是的，内核提供了 API，用户空间工具可以通过该 API 检查和管理文件系统。