我刚刚在大约9个月前就发现了两台全新的，相同的服务器上的相同问题。 我无法在这两个磁盘上写入磁盘，因为系统已将其标记为只读。 日志表明两者都有某种磁盘错误。
请注意，我在这些服务器上运行了多个guest虚拟机的KVM。 客人都运行良好，但问题是在KVM主机。 这可能没有关系，但也许是有关系的。 两个系统都只有两个驱动器 ，软件raid1和LVM在上面。 每个KVM客户也有自己的LVM分区。
在查看/proc/mdstat时，两个系统都显示降级的RAID1arrays。
所以我重新启动了其中一个系统，它告诉我需要手动运行fsck 。 所以我这样做了。 它似乎解决了问题，并重新启动，使系统正常恢复。 第二台服务器也使用相同的进程。
接下来，我运行mdadm --manage /dev/md0 --add /dev/sdb1将故障驱动器添加回数组中。 这两个服务器上工作正常。 在接下来的一个小时左右，查看/proc/mdstat显示驱动器正在同步进度。 大约一个小时之后，一个系统完成了， /proc/mdstat显示了一切与[UU]很好的结合。
但是，在另一个系统上，大约1.5小时后，系统负载猛增，没有任何反应。 几分钟后，一切都恢复了。 但现在看/proc/mdstat显示如下：
root@bond:/etc# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 sda1[2] sdb1[1] 293033536 blocks [2/1] [_U] unused devices: <none>
正如你所看到的，它似乎不再同步。 完成的百分比，剩余时间等不再显示。 但是，运行mdadm --detail /dev/md0显示：
root@bond:/etc# mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Mon Nov 30 20:04:44 2009 Raid Level : raid1 Array Size : 293033536 (279.46 GiB 300.07 GB) Used Dev Size : 293033536 (279.46 GiB 300.07 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Fri Sep 10 23:38:33 2010 State : clean, degraded Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d Events : 0.5104310 Number Major Minor RaidDevice State 2 8 1 0 spare rebuilding /dev/sda1 1 8 17 1 active sync /dev/sdb1
底线似乎表明，备件正在重build。 为什么这是一个备用？ 系统报告这两个设备是干净的。 它一直这样呆了好几个小时。 驱动器是小巧而快速的300GB 10K RPM的VelociRaptor，所以我认为它现在已经同步了。 试图重新添加说设备忙：
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda mdadm: Cannot open /dev/sda: Device or resource busy
在“好”服务器上运行dmesg最后显示了这一点：
[ 4084.439822] md: md0: recovery done. [ 4084.487756] RAID1 conf printout: [ 4084.487759] --- wd:2 rd:2 [ 4084.487763] disk 0, wo:0, o:1, dev:sda1 [ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
在“坏”服务器上，最后4行重复数百次。 在“好”的服务器上，他们只显示一次。
驱动器仍在同步吗？ 这个“重build”会完成吗？ 我只是需要更耐心？ 如果不是，我现在该怎么办？
更新：
我刚刚重新启动，驱动器又开始重新同步。 差不多2个小时后，同样的事情发生如上所述（仍然得到[_U]）。 但是，在RAID1 conf打印输出块完全消耗之前，我能够看到dmesg日志：
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code [ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor] [ 6348.303697] Descriptor sense data with sense descriptors (in hex): [ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 [ 6348.303707] 22 ee a4 c7 [ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed [ 6348.303716] end_request: I/O error, dev sdb, sector 586065095 [ 6348.303753] ata2: EH complete [ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024 [ 6348.305625] md: md0: recovery done.
所以也许我应该问的问题是：“如何在raid集的备用磁盘上运行fsck？
我不清楚你是否真的更换了故障的驱动器？ 因为如果您重新添加了有故障的驱动器，您的症状对我来说是有意义的，在这种情况下，驱动器locking的可能性很大。 如果你重新添加有故障的驱动器，/ var / log / messages或dmesg中是否有后续错误？
（顺便说一句，我强烈build议不要将故障驱动器重新添加到RAIDarrays中，如果故障损坏了磁盘上的数据，则可能会发现将其添加回arrays时，重新同步会将损坏的文件保留在光盘，下一次读取文件时，根据哪个磁盘首先响应，这将成为一个很好的或不良的数据，我已经看到这种情况发生了。
使用mdadm -details会在重build时列出一个驱动器。 重build完成后，将不再显示为备用。
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed [ 6348.303716] end_request: I/O error, dev sdb, sector 586065095 [ 6348.303753] ata2: EH complete [ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024 [ 6348.305625] md: md0: recovery done.
第一行表示重新分配失败，数据不被读取。 以下三行指出无法读取数据，并列出了不可读的扇区。
Rodger指出，驱动器坏了，不要重新添加。 重新添加失败的驱动器永远不是一个好主意。 拉动驱动器并更换它。 如果需要，请在发生故障的驱动器上运行诊断程序，但只能在拔出和更换后进行诊断。
首先 – 是摆脱任何抛出读取错误，最终在日志文件中的磁盘。 这意味着坏块重新定位失败和/或驱动器即将死亡。
我build议救援你的数据，你使用Linux救援光盘，如http://ubuntu-rescue-remix.org/使用ddrescue。 这可以将镜像复制到一个新的磁盘分区，并将执行大量的重试等尝试恢复您的分区。 安装USB驱动器或其他分区
mkdir / tmp / x && mount / dev / sdd1 / tmp / x
保存ddrescue日志文件 – 然后您可以停止ddrescue（ctrl-C）并稍后从同一点重新启动它。
在新磁盘上创build一个比旧磁盘更大的分区。 你不必使用整个磁盘！
用“nodmraid”作为内核启动参数启动救援CD。 如果使用Ubuntu Live CD，那么安装RAID和LVM（如果使用的话）
apt-get install mdadm lvm2 gddrescue
你将需要在互联网上工作）。 否则，使用ubuntu rescue CD进行ddrescue步骤。 我在ddrescue运行的救援CD和grub和fsck工作的live CD之间进行了交换。
假设/ dev / sdb是您的失败源磁盘，并且/ dev / sdx是您的新磁盘，并且/ mnt / x是另一个已安装的磁盘上的USB密钥或分区。 你需要 ddrescue日志文件，真的！ 跟踪ddrescue如何进行，并允许它被打断。
按照http://www.forensicswiki.org/wiki/Ddrescue
ddrescue –no-split / dev / sdb / dev / sdX imagefile / mnt / x / logfile
然后
ddrescue –direct –max-retries = 3 / dev / sdb / dev / sdX / mnt / x / logfile
然后
ddrescue –direct –retrim –max-retries = 3 / dev / sdb / dev / sdX / mnt / x / logfile
如果要花费数小时来恢复单个扇区，不要害怕按Ctrl-C进程。 只要继续下一步（第一步应该是成功的）。 最后一步试图恢复可用数据的最后碎屑。
你也必须这样做
mdadm –create / dev / md99 –level-1 –raid-devices = 2缺less/ dev / sdX
使用新磁盘创build一个新的RAIDarrays，这将在分区上写入一个新的RAID超级块（在分区末尾的最后64K到128K）。
从系统中删除旧的故障磁盘/ dev / sdb，以便它对linux不可见。
使您的源RAID磁盘可访问。 你可能必须使用内核启动内核的“nodmraid”参数，因为我遇到了ubuntu rescue CD的问题，最后使用了Ubuntu live CD（10.4），其中nodmraid在F6 Options中。 你应该只需要使用
mdadm –assemble / dev / md99 / dev / sdX
然后fsck或做任何检查你需要做的md99 RAIDarrays上的数据（我用vgscan，然后能够看到LVM LVs运行检查）。 我为mythtv使用XFS，但是xfs_check命令崩溃了我的系统，但xfs_repair正常。
从新的/ dev / sdX挂载/ boot目录
mount / dev / mapper / my_vg / root_lv / tmp / x
然后在新的/ dev / sdX RAID磁盘上添加一个新的GRUB引导logging（仅当您从RAID引导时）
grub-setup -d / tmp / x / boot / grub / dev / sdX
现在你有一个（几乎）可引导的RAIDarrays。 您也可以使用GRUB本身进行设置，或使用dd将/ dev / sdb的前446个字节复制到/ dev / sdX。 只有第一个446字节，第一个扇区的其余部分是你的分区表，如果你复制的更多，你将会大大的填满！ 你可能也必须对你的分区/ dev / sdX1（比如说）中的第一个扇区做同样的事情。 备份你要覆盖的任何部分，也使用dd。
如果使用grub2，并且从RAID引导，则会发现RAIDarraysUUID已更改，因此引导将失败。 编辑引导命令行（在Grub启动面板中的e）删除飞溅和安静，所以你可以看到发生了什么。 然后，失败的启动后，你留在initramfs。
mdadm –assemble / dev / md99 / dev / sdX
然后检查/ proc / mdstat以确保数组在那里。 如果这只是“退出”，希望你的GRUB启动节能够正常工作（我的设置使用了LVM，所以一旦有任何RAID设备，它只是findLV设备在RAID设备上，它只是searchLV）。 一旦你开机了，你就差不多完成了。
initrd映像文件（gzip cpio文件）包含启动过程中使用的mdadm.conf的一个副本，在启动过程中可以看到并可编辑为/etc/mdadm/mdamdm.conf。 如果你能正常引导你的系统，只需使用更新initramfs即可
update-initramfs -u
如果因为mdadm.conf文件中的UUID不匹配而无法启动系统
请注意，当您以不同的方式启动（Grub，rescue，real boot）时，您的目标设备/ dev / sdX可能会显示为/ dev / sdY。
顺便说一下，除非你使用的是RAID5，并且对块alignment真的很感兴趣，否则我会为你的RAIDarrays使用一个分区，你不必使用整个磁盘（尤其是如果你用1TB磁盘replace2TB一）。 您可以随时添加另一个分区和第二个RAIDarrays来使用整个2TB。
唷！ 完成！