On 04/28/2016 12:46 AM, Benjamin Marzinski wrote:
> On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote:
>> On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote:
>>> On 04/25/2016 02:56 PM, Christophe Varoqui wrote:
>>>
>>>> Those example udev rules are indeed unmaintained and should be
>>>> removed not to confuse distributors.
>>>>
>>>> Distributors can't be asked to agree on a common udev ruleset.
>>>> Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ?
>>>
>>> Fine with me.
>>>
>>> Btw, are these relevant ?
>
> For all that I didn't comment on, I feel the same way as Hannes.
>
>>> getuid/usb_id
>> Huh? What is that doing there?
>> It should really have been moved to the udev package ...
>>
>>> kpartx/kpartx_id
>>> kpartx/kpartx.rules
>> See above. Yes, they are relevant (at least for us)
>
> Like I said, Red Hat doesn't use them. I'll post our multipath.rules
> shortly.
>
Which would be cool.
I was actually hoping to meet you in Raleigh last week, but then it
didn't work out.
>>> multipath/01_udev
>>> multipath/02_multipath
>> Not used anymore with systemd/dracut
>>
>>> multipath/11-dm-mpath.rules
>> Yep. Absolutely required.
>>
>>> multipath.conf.annotated
>>> multipath.conf.defaults
>>> multipath.conf.synthetic
>> Actually, I never saw the need for those.
>> Can we at least have them merged?
>
> I don't think they are being kept up to date anymore. The 'defaults'
> information can be gotten from a running system, and it includes the
> changes from the config files, so it's much more useful. I have no idea
> what people would use 'synthetic' for besides an example of what a
> config would look like. And the 'annotated' information is all in the
> multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be
> happy to see them go.
>
Couldn't agree more.
Let's drop them.
>>> multipathd/multipathd.init.debian
>>> multipathd/multipathd.init.redhat
>>> multipathd/multipathd.init.suse
>> Old init scripts; doubtful value.
>>
>>> multipathd/multipathd.service
>>> multipathd/multipathd.socket
>> systemd service definitions. Yes, required.
>
> Red Hat has a slightly different multipathd.service file, and we don't
> ship the socket file. Since multipathd should always be running, I
> don't really see the need. Also, if you start multipathd manually
> (instead of through udev) this causes problems with multipathd not
> getting messages.
>
Hmm. Actually, I quite like the systemd integration; it allows me to
signal the internal multipathd state back to systemd:
# systemctl status multipathd
multipathd.service - Device-Mapper Multipath Device Controller
Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled)
Active: active (running) since Wed 2016-04-27 12:39:59 CEST; 19h ago
Main PID: 6913 (multipathd)
Status: "idle"
CGroup: /system.slice/multipathd.service
└─6913 /sbin/multipathd -d -s
Which I find quite neat. And I guess we should be able to overcome
the manually started issue by checking if the socket is present, and
just execute a 'reconfigure' command if so.
Let me see ...
> For those interested, here's a diff of our multipath.service
>
> diff --git a/multipathd/multipathd.service
> b/multipathd/multipathd.service
> index d5f8606..1e5dfab 100644
> --- a/multipathd/multipathd.service
> +++ b/multipathd/multipathd.service
> @@ -2,9 +2,10 @@
> Description=Device-Mapper Multipath Device Controller
> Before=iscsi.service iscsid.service lvm2-activation-early.service
> Before=local-fs-pre.target
> -After=multipathd.socket
> +ConditionPathExists=/etc/multipath.conf
> +ConditionKernelCommandLine=!nompath
> DefaultDependencies=no
> -Wants=local-fs-pre.target multipathd.socket blk-availability.service
> +Wants=local-fs-pre.target blk-availability.service
> Conflicts=shutdown.target
>
> [Service]
> @@ -12,9 +13,9 @@ Type=notify
> NotifyAccess=main
> LimitCORE=infinity
> ExecStartPre=/sbin/modprobe dm-multipath
> +ExecStartPre=-/sbin/multipath -A
> ExecStart=/sbin/multipathd -d -s
> ExecReload=/sbin/multipathd reconfigure
>
> [Install]
> WantedBy=sysinit.target
> -Also=multipathd.socket
>
>
> Aside from dropping the socket, it checks that /etc/multipath.conf
> exists, and that the kernel wasn't started with "nompath". Also it runs
> "multipath -A" this reads the kernel commandline from /proc/cmdline, and
> adds any wwids listed as part of any mpath.wwid=<wwid> parameters.
> Hannes NACKed this patch, so the option isn't present upsteam.
>
>
Hmm. Actually, I do like the 'nompath' checking; we do lack the
capability of switching off multipath from the kernel commandline
ATM. So yes, we should be including that bit.
As for /etc/multipath.conf ... The original setup has been shipping
without any multipath.conf file. So I would be okay with this change
if we can guarantee that /etc/multipath.conf will always be existing.
Seeing that you're running 'multipath -A' to add any wwids, wouldn't
that be sufficient?
IE why do we need the check for /etc/multipath.conf here; couldn't
we make 'multipath -A' return non-zero to avoid multipathd to be
started?
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
