![分区恢复后出现与 ext4/lvm/raid-5 相关的奇怪问题](https://linux22.com/image/1317479/%E5%88%86%E5%8C%BA%E6%81%A2%E5%A4%8D%E5%90%8E%E5%87%BA%E7%8E%B0%E4%B8%8E%20ext4%2Flvm%2Fraid-5%20%E7%9B%B8%E5%85%B3%E7%9A%84%E5%A5%87%E6%80%AA%E9%97%AE%E9%A2%98.png)
我有 3 个硬盘,以下分别命名为 /dev/sda、/dev/sdb 和 /dev/sdc,最新的排在最前面。注意:/dev/sdc 有一个主分区 /dev/sdc1、一个扩展分区 /dev/sd2 和 3 个逻辑分区 /dev/sdc5、/dev/sdc6 和 /dev/sda7。
我使用 /dev/sda5 和 /dev/sdb5 创建了一个降级的 RAID 5 设备 /dev/md0(计划将 /dev/sdc5 添加到 RAID 以使其恢复正常状态),然后使用 /dev/md0 作为 LVM 的唯一 pv,并创建了一个具有 ext4 文件系统的 lv /dev/mapper/vg0-lv0。
不幸的是,在探索和使用 LVM 时,我dd if=/dev/zero of=/dev/sdc1 bs=64M count=10
删除了 /dev/sdc1。因此实际上将零写入了 /dev/sdc2,并破坏了存储在 /dev/sdc2 上的分区表的一部分以及 /dev/sdc5 的开头部分。
当意识到这一点时,我立即通过 dd 制作了 /dev/sdc 的图像,如下所示:dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img
。
几天后,我终于有时间尝试恢复 /dev/sdc 上的数据,实际上只有 /dev/sdc7,因为它是唯一没有备份的分区。我用映像文件 sdc.img 运行 testdisk,使用其快速搜索功能重建分区表,将其丢失到 /dev/loop0。/dev/loop0p7(/dev/sdc7 的映像)已恢复并可挂载,所有文件似乎都正常。然后我运行find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum
以构建 /dev/loop0p7 上所有文件的 MD5 校验和列表。
在处理物理 /dev/sdc 设备时,testdisk 的快速搜索找不到所有分区,但深度搜索可以。然后我用类似的命令为物理 /dev/sdc7 上的所有文件建立了 MD5 校验和列表 sdc7.md5sum。当将它与 sdc7_image.md5sum 进行比较时,我发现 4 个文件不同。手动比较后,我注意到每个文件只有 1 个字节的差异。而且由于一个文件的名称中有 CRC32,所以我可以确认来自物理 /dev/sdc7 的文件是正确的。
所以我的问题是,为什么会发生这种奇怪的事情?我已经运行fsck.ext4 -c -c /dev/mapper/vg0-lv0
确认它没有坏块。1.2TB 数据中的 4 个字节差异所占百分比很小,但这让我对将来在 /dev/mapper/vg0-lv0 上存储数据没有信心。
更新:我不得不提一下,所有操作都是在最新的 ArchLinux 中完成的,该 Linux 运行在 Windows 7 中的 VirtualBox 4.1.16 中。/dev/sda、/dev/sdb 和 /dev/sdc 都通过 链接到物理硬盘VBoxManage internalcommands createrawvmdk
。VirtualBox 在对物理 /dev/sdc7 进行 md5sum 时只报告了错误 VERR_ACCESS_DENIED,在通过diskpart
Win7 离线物理磁盘后,没有出现其他错误。
答案1
有几种情况可能发生。首先,您没有提到在对磁盘进行映像之前卸载 sdc7,因此可能是当时正在写入数据。不过,我猜情况并非如此,否则您就不会问了。我无法指责您的反应“首先,对磁盘进行映像”,这是一个相当不错的反应。不过我注意到,在您重新启动之前,内核仍然在内存中保留分区表,请检查/proc/partitions
。
首先要检查的是内存错误。您的 RAM 可能有问题。您的数据无疑经过了 RAM 多次。我假设您没有 ECC 内存,这可能会发现这个问题。
硬盘也会出错。查看一些随机消费级硬盘的规格表,它们显示每 100 Tbit 出错 1 次。您至少复制了 1.2TB 数据几次(从源读取,从目标读取),因此读取量相当于 19 Tbit。出现一点错误是可以接受的。(遗憾的是,规格表上没有给出写入错误率)。
单字节损坏背后有什么原因或韵律吗?cmp -l
可以告诉您变化的字节。例如,如果页面中的偏移量始终相同(您的页面大小可能是 4K),并且始终是相同的位,则几乎可以肯定地指向有缺陷的 RAM。即使它始终是相同的位或相同的偏移量,那也将是相当有说服力的(并且您是否对所有四个文件都进行了 CRC32,还是只有一个?)