共 3 篇相关文章
这篇讲的是当磁盘利用率飙到100%、程序变卡时，如何揪出背后的“元凶”文件。作者从实际场景出发，演示了如何组合使用blktrace和debugfs这两个工具，层层追查IO的来源。 具体来说，当iostat显示磁盘压力巨大时，先用blktrace捕获块设备层的IO请求。关键点在于grep出以“A”开头的日志行，这里是原始请求的入口，能清晰看到读写操作对应的源设备扇区。接着，通过debugfs的“icheck”命令，根据扇区号换算出的文件系统块号，反查到对应的inode号。最后，用“ncheck”命令把这个inode号映射为具体的文件路径——比如例子中的“test_file”。 整个流程就像顺藤摸瓜：从设备层的扇区，到文件系统的块和inode，最终定位到用户可见的文件。拿到这个结果后，就能结合自己的应用程序，分析为什么这个文件会被频繁读写，从而进行优化。文章给出了完整的命令示例和输出解读，实操性很强。
这篇讲的是在CentOS 5.3系统上，一个使用EXT3文件系统的数据分区发生了文件误删事件。作者没有停留在理论，而是直接分享了从发现问题到成功恢复的完整实战过程。 核心方法是利用EXT3文件系统的日志特性，通过专门工具直接读取文件系统日志来定位被删除文件的数据块。文章没有停留在“可以恢复”的结论上，而是详细记录了具体的命令行操作步骤、所使用的工具参数，以及恢复过程中可能遇到的文件名丢失或内容不完整等问题。 值得注意的是，作者明确指出了这种基于日志恢复方法的局限性：它高度依赖于日志尚未被新操作覆盖的时间窗口。文章最终给出了清晰的结论——在误删后立即停止对该分区的任何写入操作，并迅速启动恢复流程，是提高成功率的关键。整个案例从问题到解决，步骤扎实，为遇到类似问题的读者提供了一份可按图索骥的操作参考。
这篇讲的是在ext2文件系统上，如何利用debugfs工具将误删的文件找回来。作者从ext2的一个关键特性出发：执行rm命令时，其实只是删除了文件的索引，数据本身还保留在磁盘上，这为恢复提供了可能。 对于单个文件，操作很直接。打开debugfs连接设备，用`lsdel`找到被删文件的inode，再用`dump`命令就能将其导出。文章重点在于，当需要恢复成千上万个文件时，如何高效操作。作者演示了通过一条组合管道命令，先利用`lsdel`批量列出删除文件信息，再用grep和awk进行筛选（比如按用户、时间、文件大小），自动生成一个包含大量dump命令的脚本文件`cmd`。最后，一条`debugfs -f cmd`指令就能批量完成恢复，这省去了交互模式下手动生成命令的繁琐。 文章末尾还给出了一个至关重要的安全提示：如果系统有多块磁盘，恢复文件时务必指定保存到另一块磁盘。否则，dump过程写入的数据可能会覆盖掉其他尚未恢复文件的磁盘区域，导致数据永久丢失。
