1. XFS:如何找到 inode 的路径/目录 2. 文件中的 XFS -o 循环和 ddrescue?

1. XFS:如何找到 inode 的路径/目录 2. 文件中的 XFS -o 循环和 ddrescue?
  1. 如何找到一些损坏的 XFS inode 的完整原始文件/目录路径?

    以及如何在数百万个文件中快速列出最后修改的几十万个 inode(=编辑或移动的文件/目录)?

  2. 是只对文件中损坏的 website.image 文件系统进行 ddrescue 更好,还是对整个硬盘(包括其父文件系统,据说没有损坏,尽管磁盘有一些错误)进行 ddrescue 更好?(而“1”则不是,这可能需要阅读下面的整个故事)

在 Debian 上安装的几乎完整的 XFS 映像 -o loop 在同一驱动器上运行多年,非常高效。每天读取数百万个文件,只有一些文件每隔几天分批写入。

/dev/cciss/c0d9      1953449048 1950392335   3056714 100% /website  '
(smart unvisible due to HP p410 raid controller)
/dev/loop0  1950358937 1937866163  12492775 100% /var/www/website

在移动一批文件时,文件系统已经说了几次再见。这次它无法再安装,并尝试使用 xfs_repair 和 xfs_repair -f -L,但无济于事,在 I/O 错误扫描 inode 时停止...

ddrescue /dev/cciss/c0d9 /dev/cciss/c0d6 /ddrescuelog 首次运行时,ddrescue 日志发现大约 50 个错误,总计约 2800kb

经过几次之后:ddrescue -c1 --direct --retrim --try-again /dev/cciss/c0d9 /dev/cciss/c0d6 /ddrescuelog 500 个错误,据称只剩下 440 kb 仍然丢失。

(还忘记使用日志一次,再次覆盖前 20gb 直到我停止它。但我想没有问题,因为它会写入目标驱动器上完全相同的位置?)

现在修复新磁盘上的文件系统, 它删除了大约 2000 个损坏的 inode 和 1500 个文件/目录 就像这个:

bad magic number 0xe5a0 on inode 3270245798
bad version number 0x12 on inode 3270245798
bad inode format in inode 3270245798
bad magic number 0xe5a0 on inode 3270245798, resetting magic number
bad version number 0x12 on inode 3270245798, resetting version number
bad inode format in inode 3270245798
cleared inode 3270245798
**entry "index.html" at block 0 offset 6848 in directory inode 3270245561 references free inode 3270245798
        clearing inode number in entry at offset 6848...**

*- 另外:对于十亿个 inode,我认为 xfs_repair 确实消耗了 30GB 的 RAM 并在最后一步崩溃了(这很常见,我想这没什么关系)

        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ..*

谢谢=)

答案1

您最好的恢复选项是 UFS Explorer。

显然,摆脱复杂的循环设备和文件系统安排是有意义的。

看:如何恢复出现“超级块读取失败”的 XFS 文件系统

相关内容