From patchwork Tue Feb 28 16:23:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Wilck X-Patchwork-Id: 9596217 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 29E8D60574 for ; Tue, 28 Feb 2017 16:25:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1C04126BE9 for ; Tue, 28 Feb 2017 16:25:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 112882853F; Tue, 28 Feb 2017 16:25:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B1AC926CF9 for ; Tue, 28 Feb 2017 16:25:39 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1SGOR3N038816; Tue, 28 Feb 2017 11:24:27 -0500 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v1SGNv93005825 for ; Tue, 28 Feb 2017 11:23:57 -0500 Received: by smtp.corp.redhat.com (Postfix) id 121A92D655; Tue, 28 Feb 2017 16:23:57 +0000 (UTC) Delivered-To: dm-devel@redhat.com Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0A87515A80 for ; Tue, 28 Feb 2017 16:23:57 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E6BE68047B for ; Tue, 28 Feb 2017 16:23:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B2BE5AD17 for ; Tue, 28 Feb 2017 16:23:51 +0000 (UTC) From: Martin Wilck To: dm-devel@redhat.com Date: Tue, 28 Feb 2017 17:23:12 +0100 Message-Id: <20170228162329.14517-17-mwilck@suse.com> In-Reply-To: <20170228162329.14517-1-mwilck@suse.com> References: <20170228162329.14517-1-mwilck@suse.com> X-Greylist: Sender passed SPF test, Sender IP whitelisted by DNSRBL, ACL 202 matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 28 Feb 2017 16:23:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 28 Feb 2017 16:23:56 +0000 (UTC) for IP:'195.135.220.15' DOMAIN:'mx2.suse.de' HELO:'mx2.suse.de' FROM:'mwilck@suse.com' RCPT:'' X-RedHat-Spam-Score: -1.901 (BAYES_50, DCC_REPUT_00_12, RCVD_IN_DNSWL_MED, SPF_PASS) 195.135.220.15 mx2.suse.de 195.135.220.15 mx2.suse.de X-Scanned-By: MIMEDefang 2.78 on 10.5.110.28 X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-loop: dm-devel@redhat.com Subject: [dm-devel] [PATCH 16/33] multipath: ignore -i if find_multipaths is set X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Virus-Scanned: ClamAV using ClamSMTP multipath's logic for detecing new multipath devices with find_multipaths currently doesn't work reliably. If paths for a new device are added sequentially, the first one will be classified as non-multpath (and passed on to systemd for further processing) while subsequent ones will be seen as multipath devices. If the paths are added simultaneously (such as at udev trigger time after switching from the initrd to the rootfs, if device detection is already finished), whether or not additional paths will be seen when the udev rules for a given paths are processed is random. A proper implementation of this device detection would require some sort of information passing between multipathd and multipath, timeouts waiting for additional paths to appear when a single one is detected, retriggering of uevents if the status of a given paths changes, and more fine-grained treatment of "orphaned" paths in multipathd. All of that is currently non-existent. Currently, our only option is to rely on the wwids file for device setup with find_multipaths. In practice, that means that multipath maps will only be set up for such devices that have been set up manually by the user before. This is the behavior of multipath [-c|-u] without the "-i" option. But "-i" is useful for the !find_multipaths case, where the expectation is that all non-blacklisted devices are multipathed by default. Because we can't change the multipath invocation in the udev rules file depending on the find_multipaths setting, just ignore "-i" if find_multipaths is set. Signed-off-by: Martin Wilck --- multipath/main.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/multipath/main.c b/multipath/main.c index 8ce87a08..ed57135a 100644 --- a/multipath/main.c +++ b/multipath/main.c @@ -619,6 +619,16 @@ main (int argc, char *argv[]) } } + /* + * FIXME: new device detection with find_multipaths currently + * doesn't work reliably. + */ + if (cmd == CMD_VALID_PATH && + conf->find_multipaths && conf->ignore_wwids) { + condlog(2, "ignoring -i flag because find_multipath is set in multipath.conf"); + conf->ignore_wwids = 0; + } + if (getuid() != 0) { fprintf(stderr, "need to be root\n"); exit(1);