Still tanked in my local git tree.
I'll push them online late this afternoon.
On Fri, Jul 4, 2014 at 8:24 AM, Hannes Reinecke <hare@xxxxxxx> wrote:
Okay, I've send a patch.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:Hmm. Similar to what I've seen here when booting with multipath enabled and
On 07/01/2014 09:22 PM, Christophe Varoqui wrote:
Hannes,Sigh. The whole multipath / systemd / dracut integration
would you Ack this one, or do you have some other idea for this in
your tree ?
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.
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.
Oh, I don't have any objections to that, provided it's configurable
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.
via the config file.
Care to send a patch for that?Ah, I've been luckier than you, then.
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.
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@xxxxxxx +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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
