[dm-devel] [PATCH 06/12] Make multipath add wwids from kernel cmdline mpath.wwids with -A

[Hannes Reinecke]

On 07/03/2014 09:25 PM, Benjamin Marzinski wrote:
> On Thu, Jul 03, 2014 at 01:05:37PM +0200, Hannes Reinecke wrote:
>> On 07/02/2014 09:48 PM, Benjamin Marzinski wrote:
>>> On Wed, Jul 02, 2014 at 08:03:38AM +0200, Hannes Reinecke wrote:
>>>> On 07/01/2014 09:22 PM, Christophe Varoqui wrote:
>>>>> Hannes,
>>>>>
>>>>> would you Ack this one, or do you have some other idea for this in
>>>>> your tree ?
>>>>>
>>>> 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.
>>>
>>> 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.
>>>
>> 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).
>
> '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.
>
Okay, I've send a patch.

>> 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.
>
> 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.
>
Oh, I don't have any objections to that, provided it's configurable
via the config file.
Care to send a patch for that?

>
>> 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 ...
>
> 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.
>
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 ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)