分布式救援(GNU)算法

Question

manual.html

快速救援的算法如下(用户可以在任何时候中断进程，但要注意坏的驱动器会在内核放弃之前很长一段时间阻止暂存)： ( 1)可选地读取描述多部分或先前中断的救援状态的日志文件。如果没有指定日志文件，或者是空的，或者不存在，请将所有救援域标记为“未试”。 2) (第一阶段；复制)读取输入文件中未试过的部分，将失败的块标记为未修剪并跳过它们，直到所有救援域都试过为止。只有未试过的区域才能在大块中读取。裁剪、分割和重试是按扇区进行的。每个扇区最多试两次；第一步作为大块读取的一部分，第二步在下面的步骤中作为单个扇区读取。 3) (第二阶段；修边)从最大的无修剪块的前缘一次读一个扇区，直到发现一个坏扇区。然后从同一块的后缘一次向后读一个扇区，直到发现一个坏扇区。对于每个未修剪的块，将发现的坏扇区标记为坏扇区，并将该块的其余部分标记为非拆分。重复，直到没有更多的非修剪块。 4) (第三阶段；分裂)从最大的非分裂块中心一次读一个扇区，直到发现一个坏扇区。然后从同一块的中心一次向后读一个扇区，直到发现一个坏扇区。如果日志文件大于--logfile-size', read the smallest non-split blocks until the number of entries in the logfile drops below--日志文件大小‘。重复，直到所有剩余的非分割区块有少于5个扇区。然后按顺序读取剩余的非拆分块。 5) (第四阶段；重试)可选地尝试重新读取坏扇区，直到达到指定数量的重试为止。 6)可选地编写日志文件供以后使用。

我的理解是：**当他在复制的时候，他只是一个一个地拷贝，从不后退去复制旧的块。任何包含缺陷扇区的块都被标记为“坏”(整个块)。坏块被标记为未修剪。

图例：

=1 2 3= is a bad BLOCK
[1 2 3] is a good block
x is a bad sector
@ is the read cursor
in a =1 2 3= center sector(2) is always bad

当正在修剪时，一次从最大的无修剪块的前缘读取一个扇区，直到发现一个坏扇区。

=1 2 3= [4 5 6] =7 8 9=@ [10 11 12] =13 14 15=

=1 2 3= [4 5 6] =7 8 9= [10 11 12] =13 @14 15=

然后从同一块的后缘一次向后读一个扇区，直到发现一个坏扇区。

=1 2 3= [4 5 6] @=7 8 9= [10 11 12] =13 14 15=

=1 @2 3= [4 5 6] =7 8 9= [10 11 12] =13 14 15=

对于每个未修剪的块，将发现的坏扇区标记为坏扇区，并将该块的其余部分标记为非拆分。

=1 x 3= [4 5 6] =7 8 9= [10 11 12] =13 x 15=

1. 他为什么要这么做？？为什么他不能线性地复制，每次他遇到一个坏的扇区，跳过它--在我看来，他所做的只是从一个坏块中提取工作扇区。
2. 我被困在‘修剪’和分裂是更糟-谁能读文件解释这一切！
3. 他怎么能再试一次！他可以重试坏的部分，但既然他已经修剪了块并把它们写出来了--他将如何插入重试后恢复的数据？

Answer 1

1. 坏扇区自然发生在groups...if上，我用锤子轻轻敲了一下驱动器，头部很有可能划伤了surface...which is rotating...so，它会在存储表面形成一个很好的集中圆圈。尝试一个又一个坏块通常是时间wasting...and在大多数情况下坏驱动器没有太多的时间剩下.
2. 在削减未知范围后，最有可能有坏扇区的边缘-这就是为什么分裂开始在center...which可能是健康的.
3. 它通过使用using ()或类似于that...ddrescue的steroids...it上的dd来寻找目标扇区，它能够“知道”读取了哪些数据，它忽略了磁盘中所有不可读的部分。