批处理带有调试器的dd救援映射文件

Question

我有一个由mapfile生成的ddrescue，它列出了418个坏扇区，每行看起来如下(减号表示一个坏块)：

Position      Size
0x1CC7C68000  0x00001000  -

通过将以字节为单位的位置转换为分区相对扇区号，我可以使用debugfs查询inode编号，然后查找已损坏的文件的路径。对于将近2000个坏块来说，手动执行这个操作是不可行的，所以我想将其自动化，是否有一种在文件系统上执行一系列命令的脚本debugfs的方法？

下面是我目前正在为一个破碎的扇区获取文件名所做的工作：

1. ddrescue mapfile中的位置是相对于磁盘开始的字节。首先，我用512除以扇区数，然后减去分区的起始位置:第一扇区的划分: 91914240坏块位置: 0x1CC7C68000在十进制: 123610759168绝对扇区位置: 123610759168 / 512 = 241427264分区上的相对块位置: 241427264 - 91914240 = 149513024

因此，坏扇区相对于分区启动位于149513024，使用debugfs，我现在可以找到inode：

$ debugfs
debugfs: open /dev/sdd3
debugfs: icheck 149513024
Block       Inode number
149513024   1183169
debugfs: ncheck 1183169
Inode   Pathname
1183169 /username/foo/bar/baz

我想自动化这个过程，这样我就可以将块位置的列表传递给debugfs，将这些块解析为inode，过滤inode以排除未映射的inode，然后使用ncheck解析其余节点的路径名。通过调试器和一些shell脚本，这是可能的吗？

Answer 1

在我的rpi3b+ SD卡死后，我今天不得不这样做。最后，我编写了一个python脚本，完成了您在上述bash脚本中所做的工作，但它将自动显示文件路径。您可以在这里查看：https://github.com/zkrx/rescue2path

在这个解决方案中，我还检查了尚未刮掉的数据块('/')。刮擦在这里花了很长时间，我在它完成之前就停了下来。

Arch中的这个条目特别有用：https://wiki.archlinux.org/index.php/Identify_受损_文件