我的问题发生在我尝试将 Windows 7 安装在其自己的 SSD 上时。我使用的 Linux 操作系统具有软件 RAID 系统的知识，它位于一个 SSD 上，我在安装之前将其断开。这样做是为了防止 Windows（或我）无意中弄乱它。
然而，回想起来，我很愚蠢地让 RAID 磁盘保持连接状态，认为 Windows 不会如此荒谬地弄乱它认为是未分配空间的 HDD。
我错了！将安装文件复制到 SSD 后（如预期和期望的那样），它还ntfs在其中一个 RAID 磁盘上创建了一个分区。这既出乎意料，也完全不是我想要的！
。
我再次更换了SSDs，并在 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!
我有点不确定接下来该怎么做，尝试“看看是否有效”对我来说有点太冒险了。我建议我应该尝试以下方法：
告诉（Windows 写入的那个）不再可靠，假装它是新重新引入到阵列中，并根据其他三个驱动器重建其内容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 而言，那里没有分区，只有未分配的空间。如果没有，这些命令可能就无法工作。
也许镜像之前未动过的其他 raid 设备的分区表是有意义的--re-add。例如：
sfdisk -d /dev/sdb | sfdisk /dev/sdd
附加问题： 为什么 Windows 7 安装会做出如此潜在的危险的事情？
更新
我继续将其标记/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|> ||
目前看起来还不错。希望接下来还能再玩 5 个多小时 :)
更新 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
答案1
我有点惊讶于你mdadm一开始用那个磁盘组装了阵列，但这是另一个故事。不幸的是，你的阵列可能不再处于可恢复状态。
Linux 软件 raid 假定阵列是健康的（干净的），除非磁盘控制器发出读取或写入错误信号，如Linux 突袭 wiki司机认为，因为有很多磁盘上存储的冗余数据，并且硬盘与控制器之间的链路也采用了错误检测。
因此，在您的情况下（在 RAID6 模式下），奇偶校验块甚至不会被读取。
覆盖您的一个磁盘（从磁盘的角度来看）是一个完全有效的请求，并且您的磁盘已经无错误地完成了该操作。
现在，当您请求使用包含损坏数据的磁盘重建阵列时，您只会将损坏的数据传播到整个阵列。
正确的做法是将驱动器设置为故障，然后将其重新添加到阵列中。阵列将在安全状态下重建。