警告：本文介绍的解决方案不是专业的，它可能是在对硬盘驱动器的结构和操作原理的误解的基础上创建的。 重复上述步骤可能会损坏设备。
最近，我遇到了一篇有关使用旧硬盘驱动器的坏块的文章 ，并认为我的经验可能对某人也很有趣。
有一次，熟人问我如何处理无法重新安装Windows的笔记本电脑。 从外观来看，笔记本电脑的使用寿命很长：外壳破裂，角落凹陷，机架破裂。 显然，问题是由于多次冲程导致硬盘驱动器损坏，这一点也得到了Smart的确认：超过200个G传感器操作，500个重新分配的扇区数，并且仍处于“待处理”状态。 嗯，当然，我安装了SSD，并使用以下命令将其螺钉中的信息复制到映像中：
dd if=/dev/sdb of=/media/hddimages/ht320.img bs=409600 conv=noerror,notrunc,sync
需要参数“ conv = noerror，notrunc，sync”，以便在读取某些扇区时发生错误的情况下，将零写入输出文件中的这些地址，并且将数据无偏差地写入其位置。
碰巧的是，当读取大块（400kb）时，磁盘不会读取整个块，而较小的块不会只读取1个扇区。 此处的扇区为4kb，因此在dd的第一次通过之后，如果出现读取错误，我尝试以4kb的块再次读取这些部分：
n=<>;dd if=/dev/sdb of=/media/hddimages/ht320.img bs=4096 conv=noerror,notrunc,sync skip=$n seek=$n count=100
需要skip和seek参数，以便从磁盘开头以相同的缩进开始读取和写入。 缩进本身是从第一个dd执行的输出中获取的，只是为了匹配块大小，将数字乘以100。
有时，访问坏扇区的磁盘会长时间挂起，以至于只有重新连接电源才有帮助，大约在5年前，制造了一个硬件-软件复合体（大声地说，甚至是使用微控制器），可以通过自动重新连接电源来自动读取坏硬盘。长期缺乏回应。 10天后，通过连接硬输入并输入命令，它很有趣并且被允许获得最完整的图像。 但是这篇文章的实验英雄并没有因此而死心，因此没有必要获得所描述的笨重的拐杖。
因此，考虑了磁盘，我通过lostup挂载了映像的所有部分，并加上了fdisk分区开始的偏移量，乘以逻辑块大小（以mbr为单位）-512字节，然后将所有数据复制到新SSD上。 如果未安装磁盘或无法读取许多文件，我将使用R-Studio打开映像并通过映像还原它，但可以从映像本身还原它。
但是尽管被击败了，但辛苦的努力还是很可惜，所以我决定以某种方式使其恢复活力。 从理论上讲，如果反复尝试写入失败或使用ECC无法恢复（使用ECC），则磁盘控制器会将扇区标记为已损坏，并将备份扇区重新分配给它们的地址。
首先，我尝试擦除磁盘（dd if = / dev / zero ...），然后读取：速度也不稳定，磁盘冻结，有时会出现输入/输出错误，但在智能方面，重新锁定和挂起的次数正在增加。 经过几个周期后，智能设备的变化并不大，待处理的对象也没有重新定位，并且每次在相同的地方或附近都发生错误挂起。 我尝试使用命令“ hdparm --make-bad-sector”强制手动重新映射，但这在此模型上不起作用，并且我意识到仅擦除读取以及写入读取将无法显示所有问题所在。 确实，如果受损的位（无论他们尝试写入什么位）更可能读为“ 1”，那么当写入位“ 1”时，随后的读取将无错误地进行，但是当写入不同的模式时，可能存在足够多的不一致，以致ECC失败并发生不可修复的读取错误，并且在多次出现此类情况后，该扇区的状态为“不良”。 顺便说一下，记录的值可以如此叠加在损坏的位的分布上，以至于读取的错误值甚至可以满足ECC。 因此，为了最大程度地识别所有坏扇区，您需要生成一个相对随机的模式，将其写入磁盘，然后读取并比较该值。 还有不稳定的扇区，它们随着时间的推移或在处理其邻居之后逐渐改变其值。
鉴于以上所有内容，我决定在bash脚本中实现以下策略：
- 我们生成一个随机模式并考虑它的校验和；
- 我们读得很聪明；
- 用零写入磁盘；
- 读取光盘；
- 我们以随机模式写入磁盘，同时读取刚刚记录的块并比较其校验和；
- 完全记录后读取磁盘，检查每个块的校验和；
- 我们读得很聪明；
- 自检
- 转到1。
我们将继续这种方式，直到错误读取的扇区和IO错误停止发生，或者直到螺丝完全盖住为止。 顺便说一下，我无法想象这种模式的磁盘如何进行自我测试。 我不知道与short'a有多长（尽管long可以在整个表面上使用，而short则可以-着眼于先前收集的统计信息，如格式化：完整和快速）。 我希望这会鼓励螺丝钉考虑最近的经验并重新映射坏扇区。
当我写完bash脚本后，第二天就运行它并检查了结果-我发现验证非常慢，而任何内核上的处理器负载都没有达到60％。 这使我不得不处理块大小，测试用于校验和的不同哈希算法，尝试直接差异验证，而不是比较校验和，但是我无法达到每秒12兆字节以上的处理速度。 结果，我不再比较diff与400kb块，并且仅在随后的日志分析不匹配的情况下才计算校验和。
正如日志在重复执行该脚本后显示的那样，所有坏扇区都位于磁盘的前13 GB中，这是多个失败的“焦点”（很可能是当头撞到时，表面被划伤和划伤）。 在最近的15次运行中，磁盘没有看到任何可疑（待定）扇区，所有内容都已重新映射，但是在第13个千兆字节中间的某个位置，一个或多个不远的块被错误地读取到了不同的地址。 此外，一个块可以连续2个周期被认为是不正确的，然后正确地2次，一次又一次不正确。 因此，捕获最后10个坏扇区是一项长期的工作。 重新映射了1268个扇区！ 最后，一个惊喜等待着我：当一切都已经稳定运行时，在下一次自检之后，“重新分配的扇区计数”参数变为“ 0”，并且只有“重新分配的事件计数”以及最近5个错误的记录（地址和时间从开始工作）存储在日志中。
尽管运行稳定，但我还是决定尽量减少与损坏区域的互动，以免因印版表面受损的地方造成头部不规则而伤到头部，并且我长期不希望信任本地部门。 我稍稍退缩了一点，并创建了一个从第15 GB开始的分区。 而且，如时间所显示，该光盘感觉非常好，并且在可穿戴式笔记本电脑中稳定运行了10个月。
尽管不可能完全信任已还原的磁盘，并且该合资企业的经济可行性令人怀疑，但有时结果只是很好的补充。