From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F54EC11F64 for ; Thu, 1 Jul 2021 08:01:34 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D370D6148E for ; Thu, 1 Jul 2021 08:01:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D370D6148E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-469-ZH05U2qiPfaFp9qhKaWnlA-1; Thu, 01 Jul 2021 04:01:31 -0400 X-MC-Unique: ZH05U2qiPfaFp9qhKaWnlA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E518B101F002; Thu, 1 Jul 2021 08:01:25 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BE735DA60; Thu, 1 Jul 2021 08:01:24 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id CCD591809C98; Thu, 1 Jul 2021 08:01:21 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1617ufqZ002049 for ; Thu, 1 Jul 2021 03:56:41 -0400 Received: by smtp.corp.redhat.com (Postfix) id 190682012E3E; Thu, 1 Jul 2021 07:56:41 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1523220285B7 for ; Thu, 1 Jul 2021 07:56:38 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 750CC18812C5 for ; Thu, 1 Jul 2021 07:56:38 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-418-2bwyaovNNWWEGTGMJ0-77Q-1; Thu, 01 Jul 2021 03:56:33 -0400 X-MC-Unique: 2bwyaovNNWWEGTGMJ0-77Q-1 Received: by verein.lst.de (Postfix, from userid 2407) id 52AB16736F; Thu, 1 Jul 2021 09:56:30 +0200 (CEST) Date: Thu, 1 Jul 2021 09:56:29 +0200 From: Christoph Hellwig To: mwilck@suse.com Message-ID: <20210701075629.GA25768@lst.de> References: <20210628151558.2289-1-mwilck@suse.com> <20210628151558.2289-4-mwilck@suse.com> MIME-Version: 1.0 In-Reply-To: <20210628151558.2289-4-mwilck@suse.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com Cc: Mike Snitzer , linux-scsi@vger.kernel.org, Daniel Wagner , emilne@redhat.com, linux-block@vger.kernel.org, dm-devel@redhat.com, Paolo Bonzini , "Martin K. Petersen" , nkoenig@redhat.com, Bart Van Assche , Christoph Hellwig , Alasdair G Kergon Subject: Re: [dm-devel] [PATCH v5 3/3] dm mpath: add CONFIG_DM_MULTIPATH_SG_IO - failover for SG_IO 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: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Jun 28, 2021 at 05:15:58PM +0200, mwilck@suse.com wrote: > The qemu "pr-helper" was specifically invented for it. I > believe that this is the most important real-world scenario for sending > SG_IO ioctls to device-mapper devices. pr-helper obviously does not SG_IO on dm-multipath as that simply does not work. More importantly - if you want to use persistent reservations use the kernel ioctls for that. These work on SCSI, NVMe and device mapper without any extra magic. Failing over SG_IO does not make sense. It is an interface specically designed to leave all error handling to the userspace program using it, and we should not change that for one specific error case. If you want the kernel to handle errors for you, use the proper interfaces. In this case this is the persistent reservation ioctls. If they miss some features that qemu needs we should add those. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13335C11F6A for ; Thu, 1 Jul 2021 07:56:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F17F96148E for ; Thu, 1 Jul 2021 07:56:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234953AbhGAH7F (ORCPT ); Thu, 1 Jul 2021 03:59:05 -0400 Received: from verein.lst.de ([213.95.11.211]:46690 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234576AbhGAH7E (ORCPT ); Thu, 1 Jul 2021 03:59:04 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 52AB16736F; Thu, 1 Jul 2021 09:56:30 +0200 (CEST) Date: Thu, 1 Jul 2021 09:56:29 +0200 From: Christoph Hellwig To: mwilck@suse.com Cc: Mike Snitzer , Alasdair G Kergon , Bart Van Assche , "Martin K. Petersen" , linux-scsi@vger.kernel.org, dm-devel@redhat.com, Hannes Reinecke , Christoph Hellwig , Daniel Wagner , linux-block@vger.kernel.org, Paolo Bonzini , Benjamin Marzinski , nkoenig@redhat.com, emilne@redhat.com Subject: Re: [PATCH v5 3/3] dm mpath: add CONFIG_DM_MULTIPATH_SG_IO - failover for SG_IO Message-ID: <20210701075629.GA25768@lst.de> References: <20210628151558.2289-1-mwilck@suse.com> <20210628151558.2289-4-mwilck@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210628151558.2289-4-mwilck@suse.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Mon, Jun 28, 2021 at 05:15:58PM +0200, mwilck@suse.com wrote: > The qemu "pr-helper" was specifically invented for it. I > believe that this is the most important real-world scenario for sending > SG_IO ioctls to device-mapper devices. pr-helper obviously does not SG_IO on dm-multipath as that simply does not work. More importantly - if you want to use persistent reservations use the kernel ioctls for that. These work on SCSI, NVMe and device mapper without any extra magic. Failing over SG_IO does not make sense. It is an interface specically designed to leave all error handling to the userspace program using it, and we should not change that for one specific error case. If you want the kernel to handle errors for you, use the proper interfaces. In this case this is the persistent reservation ioctls. If they miss some features that qemu needs we should add those.