Ubuntu 16.04 - 冻结 mdadm 数组

Question

Ubuntu 16.04 - 冻结 mdadm 数组

我有一个由 6 个 4TB 磁盘组成的工作 RAID5 阵列。Smartd 报告其中一个磁盘开始出现故障。我决定在一次操作中做几件事：1) 移除出现故障的磁盘 2) 添加新磁盘以替换它 3) 向阵列添加更多磁盘并对其进行扩展

由于我只有较小的磁盘用于 (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

Run Code Online (Sandbox Code Playgroud)

起初，一切都进行得几乎顺利。阵列开始重建。唯一奇怪的是没有创建备份文件。我之前在跑步

watch -n 1 mdadm --detail /dev/md1
nmon

Run Code Online (Sandbox Code Playgroud)

在后台密切关注事物。在重建过程中，我可以访问该阵列。

然而，进入进程 9% 后，阵列上的所有 I/O 都停止了，除了 /dev/sdb 和 /dev/sdb1 上的 100% 读取。一旦我杀死了 watch -n 1 mdadm，那也停止了。

这是 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

Run Code Online (Sandbox Code Playgroud)

我无法在阵列上执行任何 I/O。运行 htop 显示一个 CPU 内核 100% 执行 I/O 操作。

我重新启动了机器。阵列没有重新组装。我通过运行手动重新组装它：

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

Run Code Online (Sandbox Code Playgroud)

（重新启动磁盘后更改名称）。但是 lvm 正确地找到了卷和组并将它们调出。

没有力量它不会打球。它确实组装并显示了上面引用的 --detail 报告。

但是它仍然不允许任何 I/O，因此挂载命令冻结（我在那里使用单个磁盘 LVM，在里面使用 ext4 文件系统）。htop 还展示了一个与 I/O 挂钩的 CPU 内核。

但是，所有磁盘活动 LED 都不亮。

目前我被困在一个包含大量数据的非功能数组中。理想情况下，我想检索数据。

也许使用 LVM 逻辑卷作为 mdadm“磁盘”是一个错误。虽然我没有找到任何信息表明它不起作用。

我非常感谢有关如何恢复我的阵列的任何建议和指示。

仔细查看 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

Run Code Online (Sandbox Code Playgroud)

Answer 1

Spo*_*ler 8

为此使用 LVM 确实是一个错误。它不仅为它的创建者以外的任何人制造了不必要的复杂存储堆栈，而且 MD 阵列是在 LVM 阵列之前构建的，需要您在充当 MD 成员的 LV 上手动调用 MD 扫描。

此外，避免在持久配置中使用内核设备名称（例如 sda、sdb 等）。这在命名卷组时尤其重要，因为 VG 抽象了底层存储并且可以在 PV 之间自由移动。内核设备名称也不被认为是永久性的，并且可以因各种原因随时更改。这对 LVM PV 来说不是问题（因为它们是批量磁盘扫描的一部分，几乎可以拾取任何东西），但是您的 VG 名称很快就不会反映您创建的情况中的实际情况。

我建议您尝试从 MD 阵列中优雅地移除 LV，并将其恢复到降级（但正常）状态。请注意，在粉碎错误时，人们并不关心 LVM 之上的 MD。您处于未知领域，您期望工作的事情可能会无缘无故地失败。

如果这些数据很重要并且没有备份，那么您可能希望听从对 LVM 和 MD 非常了解的现场人员。我假设你没有，因为你在这里问，所以如果你需要的话，让我们谈谈。如果你必须走那条路，我会用任何有趣的细节来更新这个。现在，只需尝试通过将 LVM 混乱替换为成员的普通旧磁盘来进行后退。

你能扩展那个 dd 命令吗？您是否将所有磁盘内容转储到 /dev/null？如果您怀疑磁盘坏了，这可能不是最好的做法。相反，尝试在磁盘上执行 smartctl 命令（例如`smartctl -a /dev/sda`）以获取每个磁盘的完整运行状况报告。它的速度要快得多，并且可以为您提供真实的信息。由于我将简单地告诉您本文档中的大部分内容，因此请参考此处的一些恢复技巧：https://raid.wiki.kernel.org/index.php/RAID_Recovery 如果您有，我可以扩展该内容任何问题。 (3认同)

归档时间：	8 年，8 月前
查看次数：	1400 次
最近记录：	8 年，8 月前