IMSM fakeraid handled by mdadm: unclean mounted volumes on shutdown/reboot

Bug #1608495 reported by Stefan Bader on 2016-08-01
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
Critical
Dimitri John Ledkov
Xenial
Critical
Dimitri John Ledkov
Yakkety
Critical
Dimitri John Ledkov
Zesty
Critical
Dimitri John Ledkov

Bug Description

Opening this report for Xenial and later as this problem does surface again due to moving to systemd.

Background:

mdadm is used to create md raid volumes based on Intel Matrix Storage Manager fakeraid metadata. The setup usually consists of a container set that contains one or more raid volumes. Which is the reason that those fakeraid volume are more affected by timing issues on shutdown/reboot.

In my specific setup I am using one of the IMSM raid volumes as a LVM PV and one LV of that is mounted as /home. The problem is that unmounting /home on shutdown/reboot will update the filesystem superblock which causes the raid state to become dirty for a small period of time. For that reason with sysvinit scripts there is a mdadm-waitidle script which *must* be run after the umountroot (or for /home at least after umountfs) script has run.

With Xenial both umountroot and umountfs are softlinks to /dev/null in /lib/systemd/system, so I am not sure they are good to cause the mdadm-waitidle to be delayed *after* all filesystems are unmounted.
Practically I see that if /home is mounted on shutdown/reboot, the raid set will go into a full resync the next time I boot (additional pain but different problem: the resync appears to be much more aggressive than in the past, delaying boot a lot and rendering the system barely usable until it finishes). If I manually unmount /home before the reboot, the raid set is good.

Dimitri John Ledkov (xnox) wrote :

annoying.

/lib/systemd/system-shutdown/mdadm.shutdown should be syncing everything up, but of course that's only in unstable / yakkety.

I have spare drives finally again, so I will setup ISMS on my xenial desktop and play around with it. Hopefully package from yakkety is "good enough" for SRU into xenial.

Changed in mdadm (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Stefan Bader (smb) wrote :

I can do some testing as well. Admittedly any unsuccessful run is a bit of a pain as the re-sync takes 1-2hrs.

Stefan Bader (smb) wrote :

I did a quick test and created a mdadm.shutdown in /lib/systemd/system-shutdown like the template in Yakkety (adapted path to binary and made it executable). Unfortunately that did not help. However there might be some step missing to activate it in systemd. I guess I need to make output more verbose and add some delay to be sure that this indeed is executed and when.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mdadm (Ubuntu):
status: New → Confirmed
Sergio Callegari (callegar) wrote :

See also 1320402 and 1587142

Changed in mdadm (Ubuntu):
importance: Undecided → Critical
Dimitri John Ledkov (xnox) wrote :

I have a reproducer test case, and a partial fix for xenial I think.
I will start a bileto PPA with test packages for this issue.

Changed in mdadm (Ubuntu Xenial):
status: New → Confirmed
Changed in mdadm (Ubuntu Yakkety):
status: New → Confirmed
Changed in mdadm (Ubuntu Xenial):
importance: Undecided → Critical
Changed in mdadm (Ubuntu Yakkety):
importance: Undecided → Critical
Changed in mdadm (Ubuntu Xenial):
milestone: none → xenial-updates
Changed in mdadm (Ubuntu Yakkety):
milestone: none → yakkety-updates
Changed in mdadm (Ubuntu Zesty):
milestone: none → ubuntu-17.03
Changed in mdadm (Ubuntu Yakkety):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in mdadm (Ubuntu Xenial):
assignee: nobody → Dimitri John Ledkov (xnox)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers