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

[Hannes Reinecke]

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

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.

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

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)