<div dir="ltr">Ben,<div><br></div><div>does this patch actually break the Red Hat integration ?</div><div>I'm inclined to merge it if not.</div><div><br></div><div>Thanks,</div><div>Christophe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 7:44 AM, Hannes Reinecke <span dir="ltr"><<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/02/2016 05:31 PM, Benjamin Marzinski wrote:<br>
> On Wed, Apr 27, 2016 at 01:10:23PM +0200, Hannes Reinecke wrote:<br>
>> multipath should be using the option '-i' to ignore the wwids<br>
>> file when called from udev. Otherwise we might run into a race<br>
>> condition with systemd and the system might not boot up correctly.<br>
><br>
> The race condition being? Are you talking about the udev rules not<br>
> claiming a path for multipath, but then having multipathd create a<br>
> multipath device using that path? I agree that this can be an issue.<br>
> Another way to solve it is to run mutipathd with the -n option in the<br>
> initramfs (see commit a8efa5838cf215febd853f282c26af62c0daa862). That<br>
> commit solves the race by making mutipathd ignore devices that aren't<br>
> already in the wwids file.  This also keeps the initramfs from picking a<br>
> different user_friendly_name than will be picked in late boot (but<br>
> hopefully that issue has been sorted out by other patches already).<br>
><br>
</span>This is in fact SUSE-specific, as we do _not_ require any a-priory<br>
configuration. So we will start out with a system without any wwid file,<br>
_but_ expect multipath to start up properly.<br>
As the wwid file will only be created by multipathd the udev check will<br>
always being false, and none of the multipath devices will be created.<br>
<span class=""><br>
> I'm not NAKing this. The question of what to do about the differnces in<br>
> the distribution's systemd and udev configurations can be hashed out<br>
> outside of patch reviewing. I just want to make sure I understand the<br>
> race this is solving.<br>
><br>
</span>This is in fact a good question.<br>
We should be coming up with a common approach which would suit both needs.<br>
<br>
Cheers,<br>
<br>
Hannes<br>
<span class="HOEnZb"><font color="#888888">--<br>
Dr. Hannes Reinecke                   zSeries & Storage<br>
<a href="mailto:hare@suse.de">hare@suse.de</a>                          <a href="tel:%2B49%20911%2074053%20688" value="+4991174053688">+49 911 74053 688</a><br>
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg<br>
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)<br>
</font></span></blockquote></div><br></div>