如果 Linux 停止响应，人们可能会被迫进行不正常的关闭，在这种情况下，人们可能会在不知不觉中关闭电源。我读到，如果可能的话，您应该尝试使用 ctrl+prntSc + R +E +I + S+ U+ B 对 Linux 进行软重置，因为突然关闭电源可能会损坏文件系统。具体细节是什么？在这种情况下，Linux 的弹性是否不如 MS-Windows？
答案1
我认为Ctrl+PrtScr不会做太多，你需要的是SysRq（通常在与 相同的物理键上PrtScr，通过按住该键来访问Alt，因此，有点不清楚“神奇”组合是否实际上是SysRq+<letter>或Alt+SysRq+<letter>）。
该B函数将boot系统，所以你的组合是浪费时间，只能B完成，并且仅仅启动与电源循环一样糟糕。
（有时）可以通过以下方式获得什么SysRq+R,E,I,S,U,B（对我来说，+这表明您需要一次按下所有键，并且一次按下八个键很困难，而不是您想要做的事情 - 请注意，“BUSIER”实际上是经典组合完全向后），是一种更好的关闭方式，其中尽可能多的数据被很好地写入磁盘，因此下次启动时不需要 fsck，并且数据丢失的风险被最小化。
有很多信息，包括 SysRq 组合的完整列表和一些助记符Magic SysRq 的维基百科页面。
答案2
具体细节是什么？在这种情况下，Linux 的弹性是否不如 MS-Windows？
在某个时刻进行比较可能会很有用。这种比较可能解释了为什么这些 SysRQ 命令如此众所周知。但它不适用于比较最新的 Linux 和 Windows 版本。
如果您理解“日志文件系统”的含义，那么详细信息将得到很大程度的解释。 示例参考。
根据该参考文献，最受欢迎的Linux 文件系统系列获得日志文件系统支持的时间晚于 Microsoft。
此外，普遍的理解是 Linux 文件系统仍然能够使用 很好地恢复fsck，问题是fsck在较大的磁盘上需要很长时间，因此日志记录更多的是一种优化。
考虑到这在现代大型磁盘上需要多长时间，日志记录变得更加“有弹性”是毫无疑问的:-)。原则上，无论日志文件系统如何，同步也可能有一些用处。它允许您触发立即写回，其中包括任何未同步的文件内容。 （然后您必须观察磁盘 LED 或噪音来猜测写回何时完成）。这避免了例如必须等待dirty_writeback_centisecsext 文件系统。有些人甚至将他们的系统配置为使用“笔记本电脑模式”其中惰性写回被无限期地延迟以节省电量。
还有一个额外的细节。 Linux 上的日志文件系统倾向于假设它们不是在barriers禁用的情况下运行的。屏障对性能的影响已得到缓解，Linux 发行版已停止默认禁用屏障。 （或者，在某些情况下和在某些硬件上禁用屏障可能是“安全的”，但这不适用于截至 2018 年的普通 PC 硬件。Redhat 已停止建议在此类硬件上禁用屏障）。示例参考。
引号（一些格式 - 有用的链接 - 已丢失）：
日志文件系统
更新文件系统以反映文件和目录的更改通常需要许多单独的写入操作。这使得写入之间可能发生中断（例如电源故障或系统崩溃），从而使数据结构处于无效的中间状态。[1]
例如，删除 Unix 文件系统上的文件涉及三个步骤：[5]
- 删除其目录条目。
- 将索引节点释放到空闲索引节点池中。
- 将所有使用过的块返回到空闲磁盘块池。
如果在步骤 1 之后和步骤 2 之前发生崩溃，则会出现孤立 inode，从而导致存储泄漏。另一方面，如果在崩溃之前仅先执行步骤 2，则尚未删除的文件将被标记为空闲，并且可能会被其他内容覆盖。
检测此类不一致并从中恢复通常需要完整地了解其数据结构，例如通过 fsck（文件系统检查器）等工具。 [2]这通常必须在下次安装文件系统以进行读写访问之前完成。如果文件系统很大并且 I/O 带宽相对较小，则可能会花费很长时间，并且如果它阻止系统的其余部分恢复联机，则会导致更长的停机时间。
为了防止这种情况，日志文件系统分配一个特殊区域——日志——在其中记录它将提前进行的更改。崩溃后，恢复只需从文件系统读取日志并重播该日志中的更改，直到文件系统再次保持一致。因此，这些更改被认为是原子的（不可整除），因为它们要么成功（最初成功或在恢复期间完全重播），要么根本不重播（被跳过，因为它们在之前尚未完全写入日志）发生崩溃）。
障碍
为了降低断电期间数据损坏的风险，一些存储设备使用电池支持的写入缓存。通常，高端阵列和一些硬件控制器使用电池供电的写入缓存。然而，由于缓存的易失性对内核来说是不可见的，因此红帽企业 Linux 6 默认在所有受支持的日志文件系统上启用写屏障。
对于具有非易失性、电池供电写入缓存的设备以及禁用写入缓存的设备，您可以在装载时使用 -o nobarrier 选项安全地禁用写入屏障。然而，有些设备不支持写屏障；此类设备会将错误消息记录到 /var/log/messages（请参阅表 22.1，“每个文件系统的写入屏障错误消息”）。
[...]
笔记
红帽企业 Linux 6 中不再建议使用 nobarrier，因为写屏障对性能的负面影响可以忽略不计（大约 3%）。写屏障的好处通常超过禁用它们的性能好处。此外，nobarrier 选项绝对不能用于虚拟机上配置的存储。