linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] mdadm: Fix udev rule interaction with systemd
@ 2015-08-18 11:51 Thomas Bächler
  2015-08-18 11:51 ` [PATCH 1/2] udev: Set SYSTEMD_READY to 1 when the array becomes active Thomas Bächler
  2015-08-18 11:51 ` [PATCH 2/2] udev: Work around race condition on array activation Thomas Bächler
  0 siblings, 2 replies; 3+ messages in thread
From: Thomas Bächler @ 2015-08-18 11:51 UTC (permalink / raw)
  To: linux-raid


Good morning,

I discovered a problem with the interaction between systemd, mdadm and lvm: Every 5th boot or so, my lvm physical volume
on top of a raid1 array would not activate. This turned out to be a race condition with mdadm.

When activating the raid array, two uevents happen: an "ADD" event and a "CHANGE" event. In both cases, the mdadm udev
rules look at the md/array_state file in sysfs. However, I observed that an array with md/array_state == clean may still
be inaccessible. So, in order to analyze the issue, I looked at the contents of the "md/array_state" and the "size" sysfs
files. I discovered that during activation, my raid1 was in the following three states:

1) md/array_state: inactive, size: 0
2) md/array_state: clean, size: 0
3) md/array_state: clean, size: (the real array size)

So, if the ADD event happens in state 1) and the CHANGE event happens in state 3), everything is fine. However, sometimes the
ADD event happens in state 2) and the CHANGE event in state 3). In the latter case, the device is activated in systemd during
the ADD event, but udev internal settings like ID_FS_TYPE are not set (since the device is inaccessible). This causes the
problem described above.

What I don't know is if
a) the transition from state 1) to 3) should be atomic in the kernel.
b) state 2) is legal and this needs to be worked around in udev.

The first patch fixes a problem where ENV{SYSTEMD_READY} is never set to 1 after being set to 0.
The second patch checks whether the array has non-zero size before activating the systemd device unit (in case this is
not a kernel bug).

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-18 11:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-18 11:51 [PATCH 0/2] mdadm: Fix udev rule interaction with systemd Thomas Bächler
2015-08-18 11:51 ` [PATCH 1/2] udev: Set SYSTEMD_READY to 1 when the array becomes active Thomas Bächler
2015-08-18 11:51 ` [PATCH 2/2] udev: Work around race condition on array activation Thomas Bächler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).