From: Martin Wilck <mwilck@suse.com>
To: dm-devel@redhat.com, Benjamin Marzinski <bmarzins@redhat.com>,
Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 2/2] multipath: attempt at common multipath.rules
Date: Thu, 13 Apr 2017 17:27:04 +0200 [thread overview]
Message-ID: <1492097224.22602.12.camel@suse.com> (raw)
In-Reply-To: <1492035310-27525-3-git-send-email-bmarzins@redhat.com>
Hi Ben,
> This is a proposal to try and bring the Redhat and SuSE
> multipath.rules
> closer. There are a couple of changes that I'd like some input on.
Thanks for making this so explicit. Perhaps we should have done the
same for our recent changes, in particular d7188fcd "multipathd: start
daemon after udev trigger".
> The big change is moving the kpartx call into the multipath
> rules. Half
> of the current kpartx.rules file is about creating symlinks for
> multiple
> types of dm devices. The other half auto-creates kpartx devices on
> top
> of multipath devices. Since it is only creating kpartx devices on top
> of
> multipath devices, I've moved the these rules into multipath.rules,
> or
> rather, I've replaced them with the redhat rules in multipath.rules.
> The
> biggest difference is the kpartx isn't run on every reload. It works
> with the 11-dm-mpath.rules code to not run kpartx on multipathd
> generated reloads or when there aren't any working paths. It does
> remember if it didn't get to run kpartx when it was supposed to
> (because
> there were no valid paths or the device was suspended) and will make
> sure to run it on the next possible uevent.
>
> The other change is the redhat multipath rules remove the partition
> device nodes for devices claimed by multipath. The udev rule will
> only
> do this one time (both to keep from running partx on every event, and
> so
> that if users manually reread the partition table, we don't keep
> removing them when clearly they are wanted). Redhat does this because
> we
> had multiple customer issues where they were using the scsi
> partitions
> instead of the kpartx devices. Obviously, with setting the partition
> devices to not ready and clearing their fs_type, this isn't
> essential,
> but it has helped make customers do the right thing.
>
> Cc: Martin Wilck <mwilck@suse.com>
> Cc: Hannes Reinecke <hare@suse.de>
> Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> ---
> kpartx/kpartx.rules | 8 --------
> multipath/multipath.rules | 27 ++++++++++++++++++++++++---
> 2 files changed, 24 insertions(+), 11 deletions(-)
>
All of this makes sense to me. But I may not overlook all the possible
pitfalls in the udev rules, so please wait for Hannes' comments, too.
Regards
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2017-04-13 15:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-12 22:15 [PATCH 0/2] RFC: multipath proposals Benjamin Marzinski
2017-04-12 22:15 ` [PATCH 1/2] multipath: Merge the DELL MD3xxx device configs Benjamin Marzinski
2017-04-13 8:44 ` Johannes Thumshirn
2017-04-13 15:45 ` Benjamin Marzinski
2017-04-13 14:59 ` Martin Wilck
2017-05-07 0:32 ` Xose Vazquez Perez
2017-04-12 22:15 ` [PATCH 2/2] multipath: attempt at common multipath.rules Benjamin Marzinski
2017-04-13 15:27 ` Martin Wilck [this message]
2017-06-27 21:41 ` Martin Wilck
2017-06-28 13:00 ` Martin Wilck
2017-06-30 16:48 ` Benjamin Marzinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492097224.22602.12.camel@suse.com \
--to=mwilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.