[INTEL UBUNTU 18.04] RAID reshape hangs after OS reboot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mdadm (Ubuntu) |
Expired
|
Undecided
|
Unassigned | ||
Bionic |
Expired
|
Undecided
|
Unassigned |
Bug Description
Steps to reproduce:
1. Create IMSM RAID container:
mdadm --create /dev/md/imsm0 --metadata=imsm --raid-devices=3 /dev/sde /dev/sdc /dev/sdd --run
2. Create IMSM RAID volume:
mdadm --create /dev/md/
3. Add disk to container:
mdadm --add /dev/md127 /dev/sdb
4. Invoke RAID grow:
export MDADM_EXPERIMEN
5. By cat /proc/mdstat we will see status of the reshape.
Also systemd unit file has been created:
cat /<email address hidden>
# This file is part of mdadm.
#
# mdadm is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
[Unit]
Description=Manage MD Reshape on /dev/%I
DefaultDependen
[Service]
ExecStart=
#StandardInput=null
#StandardOutput
#StandardError=null
KillMode=none
And status of this service is:
● <email address hidden> - Manage MD Reshape on /dev/md127
Loaded: loaded (/<email address hidden>; static; vendor preset: enabled)
Active: active (running) since Fri 2018-03-23 09:20:54 CET; 23s ago
Main PID: 3364 (mdadm)
Tasks: 1 (limit: 37710)
CGroup: /system.
└─3364 /sbin/mdadm --grow --continue /dev/md127
6. Reboot the platform.
7. During OS booting I saw print:
[ 16.552076] md: reshape of RAID array md126
8. After successfully boot we can see hanging reshape process (by cat /proc/mdstat).
And status of the service:
systemctl status <email address hidden>
● <email address hidden> - Manage MD Reshape on /dev/md127
Loaded: loaded (/<email address hidden>; static; vendor preset: enabled)
Active: inactive (dead)
Possible workarounds:
a) systemctl restart <email address hidden>
or
b) mdadm --grow --continue /dev/md127
So the clue of the problem is in OS booting process and with correctly starting mdadm-grow-continue service.
information type: | Public → Private |
affects: | ubuntu → mdadm (Ubuntu) |
information type: | Private → Public |
tags: | added: vroc |
Changed in mdadm (Ubuntu Bionic): | |
status: | New → Incomplete |
This seems to me to be an upstream bug. The grow command starts the systemd unit, but doesn't enable it to be persistent. The md device names can change after reboot (if an additional array is connected whilst the system is off), therefore I think upstream udev rules should be improved to detect arrays that need mdadm-grow- continue@ .service, and trigger that unit via SYSTEMD_WANTS stanza in the udev rules.
Could you provide a dump of /sys/devices/ virtual/ block/md126/ md after reboot, when you expect the mdadm-grow-continue to resume? (assuming md126 is the one undergoing reshaping)
I hope that, e.g. /sys/devices/ virtual/ block/md126/ md/sync_ action is "reshape" and /sys/devices/ virtual/ block/md126/ md/reshape_ position is not "none".
Then it should be trivial to adjust the udev rules, to kick off mdadm-grow- continue@ .service, based on those sysfs attributes on boot.