![将 HFS+ 格式的驱动器映像写入 Linux 上容量较小的驱动器](https://linux22.com/image/1565184/%E5%B0%86%20HFS%2B%20%E6%A0%BC%E5%BC%8F%E7%9A%84%E9%A9%B1%E5%8A%A8%E5%99%A8%E6%98%A0%E5%83%8F%E5%86%99%E5%85%A5%20Linux%20%E4%B8%8A%E5%AE%B9%E9%87%8F%E8%BE%83%E5%B0%8F%E7%9A%84%E9%A9%B1%E5%8A%A8%E5%99%A8.png)
我在 Lubuntu 实时系统上使用 ddrescue 对一个可能存在缺陷的 1TB 硬盘驱动器进行了映像处理,该驱动器包含大约 270GB 的实际数据。恢复已完成 99.9%,只有 300MB 标记附近有 52KB 的区域无法读取 - 但 SMART 中没有“待处理”或“重新分配”的扇区。第一个问题:这怎么可能?这可能是“逻辑”坏扇区的良性情况吗?即扇区在物理上仍然可以运行,但处于不一致的状态,导致 CRC 校验失败,是否可以通过覆盖它们来持久可靠地“修复”它们?我运行了简短的自检,结果为“读取失败”。我仍然可以 100% 信任 SMART 数据,并确信如果它报告没有坏扇区,那么物理层面上确实没有坏扇区?
然后,我有 3 个备用驱动器,我可以用它们将恢复的数据传送给使用 MacBook 电脑的所有者:USB2 上的 320GB 驱动器、USB3 上的 500GB 驱动器、USB3 上的 1TB 驱动器。源驱动器格式化为 HFS+。有没有一种安全方便的方法可以将这个 1TB 映像(实际上只占用大约 270GB)直接写入较小容量的驱动器(因为它是使用 ddrescue 的 -S 开关在稀疏模式下创建的),使用 Linux 或 Windows 免费工具,这样恢复的 HDD 就易于读取,具有一致的分区表?(我没有使用 Apple 分区和格式化方案的经验。)或者我最好创建一个 HFS+ 分区(使用哪种工具,因为 GParter 显然无法处理这个)并复制文件和文件夹?但在这种情况下,时间戳和其他元数据会自动保留吗?还是我必须使用特定的方法来确保这一点?像“cp”这样的 Linux 命令可以在 HFS+ 分区之间复制文件并保留该文件系统特有的所有属性吗?
谢谢。
答案1
所以我按照直觉做了:我尝试用这个 ddrescue 命令覆盖那个微小的不可读区域(可以用更基本的 dd 工具来完成,但我不太熟悉它):
lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log
[Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.]
并且它起作用了:作为验证,我重新映像了第一个 GB,这次没有错误(我在运行上述命令之前尝试过这种部分映像,当时错误区域仍然存在,具有完全相同的位置和大小,我还注意到它立即被跳过,没有任何减速,这与通常发生的情况相反,当存在实际的“物理”坏扇区时,它会减慢速度或挂起几秒钟后再跳过);“简短自检”现在也已完成,没有错误。
在此之前,我尝试了一些 Windows 工具:使用 Hard Disk Sentinel 进行读取扫描使其无限期冻结,我不得不关闭驱动器;同样,尝试使用 WinHex 访问有问题的区域使其冻结,直到驱动器被关闭。
那么,我是否正确地认为这是一个“逻辑”坏扇区的情况,并且该驱动器在物理上是完好的,并且可以再次安全使用,因为在整个过程中 SMART 中从未显示过“待处理”或“重新分配”的扇区? 造成这种情况的可能原因是什么,也许是由于不正确的关机而中断了写入操作? 这是一个常见问题吗?当它影响系统文件时,它是否通常会导致驱动器无法运行?