mdadm：Win7 安装在我的一个 RAID6 驱动器上创建了一个引导分区。如何重建？
swa*_*log 6 linux raid software-raid mdadm hard-drive-recovery
当我尝试在它自己的 SSD 上安装 Windows 7 时，我的问题发生了。我使用的具有软件 RAID 系统知识的 Linux 操作系统位于我在安装前断开连接的 SSD 上。这样 Windows（或我）就不会无意中搞砸了。
然而，回想起来，愚蠢的是，我让 RAID 磁盘保持连接状态，认为 Windows 不会如此荒谬，以至于弄乱了它认为只是未分配空间的 HDD。
男孩是我错了！将安装文件复制到 SSD 后（如预期和需要的那样），它还ntfs在其中一个 RAID 磁盘上创建了一个分区。既意外又完全不受欢迎！
.
我SSD再次更改了s，并在 linux 中启动。mdadm像以前一样组装阵列似乎没有任何问题，但是如果我尝试挂载阵列，则会收到错误消息：
mount: wrong fs type, bad option, bad superblock on /dev/md0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
dmesg：
EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!
然后我用来qparted删除新创建的ntfs分区，/dev/sdd以便它与其他三个匹配/dev/sd{b,c,e}，并请求与我的阵列重新同步echo repair > /sys/block/md0/md/sync_action
这花了大约 4 个小时，完成后，dmesg报告：
md: md0: requested-resync done.
在 4 小时的任务后有点简短，但我不确定其他日志文件的存在位置（我似乎也搞砸了我的 sendmail 配置）。在任何情况下：根据 未报告任何更改mdadm，一切检查。
mdadm -D /dev/md0仍然报告：
Version : 1.2
Creation Time : Wed May 23 22:18:45 2012
Raid Level : raid6
Array Size : 3907026848 (3726.03 GiB 4000.80 GB)
Used Dev Size : 1953513424 (1863.02 GiB 2000.40 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Mon May 26 12:41:58 2014
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 4K
Name : okamilinkun:0
UUID : 0c97ebf3:098864d8:126f44e3:e4337102
Events : 423
Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
2 8 48 2 active sync /dev/sdd
3 8 64 3 active sync /dev/sde
尝试挂载它仍然报告：
mount: wrong fs type, bad option, bad superblock on /dev/md0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
和dmesg：
EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!
我有点不确定从哪里开始，尝试“看看它是否有效”对我来说有点太冒险了。这是我建议我应该尝试做的：
告诉mdadm说/dev/sdd（在一个窗口写进）是不可靠了，假装它是最近重新推出的阵列，并重建基础上，其他三个驱动器的内容。
我的假设也可能完全错误，ntfs分区的创建/dev/sdd和随后的删除已经改变了一些无法通过这种方式修复的东西。
我的问题： 求助，我该怎么办？如果我应该按照我的建议去做，我该怎么做？通过阅读文档等，我认为可能：
mdadm --manage /dev/md0 --set-faulty /dev/sdd
mdadm --manage /dev/md0 --remove /dev/sdd
mdadm --manage /dev/md0 --re-add /dev/sdd
但是，文档示例建议/dev/sdd1，这对我来说似乎很奇怪，因为就 linux 而言，那里没有分区，只有未分配的空间。也许没有这些命令将无法工作。
也许在--re-add. 就像是：
sfdisk -d /dev/sdb | sfdisk /dev/sdd
额外的问题： 为什么 Windows 7 安装会做一些如此st...潜在危险的事情？
更新
我继续并标记/dev/sdd为有故障，并从阵列中删除它（不是物理上的）：
# mdadm --manage /dev/md0 --set-faulty /dev/sdd
# mdadm --manage /dev/md0 --remove /dev/sdd
但是，不允许尝试 --re-add ：
# mdadm --manage /dev/md0 --re-add /dev/sdd
mdadm: --re-add for /dev/sdd to /dev/md0 is not possible
--add，很好。
# mdadm --manage /dev/md0 --add /dev/sdd
mdadm -D /dev/md0现在报告状态clean, degraded, recovering，和/dev/sdd作为spare rebuilding。
/proc/mdstat 显示恢复进度：
md0 : active raid6 sdd[4] sdc[1] sde[3] sdb[0]
3907026848 blocks super 1.2 level 6, 4k chunk, algorithm 2 [4/3] [UU_U]
[>....................] recovery = 2.1% (42887780/1953513424) finish=348.7min speed=91297K/sec
nmon 还显示预期输出：
?sdb 0% 87.3 0.0| > |?
?sdc 71% 109.1 0.0|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR > |?
?sdd 40% 0.0 87.3|WWWWWWWWWWWWWWWWWWWW > |?
?sde 0% 87.3 0.0|> ||
到目前为止看起来不错。交叉我的手指另外五个多小时:)
更新 2
恢复/dev/sdd完成，dmesg输出：
[44972.599552] md: md0: recovery done.
[44972.682811] RAID conf printout:
[44972.682815] --- level:6 rd:4 wd:4
[44972.682817] disk 0, o:1, dev:sdb
[44972.682819] disk 1, o:1, dev:sdc
[44972.682820] disk 2, o:1, dev:sdd
[44972.682821] disk 3, o:1, dev:sde
尝试mount /dev/md0报告：
mount: wrong fs type, bad option, bad superblock on /dev/md0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
并在dmesg：
[44984.159908] EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
[44984.159912] EXT4-fs (md0): group descriptors corrupted!
我不确定现在该怎么做。建议？
的输出dumpe2fs /dev/md0：
dumpe2fs 1.42.8 (20-Jun-2013)
Filesystem volume name: Atlas
Last mounted on: /mnt/atlas
Filesystem UUID: e7bfb6a4-c907-4aa0-9b55-9528817bfd70
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244195328
Block count: 976756712
Reserved block count: 48837835
Free blocks: 92000180
Free inodes: 243414877
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 791
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stripe width: 2
Flex block group size: 16
Filesystem created: Thu May 24 07:22:41 2012
Last mount time: Sun May 25 23:44:38 2014
Last write time: Sun May 25 23:46:42 2014
Mount count: 341
Maximum mount count: -1
Last checked: Thu May 24 07:22:41 2012
Check interval: 0 (<none>)
Lifetime writes: 4357 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e177a374-0b90-4eaa-b78f-d734aae13051
Journal backup: inode blocks
dumpe2fs: Corrupt extent header while reading journal super block
mdadm我对首先使用该磁盘组装阵列感到有点惊讶，但这是另一个故事了。不幸的是，您的阵列可能不再处于可恢复状态。
Linux 软件 raid 假定阵列是健康的（干净的），除非磁盘控制器发出读或写错误信号，如 Linux raid wiki上所述。驱动程序假设因为磁盘上存储了大量冗余数据，并且硬盘和控制器之间的链接也使用了错误检测。
因此，您的情况（在 RAID6 模式下）的四种情况甚至无法读取奇偶校验块。
覆盖您的一个磁盘（从磁盘的角度来看）是一个完全有效的请求，并且由您的磁盘完成，没有错误。
现在，当您请求使用包含损坏数据的磁盘重建阵列时，您只需将损坏的数据传播到整个阵列即可。
正确的做法是将驱动器设置为故障，然后将其添加回阵列。阵列将在安全状态下重建。
| 归档时间： |
|
| 查看次数： |
454 次 |
| 最近记录： |