我应该选择哪个扇区大小来直接访问高级格式驱动器上的 ddrescue？

Question

我首先运行以下命令，开始对 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。然而，就我而言，mapfile 包含大量 512 字节的块，这些块在第一次运行完成后既不可读又被抢救。

在第二次运行期间，512 b 块中的大部分合并为 4K 块。例如，在分裂阶段之前与非分裂块相邻的 512 b 坏扇区与相邻的坏扇区合并在一起。这对我来说似乎很好。可能，在修整阶段，硬盘驱动器上的磁头无法读取 4K 扇区，因此它返回 512 b 坏扇区给 ddrescue。修整在那里结束，512 b 扇区后面的块被标记为非分割。

看起来不正常的是有一个 512 b 坏扇区，如下图所示：

为什么磁头能够读取 4K 扇区，但声明其中只有 1/8 不可读？我的印象是物理扇区是由磁头原子读取的？因此，如果它的一部分不好，那么整个部门都是坏的。

这显然提出了一个问题——是否可以通过运行 ddrescue 直接访问或不直接访问但具有 512 b 扇区大小来从 4K“部分坏”扇区获取数据？

显然有些事情不会加起来。

顺便说一句，这是我第一次发布问题，所以如果格式与论坛不一致或问题过多，请原谅。但除此之外，我将很高兴获得与主要问题相关的任何主题的输入，即高级格式、直接磁盘访问、内核缓存等。来自读者。

干杯!

Answer 1

我与 ddrescue 的作者 Antonio Diaz 交换了电子邮件，他告诉我与“高级格式”驱动器（即具有 4096 字节物理扇区，但 512 字节“逻辑扇区”的驱动器）一起使用的正确参数“） 是：

 -b4096

如果您希望它一次只读取一个 4096 字节扇区（慢！），那么您还可以指定：

  -c1

Antonio 在 StackExchange 上并不活跃，但他通过以下电子邮件邮件列表支持 ddrescue：

https://www.mail-archive.com/bug-ddrescue@gnu.org/

如果您将电子邮件发送到 bug-ddrescue@gnu.org，那么您的电子邮件和他的回答都会以组织良好的形式显示在该摘要页面上（当然，不会显示您的电子邮件地址）。此外，在打扰安东尼奥之前，您可以在该页面上进行搜索，尝试查找以前对您的问题或疑问的讨论。（他很忙，所以请不要浪费他的时间！）

您的 ddrescue 日志文件包含 512 字节“坏”区域的原因是您最初使用 512 字节的默认扇区大小运行 ddrescue。这并不是灾难性的，但如果 ddrescue 认为驱动器有 512 字节扇区，并且发出的读取由于读取错误而返回 0 字节数据，则 ddrescue 假定只有 512 字节中的第一个字节不可读，并且不做任何假设其余的部分。因此，日志文件中只有 512 字节被标记为错误。

Answer 2

根据维基百科，奇偶校验可以是分布式的，并且ECC可以恢复一些数据。不同的磁盘可能有不同的ECC算法。在 512 位扇区错误的情况下，可能 4K 扇区仅部分损坏，ECC 能够纠正并验证 4K 扇区的 7/8。