![mdadm:Win7-install 在我的一个 RAID6 驱动器上创建了一个启动分区。如何重建?](https://linux22.com/image/1409878/mdadm%EF%BC%9AWin7-install%20%E5%9C%A8%E6%88%91%E7%9A%84%E4%B8%80%E4%B8%AA%20RAID6%20%E9%A9%B1%E5%8A%A8%E5%99%A8%E4%B8%8A%E5%88%9B%E5%BB%BA%E4%BA%86%E4%B8%80%E4%B8%AA%E5%90%AF%E5%8A%A8%E5%88%86%E5%8C%BA%E3%80%82%E5%A6%82%E4%BD%95%E9%87%8D%E5%BB%BA%EF%BC%9F.png)
我的问题发生在我尝试将 Windows 7 安装在其自己的 SSD 上时。我使用的 Linux 操作系统具有软件 RAID 系统的知识,它位于一个 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!
我有点不确定接下来该怎么做,尝试“看看是否有效”对我来说有点太冒险了。我建议我应该尝试以下方法:
告诉(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 模式下),奇偶校验块甚至不会被读取。
覆盖您的一个磁盘(从磁盘的角度来看)是一个完全有效的请求,并且您的磁盘已经无错误地完成了该操作。
现在,当您请求使用包含损坏数据的磁盘重建阵列时,您只会将损坏的数据传播到整个阵列。
正确的做法是将驱动器设置为故障,然后将其重新添加到阵列中。阵列将在安全状态下重建。