欢迎光临，若觉得本博客的内容对您有帮助，请多点击边栏的Google广告，并提供意见及建议，谢谢！
Jul
25
是的，我知道ext3文件系统上，一旦文件被删除(rm -rf )，就几乎没有恢复的可能。而且从ext3文件系统的FAQ中提到的一条也能印证这点：
但是，但是，这不是事实的全部，被删除文件的所有信息可能都还在磁盘上，包括块指针。ext3grep通过分析文件系统日志，实现了恢复被删除文件的功能。
引用
Q: How can I recover (undelete) deleted files from my ext3 partition?
Actually, you can’t! This is what one of the developers, Andreas Dilger, said about it:
In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as “deleted” and leaves the block pointers alone.
Your only hope is to “grep” for parts of your files that have been deleted and hope for the best.
Actually, you can’t! This is what one of the developers, Andreas Dilger, said about it:
In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as “deleted” and leaves the block pointers alone.
Your only hope is to “grep” for parts of your files that have been deleted and hope for the best.
但是，但是，这不是事实的全部，被删除文件的所有信息可能都还在磁盘上，包括块指针。ext3grep通过分析文件系统日志，实现了恢复被删除文件的功能。
Nov
4
某机器，系统运行一段时间之后根分区都会变成只读。当使用光盘进入拯救模式后，用
可以看到文件系统的状态是“clean with errors”。
用fsck进行系统检查时，报如下错误：
该错误表明ext3文件系统有一部分的日志丢失了。由于fsck并不能恢复日志，需要手动重建磁盘日志。
# dumpe2fs -h /dev/sda1
可以看到文件系统的状态是“clean with errors”。
用fsck进行系统检查时，报如下错误：
引用
journal_bmap_Rsmp_6199acb1: journal block not found at offset 5132 on md(9,0)
Aborting journal on device md(9,0).
ext3_abort called.
EXT3-fs abort (device md(9,0)): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
Aborting journal on device md(9,0).
ext3_abort called.
EXT3-fs abort (device md(9,0)): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
该错误表明ext3文件系统有一部分的日志丢失了。由于fsck并不能恢复日志，需要手动重建磁盘日志。
