经典情况:我遇到了麻烦rm
,立即意识到我删除了错误的文件。(没有什么紧要关头,我可以容忍最近的备份,但仍然很烦人。)
如果想使用extundelete
此类工具恢复文件,我知道进一步的磁盘活动是我的敌人,所以我立即物理关闭了计算机的电源(即使用电源按钮,而不是使用halt
诸如此类的命令)。这是一台笔记本电脑,没有重要任务在运行,也没有打开任何东西,因此是可以接受的操作。(顺便说一句,从那以后我就知道,在这种情况下要做的第一件事就是首先估计丢失的文件是否仍然可以通过https://unix.stackexchange.com/a/101247进程打开-如果是,则应以这种方式恢复它们,而不是关闭机器电源。)
尽管如此,一旦机器断电,我想了一会儿并认为文件不值得花时间启动实时系统进行适当的取证。所以我重新启动了机器。然后我发现我的文件仍坐在磁盘上:在rm
断电之前,这些文件还没有传播到磁盘上。我跳了一点舞,感谢系统管理员之神的意想不到的宽恕。
现在我的问题是了解这是怎么可能的,以及在将an rm
实际传播到磁盘之前的典型延迟是多少?我知道磁盘IO不会立即刷新,但会在内存中放置一段时间,但是我认为磁盘日志会迅速确保挂起的操作不会完全丢失。https://unix.stackexchange.com/a/78766似乎暗示了一种单独的机制来刷新脏页和刷新日记帐操作,但没有提供足够的详细信息说明日记帐将如何涉及到rm
以及预期的延迟时间操作被刷新。
更多详细信息:数据位于LUKS卷内的ext4分区中,并且在备份计算机时,我在中看到以下内容syslog
:
Sep 24 10:24:58 gamma kernel: [ 11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [ 11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [ 11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
但是我不相信它与rm
。
另一个问题是是否有一种方法可以告诉内核不执行任何未决的磁盘操作(而是将其转储到某个地方),而不是关闭计算机电源。(当然,不执行挂起的操作听起来很危险,但是无论如何关闭机器电源,都会发生这种情况,并且在某些情况下可以节省您的时间。)这当然会“更清洁”,也很有趣例如,对于那些不易关闭物理电源的远程服务器。
rm
写时间的宽限期的相关机制?换句话说,只有在即将执行写操作时,事情才会提交给日志?还是图片比这更复杂?至于alt-sysrq-u,这是一个很不错的主意。您是否对“似乎”索赔有参考意见?(您提供的链接似乎没有遵循它。)谢谢!:)