系统调用对文件系统到底做了什么reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL)？
我知道一些仍然缓存在内存中的数据将会丢失，但是如果我umount()之前从未调用（或卸载失败）reboot()，是否有可能我最终会得到一个损坏的文件系统，无法mount()直接再次作为 rw ？
我知道这是文件系统类型相关的，所以我想了解有关日志文件系统和更简单的文件系统（如 ext2）的更多详细信息。
答案1
卸载文件系统将同步所有关联的内存缓存数据。 restart() 调用可能会丢失数据，正是因为它没有干净地卸载文件系统。 （lennart 对此很不满:-)。
但是，如果文件系统不使用日志（或同等功能），我只会将其称为“损坏”。除此之外，例如 ext4/xfs/btrfs 应该使用日志 100% 可靠地修复。这可以（并且确实）自动执行。与完整检查/修复不同，它不涉及扫描整个文件系统，因此速度非常快。除非你有一个很多需要整理的未同步元数据更改。
您可以在此处查看来自 ext4 的一些示例消息：“恢复日志”是否证明是不干净的关闭/卸载？
在链接的示例中，似乎fsck.ext4恢复了日志。但是，我思考当安装文件系统时，内核还可以自动恢复 ext4 日志。对于 xfs/btrfs，fsck从不执行任何操作（请参阅相关man页面），因此它始终由内核处理。
相比之下，ext2没有日记。 fsck.ext2具有良好的声誉，但据我了解，它并不能涵盖日记可以涵盖的所有可能情况。它最终可能会丢失文件名并将其内容放入lost+found目录中。或者正确的修复可能不是 100% 明确，因此在应用最佳猜测之前需要征求用户许可。
上述假设您的存储设备满足文件系统的期望。例如，有一个已知的情况，涉及中断写入操作的电源故障：某些 SD 卡式存储可能会丢失整个 128KB 闪存擦除块，其中包含您正在写入的磁盘块（例如 4KB）。上述文件系统的设计不能承受此类数据丢失:-)。
答案2
迂腐地说，不。重启和关机事件是用户空间概念，而不是内核概念。在大多数现代 Linux 发行版上，正常关机或重新启动是由 systemd 处理的。它也是用户空间工具，用于在启动时检查文件系统，并在文件系统处于可用状态时安装它们。
是的，文件系统驱动程序实现日志记录以保持文件系统的一致性，即使在非正常关闭或重新启动的情况下也是如此。
是的，内核提供了 API，用户空间工具可以通过该 API 检查和管理文件系统。