硬盘URE(不可恢复的读取错误)的粒度是多少?

hum*_*ace 8 hard-drive data-recovery

tl; dr,如果URE 发生在硬盘上,我会丢失 1 位、1 字节或扇区大小(512 字节或 4096 字节 AF)吗?如果可能,请解释为什么会这样?

背景: 当硬盘读取数据出现问题时,就会出现这里的问题。当然,磁盘可能会完全失败而导致其所有数据丢失(DISK FAIL),但我在这里询问的情况是,只有一小部分丢失(URE,不可纠正的读取错误)。

尽管我已经查找了有关 URE 的信息,但我几乎没有找到确切的信息。这可能有其原因,因为驱动器内部发生的事情,即从直接用户交互(如 ECC 校正)中隐藏的内容,对我来说很难与我作为用户访问的内容相关 - 扇区。

让我们想象一下硬盘读取数据有问题。

在那种情况下,这肯定意味着:

  • (a) 扇区的某些位无法读取,或
  • (b) 所有位都可以读取,但它们没有通过校验和测试(当然期望扇区 4096 字节不只是 8*4096 位,而是一些额外的位/字节用于错误检查/纠正(即奇偶校验位) ) (C) ????

不,我相信当我们处于 (a) 和 (b) 的组合并且无法对 4096 扇区的字节进行可靠重建的情况时,那么假设所有这些字节都必须是垃圾文件是过分的,实际上,如果我们知道内部硬盘纠错逻辑,我们可能会说“看起来有些东西没有检查出来,如果有好的变化,块数据的至少 1,2,3,n 位/字节是“错误的” ”。如果我们在该扇区中多余地保存“hello,hello.....,hello”ASCII 字节字符串,我们实际上可能仍然有相当连续的“hello,hello....”,然后才会出现“... Uellohello...”(即“e”->“U”)。

那么 URE 的粒度是多少呢?

更新:有一条评论输入了坏扇区的想法(并暗示这反映了 URE 事件的粒度。建议它并不荒谬,也许可以用于回答问题。但我刚刚阅读了另一个相关的询问待处理的不可读扇区的问题(此处为https://unix.stackexchange.com/questions/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors),这让我认为在某些在某些情况下,在 URE 的情况下丢失的数据之间确实存在更模糊的界限。

Jam*_*han 8

硬盘驱动器上的纠错码是与每个硬件扇区相关联的附加数据块。在写入期间,驱动器固件会计算此数据并将其与用户数据一起写入。在读取期间,固件读取 ECC 和数据并一起检查它们。

对于传统硬盘驱动器,硬件扇区为 512 字节。对于高级格式驱动器,它是 4K 字节(驱动器在接口上显示 512 字节还是 4K 字节扇区并不重要,即 512e 与 4kn)。

读取后检查的结果基本上有三种可能的结果:

  • 扇区被正确读取。这实际上在现代硬盘驱动器上并不完全常见。位密度取决于 ECC 的工作。

  • 读取扇区时有可纠正的错误。如上所述,这种情况并不少见。这是预期的。驱动器将应用了纠错的数据返回给用户。

  • 扇区被读取,但“错误位”太多;错误无法纠正。

在后一种情况下,驱动器通常不会返回任何内容;它只返回一个指示错误的状态。这是因为不可能知道哪些位是可疑的,更不用说它们的值应该是什么了。因此整个扇区(ECC 位和所有)是不可信的。无法确定坏道的哪个部分是坏的,更不用说它的内容应该是什么了。ECC 是一个“格式塔”,它是跨整个扇区内容计算的,如果不匹配,则不匹配的就是整个扇区。

SpinRite 的工作原理是简单地尝试一遍又一遍地读取坏扇区,使用“维护读取”功能返回数据(但没有 ECC 位),即使驱动器显示“无法纠正的错误”。正如 DavidPostill 链接的描述中所说,它可能会成功读取无错误(实际上“可纠正”的可能性更大);或者它可能能够通过将返回的位平均在一起来推断出扇区内容的合理猜测。与驱动器相比,它无法使用 ECC 精确纠正错误;这在数学上是不可能的。