我首先运行以下命令开始对 AF/512e HDD 进行映像：
ddrescue -n /dev/sdb2 drive_c.img mapfile.log
完成后，我对 mapfile.log 进行了备份，并决定使用驱动器的物理扇区大小 4K 来运行直接磁盘访问的分割阶段：
ddrescue -d -b4096 -r3 /dev/sdb2 drive_c.img mapfile.log
如果我选择了 512 字节扇区大小，我会从坏扇区中清除更多吗？
当我写这篇文章时，分割阶段已经完成，坏扇区正在第二次重试。当然，mapfile 中几乎所有的坏块都是 n×4K 大小。如果我运行相同的命令但使用 512 b 扇区，我是否能够从它们中获取更多信息？
思想与困惑
首先，我什至不确定使用直接磁盘访问是否合适。
ddrescue 的信息文件在以下情况下调用直接磁盘访问开关：
日志文件中的位置和大小始终是扇区大小的倍数
这意味着
内核正在缓存磁盘访问并对它们进行分组。
因此，如果我的内核对请求进行“分组”，则映射文件中的最小块应该是 8K 或 16K。然而，就我而言，映射文件包含大量 512 字节的块，这些块在第一次运行完成后无法读取并被救援。
在第二次运行期间，大部分 512 b 块被合并为 4K 块。例如，在分割阶段之前与未分割块相邻的512b坏扇区与相邻坏扇区合并在一起。这对我来说似乎很好。可能在修剪阶段，硬盘驱动器上的磁头无法读取 4K 扇区，因此它返回 512 b 坏扇区以进行 ddrescue。修剪就在那里结束，512 b 扇区后面的块被标记为非分割。
看起来不正常的是有一个 512 b 坏扇区，如下截图所示：
为什么磁头能够读取 4K 扇区，但仅声明其中 1/8 不可读？我的印象是物理扇区是由磁头自动读取的？因此，如果其中一部分不好，那么整个行业都会不好。
这显然提出了一个问题——是否可以通过运行 ddrescue 来从 4K“部分损坏”扇区获取数据，无论是否直接访问，但扇区大小为 512 b？
显然有些东西不合时宜。
顺便说一句，这是我第一个发布的问题，所以如果格式与论坛不一致或者问题太多，请原谅。但除此之外，我将很高兴获得与主要问题相关的任何主题的输入，即高级格式、直接磁盘访问、内核缓存等，因为我发现的所有内容要么与实际情况相差太远，要么明显假设了专业知识来自读者。
干杯!
答案1
我与 ddrescue 的作者 Antonio Diaz 交换了电子邮件，他告诉我与“高级格式”驱动器（即具有 4096 字节物理扇区，但 512 字节“逻辑扇区”的驱动器）一起使用的正确参数“） 是：
-b4096
如果您希望它一次只读取一个 4096 字节扇区（慢！），那么您还可以指定：
-c1
Antonio 在 StackExchange 上并不活跃，但他通过以下电子邮件邮件列表支持 ddrescue：
https://www.mail-archive.com/[电子邮件受保护]/
如果您将电子邮件发送至[电子邮件受保护]然后您的电子邮件将显示在该摘要页面上，他的答案也会以组织良好的形式显示（当然，不会显示您的电子邮件地址）。此外，在打扰安东尼奥之前，您可以在该页面上进行搜索，尝试查找以前对您的问题或疑问的讨论。 （他很忙，所以请不要浪费他的时间！）
您的 ddrescue 日志文件包含 512 字节“坏”区域的原因是您最初使用 512 字节的默认扇区大小运行 ddrescue。这并不是灾难性的，但如果 ddrescue 认为驱动器有 512 字节扇区，并且发出的读取由于读取错误而返回 0 字节数据，则 ddrescue 假定只有 512 字节中的第一个字节不可读，并且不做任何假设其余的部分。因此，日志文件中只有 512 字节被标记为错误。
答案2
根据维基百科，奇偶校验可以分布，ECC可以恢复一些数据。不同的磁盘可能有不同的ECC算法。在 512 位扇区错误的情况下，可能 4K 扇区仅部分损坏，ECC 能够纠正并验证 4K 扇区的 7/8。