<div dir="ltr">Still tanked in my local git tree.<div>I'll push them online late this afternoon.</div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jul 4, 2014 at 8:24 AM, Hannes Reinecke <<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/03/2014 09:25 PM, Benjamin Marzinski wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, Jul 03, 2014 at 01:05:37PM +0200, Hannes Reinecke wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 07/02/2014 09:48 PM, Benjamin Marzinski wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, Jul 02, 2014 at 08:03:38AM +0200, Hannes Reinecke wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 07/01/2014 09:22 PM, Christophe Varoqui wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hannes, would you Ack this one, or do you have some other idea for this in your tree ? </blockquote> Sigh. The whole multipath / systemd / dracut integration is _a mess_. The main problem is that RH and SUSE treat multipath handling differently. (From what I can see. I've still a hard time to understand how multipath booting works with RH. So there might be errors.) RH is taking a restrictive approach, ie it'll allow only configured multipath devices during boot. IE it'll accept only devices present in '/etc/multipath/wwids' for booting. So when coming across a new wwid multipath won't be setup there, so of course they'll need an additional parameter for that. </blockquote> That's not strictly true. multipathd will happily create a multipath device on top of any valid scsi devices it finds, but unless those devices are in /etc/multipath/wwids, other components, like lvm won't know to leave them alone. This actually isn't an issue during the initramfs boot stages because lvm doesn't do autoactivation there. So, if the device appears in the initramfs portion of boot, we're great. The specific issue that prompted this goes like this: - The iscsi initiator is not setup to run in the initramfs on install - Storage is added to the system that makes up a working LV - Once the machine boots up, and is past the initramfs, the iscsi initiator starts up and discovers the devices. - Multipath races with lvmetad and loses - Now you have a LV built on top of a single path device, instead of being multipathed (The LV is on top of a partition of the path device, so reassign_maps doesn't work on it) If you tell the redhat installer that you want to use multipath, this causes problems, since it can't disassemble the an arbitrary stack of virtual devices. Eventually, we'll fix that issue, and this won't matter anymore, because it will just be able to disassemble the virtual device stack, and rerun multipath, to make everything autoassemble in the correct order. </blockquote> Hmm. Similar to what I've seen here when booting with multipath enabled and an empty '/etc/multipath/wwids' file. We're having an udev rule calling 'multipath -u' to check if the device is eligible for multipathing. If so it'll set the various udev properties to keep LVM and others from working with that device. But as 'multipath -u' is be checking /etc/multipath/wwids it will always report 'not a multipath device'. So I would be perfectly happy with 'multipath -u' _not_ checking /etc/multipath/wwids (or have a switch for doing so). </blockquote> 'multipath -u'? Do you mean 'multipath -c'? I do worry that not checking the wwids file could break things were some device appears multipathable, but will never successfully get created for reasons outside of multipath's knowledge. The wwids file makes sure that this device is multipathable, because it HAS been multipathed before. That being said, I have no objections to a switch to avoid the wwid file check. </blockquote></div></div> Okay, I've send a patch.<div class=""> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Anyway. There is actually a slight inconsistency with the above approach: Multipath is _not_ setup for autoconfiguration; from my understanding this was exactly why /etc/multipath/wwids was introduced in the first place. LVM, on the other hand, is trying to do autoconfiguration. Why? I would set either both to autoconfiguration or none. If I want something different I need to configure the system. </blockquote> Well, multipath is only not set up to do autoconfiguration because you keep objecting to my find_multipaths patch, which makes multipath only run on devices that have more than one path. With that, you can usually leave the blacklists alone, and you will only get the devices that you want. </blockquote></div> Oh, I don't have any objections to that, provided it's configurable via the config file. Care to send a patch for that?<div class=""> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Can you clarify what the intended usage for /etc/multipath/wwids is? I was under the impression that it's been introduced to keep multipath from accepting unconfigured devices ... </blockquote> Like I mentioned above, it was added to avoid the situations where multipath isn't blacklisted on a device, but is unable to set up on it. We use this to so that 'multipath -c' doesn't claim a device and keep lvm or md from using it when it shouldn't. </blockquote></div> Ah, I've been luckier than you, then. I keep telling folks that multipath will grab all devices, and the only way to modify this is blacklisting devices via /etc/multipath.conf. So any system where the above happens is per definition misconfigured :-) Christophe, what happened to the patches you've said to have applied? I haven't seen them showing up in the git repository ...<div class="HOEnZb"><div class="h5"> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage <a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a> <a href="tel:%2B49%20911%2074053%20688" value="+4991174053688" target="_blank">+49 911 74053 688</a> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- dm-devel mailing list <a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/dm-devel" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a> </div></div></blockquote></div> </div>