我有一个有效的RAID5arrays，由6个4TB磁盘组成。 Smartd报告说其中一个磁盘启动失败。 我决定在一个操作中做几件事情：1）删除发生故障的磁盘2）添加一个新的replace它3）添加更多的磁盘到arrays，并成长
由于（3）我只有较小的磁盘，所以我使用LVM连接大于4TB的卷
这是我跑的顺序：
1) vgcreate vg_sdi_sdj /dev/sdi1 /dev/sdj1 2) vgcreate vg_sdj_sdl /dev/sdk1 /dev/sdl1 3) lvcreate -l 100%FREE -n all vg_sdi_sdj 4) lvcreate -l 100%FREE -n all vg_sdk_sdl 5) mdadm --manage /dev/md1 --add /dev/sdg1 6) mdadm --manage /dev/md1 --add /dev/vg_sdi_sdj/all 7) mdadm --manage /dev/md1 --add /dev/vg_sdk_sdl/all 8) mdadm --manage /dev/md1 --fail /dev/sdc1 9) mdadm --grow --raid-devices=8 --backup-file=/home/andrei/grow_md1.bak /dev/md1 起初一切都进展顺利。 arrays开始重build。 唯一奇怪的是备份文件没有被创build。 我之前在跑步
watch -n 1 mdadm --detail /dev/md1 nmon
在背景中保持眼睛的东西。 虽然正在重build，我可以访问arrays。
然而，在进程9％的情况下，除了在/ dev / sdb和/ dev / sdb1上读取100％的数据之外，arrays上的所有I / O都会停止。 有一次我杀了手表，但是也停了下来。
这里是mdadm的最近输出–detail：
/dev/md1: Version : 1.2 Creation Time : Sun Jan 8 22:16:01 2017 Raid Level : raid5 Array Size : 19534430720 (18629.49 GiB 20003.26 GB) Used Dev Size : 3906886144 (3725.90 GiB 4000.65 GB) Raid Devices : 8 Total Devices : 8 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Jan 15 21:38:17 2017 State : clean, degraded, reshaping Active Devices : 7 Working Devices : 8 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Reshape Status : 9% complete Delta Devices : 2, (6->8) Name : server:1 (local to host server) UUID : bec66f95:2975e7ae:8f8ba15c:8eb3a33f Events : 79504 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 9 252 0 1 spare rebuilding /dev/dm-0 2 8 49 2 active sync /dev/sdd1 3 8 145 3 active sync /dev/sdj1 4 8 161 4 active sync /dev/sdk1 6 8 177 5 active sync /dev/sdl1 8 252 1 6 active sync /dev/dm-1 7 8 129 7 active sync /dev/sdi1
我无法在arrays上进行任何I / O操作。 运行htop显示一个CPU内核挂100％做I / O操作。
我重新启动机器。 arrays没有重新组装。 我通过运行手动重新组装它：
mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
（重新启动磁盘后更改名称）。 但是，lvm正确地find了卷和组，并将它们提起来。
没有武力就不会打球。 它汇集并显示了上面引用的 – 尾巴报告。
但是，它仍然不会允许任何I / O，所以安装命令冻结（我单磁盘LVM那里和ext4文件系统里面）。 htop还展示了一个与I / O挂钩的CPU内核。
但是，没有任何磁盘活动指示灯亮起。
目前，我坚持与一个非常有用的数据在其中的数组。 理想情况下，我想要检索数据。
也许将LVM逻辑卷用作mdadm“磁盘”是个错误。 虽然我没有find任何信息表明这是行不通的。
我真的很感激任何意见和指导如何恢复我的arrays。
仔细看看journalctl -xe显示如下：
Jan 15 22:41:15 server sudo[1612]: andrei : TTY=tty1 ; PWD=/home/andrei ; USER=root ; COMMAND=/sbin/mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all Jan 15 22:41:15 server sudo[1612]: pam_unix(sudo:session): session opened for user root by andrei(uid=0) Jan 15 22:41:15 server kernel: md: md1 stopped. Jan 15 22:41:15 server kernel: md: bind<dm-1> Jan 15 22:41:15 server kernel: md: bind<sdd1> Jan 15 22:41:15 server kernel: md: bind<sdg1> Jan 15 22:41:15 server kernel: md: bind<sdh1> Jan 15 22:41:15 server kernel: md: bind<sdf1> Jan 15 22:41:15 server kernel: md: bind<dm-0> Jan 15 22:41:15 server kernel: md: bind<sde1> Jan 15 22:41:15 server kernel: md: bind<sdb1> Jan 15 22:41:15 server mdadm[879]: NewArray event detected on md device /dev/md1 Jan 15 22:41:15 server mdadm[879]: DegradedArray event detected on md device /dev/md1 Jan 15 22:41:15 server kernel: md/raid:md1: reshape will continue Jan 15 22:41:15 server kernel: md/raid:md1: device sdb1 operational as raid disk 0 Jan 15 22:41:15 server kernel: md/raid:md1: device sde1 operational as raid disk 7 Jan 15 22:41:15 server kernel: md/raid:md1: device dm-0 operational as raid disk 6 Jan 15 22:41:15 server kernel: md/raid:md1: device sdf1 operational as raid disk 5 Jan 15 22:41:15 server kernel: md/raid:md1: device sdh1 operational as raid disk 4 Jan 15 22:41:15 server kernel: md/raid:md1: device sdg1 operational as raid disk 3 Jan 15 22:41:15 server kernel: md/raid:md1: device sdd1 operational as raid disk 2 Jan 15 22:41:15 server kernel: md/raid:md1: allocated 8606kB Jan 15 22:41:15 server kernel: md/raid:md1: raid level 5 active with 7 out of 8 devices, algorithm 2 Jan 15 22:41:15 server kernel: RAID conf printout: Jan 15 22:41:15 server kernel: --- level:5 rd:8 wd:7 Jan 15 22:41:15 server kernel: disk 0, o:1, dev:sdb1 Jan 15 22:41:15 server kernel: disk 1, o:1, dev:dm-1 Jan 15 22:41:15 server kernel: disk 2, o:1, dev:sdd1 Jan 15 22:41:15 server kernel: disk 3, o:1, dev:sdg1 Jan 15 22:41:15 server kernel: disk 4, o:1, dev:sdh1 Jan 15 22:41:15 server kernel: disk 5, o:1, dev:sdf1 Jan 15 22:41:15 server kernel: disk 6, o:1, dev:dm-0 Jan 15 22:41:15 server kernel: disk 7, o:1, dev:sde1 Jan 15 22:41:15 server kernel: created bitmap (30 pages) for device md1 Jan 15 22:41:15 server kernel: md1: bitmap initialized from disk: read 2 pages, set 7 of 59615 bits Jan 15 22:41:16 server kernel: md1: detected capacity change from 0 to 20003257057280 Jan 15 22:41:16 server kernel: md: reshape of RAID array md1 Jan 15 22:41:16 server kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Jan 15 22:41:16 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape. Jan 15 22:41:16 server kernel: md: using 128k window, over a total of 3906886144k. Jan 15 22:41:16 server mdadm[879]: RebuildStarted event detected on md device /dev/md1 Jan 15 22:41:16 server sudo[1612]: pam_unix(sudo:session): session closed for user root Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589312 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589320 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589328 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589336 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589344 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589352 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589360 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589368 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589376 on sdf1) Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759582288 on sdf1) ... Jan 15 22:43:36 server kernel: INFO: task md1_reshape:1637 blocked for more than 120 seconds. Jan 15 22:43:36 server kernel: Not tainted 4.4.0-59-generic #80-Ubuntu Jan 15 22:43:36 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 15 22:43:36 server kernel: md1_reshape D ffff88021028bb68 0 1637 2 0x00000000 Jan 15 22:43:36 server kernel: ffff88021028bb68 ffff88021028bb80 ffffffff81e11500 ffff88020f5e8e00 Jan 15 22:43:36 server kernel: ffff88021028c000 ffff8800c6993288 ffff88021028bbe8 ffff88021028bd14 Jan 15 22:43:36 server kernel: ffff8800c6993000 ffff88021028bb80 ffffffff818343f5 ffff8802144c7000 Jan 15 22:43:36 server kernel: Call Trace: Jan 15 22:43:36 server kernel: [<ffffffff818343f5>] schedule+0x35/0x80 Jan 15 22:43:36 server kernel: [<ffffffffc01d2fec>] reshape_request+0x7fc/0x950 [raid456] Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60 Jan 15 22:43:36 server kernel: [<ffffffffc01d346b>] sync_request+0x32b/0x3b0 [raid456] Jan 15 22:43:36 server kernel: [<ffffffff81833d46>] ? __schedule+0x3b6/0xa30 Jan 15 22:43:36 server kernel: [<ffffffff8140c305>] ? find_next_bit+0x15/0x20 Jan 15 22:43:36 server kernel: [<ffffffff81704c5c>] ? is_mddev_idle+0x9c/0xfa Jan 15 22:43:36 server kernel: [<ffffffff816a20fc>] md_do_sync+0x89c/0xe60 Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60 Jan 15 22:43:36 server kernel: [<ffffffff8169e689>] md_thread+0x139/0x150 Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60 Jan 15 22:43:36 server kernel: [<ffffffff8169e550>] ? find_pers+0x70/0x70 Jan 15 22:43:36 server kernel: [<ffffffff810a0c08>] kthread+0xd8/0xf0 Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0 Jan 15 22:43:36 server kernel: [<ffffffff8183888f>] ret_from_fork+0x3f/0x70 Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
使用LVM确实是一个错误。 MD不仅为创build者以外的人创build了一个不必要的复杂存储栈，MD数组在LVM数组之前构build，要求您在作为MD成员的LV上手动调用MD扫描。
此外，避免在持久configuration中使用内核设备名称（如sda，sdb等）。 这在命名卷组时尤其重要，因为VG将底层存储抽象出来，并可以自由地跨越PV进行移动。 内核设备名称也不被认为是永久性的，并且可以随时因各种原因而改变。 这对于LVM PV来说并不是问题（因为它们是批量磁盘扫描的一部分，几乎可以提取任何内容），但是您的VG名称很快就不会在您创build的情况下反映出真实情况。
我build议您尝试从MDarrays中正常删除LV，并将其恢复到降级（但是正常）的状态。 请注意，在LVM之上的MD不是人们关心的问题。 你在未知的领域，而你期望的工作可能会失败，没有明显的原因。
如果这些数据非常重要，而且没有备份，那么您的方式就是要推迟到现场知道LVM和MD的人。 我假设你没有，因为你在这里问，所以让我们有一个对话，如果你需要它。 我会更新这个有任何有趣的细节，如果你必须走这条路线。 现在，试着用一个普通的旧磁盘replace成员来替代LVM的混乱。