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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 94F83C433ED for ; Tue, 27 Apr 2021 10:52:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B4C2613B0 for ; Tue, 27 Apr 2021 10:52:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235254AbhD0KxV (ORCPT ); Tue, 27 Apr 2021 06:53:21 -0400 Received: from mx4.uni-regensburg.de ([194.94.157.149]:36434 "EHLO mx4.uni-regensburg.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230365AbhD0KxU (ORCPT ); Tue, 27 Apr 2021 06:53:20 -0400 Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05756600004E for ; Tue, 27 Apr 2021 12:52:35 +0200 (CEST) Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 20327600005F for ; Tue, 27 Apr 2021 12:52:34 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 27 Apr 2021 12:52:34 +0200 Message-Id: <6087ECF1020000A100040C7F@gwsmtp.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 18.3.1 Date: Tue, 27 Apr 2021 12:52:33 +0200 From: "Ulrich Windl" To: , , , Cc: , , "systemd-devel@lists.freedesktop.org" , , , , Subject: Antw: [EXT] Re: [dm-devel] RFC: one more time: SCSI device identification References: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> <685c40341d2ddef2fe5a54dd656d10104b0c1bfa.camel@suse.com> <6086A0B2020000A100040BBE@gwsmtp.uni-regensburg.de> <59dc346de26997a6b8e3ae3d86d84ada60b3d26b.camel@suse.com> <15e1a6a493f55051eab844bab2a107f783dc27ee.camel@suse.com> <2a6903e4-ff2b-67d5-e772-6971db8448fb@suse.de> In-Reply-To: <2a6903e4-ff2b-67d5-e772-6971db8448fb@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org >>> Hannes Reinecke schrieb am 27.04.2021 um 10:21 in Nachricht <2a6903e4-ff2b-67d5-e772-6971db8448fb@suse.de>: > On 4/27/21 10:10 AM, Martin Wilck wrote: >> On Tue, 2021‑04‑27 at 13:48 +1000, Erwin van Londen wrote: >>>> >>>> Wrt 1), we can only hope that it's the case. But 2) and 3) need work, >>>> afaics. >>>> >>> In my view the WWID should never change. >> >> In an ideal world, perhaps not. But in the dm‑multipath realm, we know >> that WWID changes can happen with certain storage arrays. See >> https://listman.redhat.com/archives/dm‑devel/2021‑February/msg00116.html >> and follow‑ups, for example. >> > And it's actually something which might happen quite easily. > The storage array can unmap a LUN, delete it, create a new one, and map > that one into the same LUN number than the old one. > If we didn't do I/O during that interval upon the next I/O we will be > getting the dreaded 'Power‑On/Reset' sense code. > _And nothing else_, due to the arcane rules for sense code generation in > SAM. > But we end up with a completely different device. > > The only way out of it is to do a rescan for every POR sense code, and > disable the device eg via DID_NO_CONNECT whenever we find that the > identification has changed. We already have a copy of the original VPD > page 0x83 at hand, so that should be reasonably easy. I don't know the depth of the SCSI or FC protocol, but storage systems typically signal such events, maybe either via some unit attention or some FC event. Older kernels logged that there was a change, but a manual SCSI bus scan is needed, while newer kernels find new devices "automagically" for some products. The HP EVA 6000 series wored that way, a 3PAR SotorServ 8000 series also seems to work that way, but not Pure Storage X70 R3. FOr the latter you need something like a FC LIP to make the kernel detect the new devices (LUNs). I'm unsure where the problem is, but in principle the kernel can be notified... > > I had a rather lengthy discussion with Fred Knight @ NetApp about > Power‑On/Reset handling, what with him complaining that we don't handle > is correctly. So this really is something we should be looking into, > even independently of multipathing. > > But actually I like the idea from Martin Petersen to expose the parsed > VPD identifiers to sysfs; that would allow us to drop sg_inq completely > from the udev rules. Talking of VPDs: Somewhere in the last 12 years (within SLES 11)there was a kernel change regarding trailing blanks in VPD data. That change blew up several configurations being unable to re-recognize the devices. In one case the software even had bound a license to a specific device with serial number, and that software found "new" devices while missing the "old" ones... Regards, Ulrich > > Cheers, > > Hannes > ‑‑ > Dr. Hannes Reinecke Kernel Storage Architect > hare@suse.de +49 911 74053 688 > SUSE Software Solutions Germany GmbH, 90409 Nürnberg > GF: F. Imendörffer, HRB 36809 (AG Nürnberg) 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 810CFC433B4 for ; Tue, 27 Apr 2021 10:57:17 +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 35427613BF for ; Tue, 27 Apr 2021 10:57:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35427613BF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rz.uni-regensburg.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-203-KUCaKCjyPjO6KmVBPwSB4g-1; Tue, 27 Apr 2021 06:57:12 -0400 X-MC-Unique: KUCaKCjyPjO6KmVBPwSB4g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 857C61898296; Tue, 27 Apr 2021 10:57:06 +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 421816A8EA; Tue, 27 Apr 2021 10:57:05 +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 777CA1806D1B; Tue, 27 Apr 2021 10:57:01 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 13RAqgA0007419 for ; Tue, 27 Apr 2021 06:52:42 -0400 Received: by smtp.corp.redhat.com (Postfix) id 8084851E1; Tue, 27 Apr 2021 10:52:42 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AE354404A for ; Tue, 27 Apr 2021 10:52:40 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.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 2FD02857A86 for ; Tue, 27 Apr 2021 10:52:40 +0000 (UTC) Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [194.94.157.148]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-278-lEIJlAM9NnuusqKSWmZRyg-1; Tue, 27 Apr 2021 06:52:37 -0400 X-MC-Unique: lEIJlAM9NnuusqKSWmZRyg-1 Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 71932600004D for ; Tue, 27 Apr 2021 12:52:35 +0200 (CEST) Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id 49E1C600005E for ; Tue, 27 Apr 2021 12:52:34 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 27 Apr 2021 12:52:34 +0200 Message-Id: <6087ECF1020000A100040C7F@gwsmtp.uni-regensburg.de> Date: Tue, 27 Apr 2021 12:52:33 +0200 From: "Ulrich Windl" To: , , , References: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> <685c40341d2ddef2fe5a54dd656d10104b0c1bfa.camel@suse.com> <6086A0B2020000A100040BBE@gwsmtp.uni-regensburg.de> <59dc346de26997a6b8e3ae3d86d84ada60b3d26b.camel@suse.com> <15e1a6a493f55051eab844bab2a107f783dc27ee.camel@suse.com> <2a6903e4-ff2b-67d5-e772-6971db8448fb@suse.de> In-Reply-To: <2a6903e4-ff2b-67d5-e772-6971db8448fb@suse.de> Mime-Version: 1.0 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.79 on 10.11.54.5 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 13RAqgA0007419 X-loop: dm-devel@redhat.com Cc: hare@suse.com, "systemd-devel@lists.freedesktop.org" , linux-scsi@vger.kernel.org, dm-devel@redhat.com, dgilbert@interlog.com, jejb@linux.vnet.ibm.com, hch@lst.de Subject: [dm-devel] Antw: [EXT] Re: RFC: one more time: SCSI device identification 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.15 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="utf-8" Content-Transfer-Encoding: base64 Pj4+IEhhbm5lcyBSZWluZWNrZSA8aGFyZUBzdXNlLmRlPiBzY2hyaWViIGFtIDI3LjA0LjIwMjEg dW0gMTA6MjEgaW4gTmFjaHJpY2h0CjwyYTY5MDNlNC1mZjJiLTY3ZDUtZTc3Mi02OTcxZGI4NDQ4 ZmJAc3VzZS5kZT46Cj4gT24gNC8yNy8yMSAxMDoxMCBBTSwgTWFydGluIFdpbGNrIHdyb3RlOgo+ PiBPbiBUdWUsIDIwMjHigJEwNOKAkTI3IGF0IDEzOjQ4ICsxMDAwLCBFcndpbiB2YW4gTG9uZGVu IHdyb3RlOgo+Pj4+Cj4+Pj4gV3J0IDEpLCB3ZSBjYW4gb25seSBob3BlIHRoYXQgaXQncyB0aGUg Y2FzZS4gQnV0IDIpIGFuZCAzKSBuZWVkIHdvcmssCj4+Pj4gYWZhaWNzLgo+Pj4+Cj4+PiBJbiBt eSB2aWV3IHRoZSBXV0lEIHNob3VsZCBuZXZlciBjaGFuZ2UuIAo+PiAKPj4gSW4gYW4gaWRlYWwg d29ybGQsIHBlcmhhcHMgbm90LiBCdXQgaW4gdGhlIGRt4oCRbXVsdGlwYXRoIHJlYWxtLCB3ZSBr bm93Cj4+IHRoYXQgV1dJRCBjaGFuZ2VzIGNhbiBoYXBwZW4gd2l0aCBjZXJ0YWluIHN0b3JhZ2Ug YXJyYXlzLiBTZWUgCj4+IGh0dHBzOi8vbGlzdG1hbi5yZWRoYXQuY29tL2FyY2hpdmVzL2Rt4oCR ZGV2ZWwvMjAyMeKAkUZlYnJ1YXJ5L21zZzAwMTE2Lmh0bWwgCj4+IGFuZCBmb2xsb3figJF1cHMs IGZvciBleGFtcGxlLgo+PiAKPiBBbmQgaXQncyBhY3R1YWxseSBzb21ldGhpbmcgd2hpY2ggbWln aHQgaGFwcGVuIHF1aXRlIGVhc2lseS4KPiBUaGUgc3RvcmFnZSBhcnJheSBjYW4gdW5tYXAgYSBM VU4sIGRlbGV0ZSBpdCwgY3JlYXRlIGEgbmV3IG9uZSwgYW5kIG1hcAo+IHRoYXQgb25lIGludG8g dGhlIHNhbWUgTFVOIG51bWJlciB0aGFuIHRoZSBvbGQgb25lLgo+IElmIHdlIGRpZG4ndCBkbyBJ L08gZHVyaW5nIHRoYXQgaW50ZXJ2YWwgdXBvbiB0aGUgbmV4dCBJL08gd2Ugd2lsbCBiZQo+IGdl dHRpbmcgdGhlIGRyZWFkZWQgJ1Bvd2Vy4oCRT24vUmVzZXQnIHNlbnNlIGNvZGUuCj4gX0FuZCBu b3RoaW5nIGVsc2VfLCBkdWUgdG8gdGhlIGFyY2FuZSBydWxlcyBmb3Igc2Vuc2UgY29kZSBnZW5l cmF0aW9uIGluCj4gU0FNLgo+IEJ1dCB3ZSBlbmQgdXAgd2l0aCBhIGNvbXBsZXRlbHkgZGlmZmVy ZW50IGRldmljZS4KPiAKPiBUaGUgb25seSB3YXkgb3V0IG9mIGl0IGlzIHRvIGRvIGEgcmVzY2Fu IGZvciBldmVyeSBQT1Igc2Vuc2UgY29kZSwgYW5kCj4gZGlzYWJsZSB0aGUgZGV2aWNlIGVnIHZp YSBESURfTk9fQ09OTkVDVCB3aGVuZXZlciB3ZSBmaW5kIHRoYXQgdGhlCj4gaWRlbnRpZmljYXRp b24gaGFzIGNoYW5nZWQuIFdlIGFscmVhZHkgaGF2ZSBhIGNvcHkgb2YgdGhlIG9yaWdpbmFsIFZQ RAo+IHBhZ2UgMHg4MyBhdCBoYW5kLCBzbyB0aGF0IHNob3VsZCBiZSByZWFzb25hYmx5IGVhc3ku CgpJIGRvbid0IGtub3cgdGhlIGRlcHRoIG9mIHRoZSBTQ1NJIG9yIEZDIHByb3RvY29sLCBidXQg c3RvcmFnZSBzeXN0ZW1zCnR5cGljYWxseSBzaWduYWwgc3VjaCBldmVudHMsIG1heWJlIGVpdGhl ciB2aWEgc29tZSB1bml0IGF0dGVudGlvbiBvciBzb21lIEZDCmV2ZW50LiBPbGRlciBrZXJuZWxz IGxvZ2dlZCB0aGF0IHRoZXJlIHdhcyBhIGNoYW5nZSwgYnV0IGEgbWFudWFsIFNDU0kgYnVzIHNj YW4KaXMgbmVlZGVkLCB3aGlsZSBuZXdlciBrZXJuZWxzIGZpbmQgbmV3IGRldmljZXMgImF1dG9t YWdpY2FsbHkiIGZvciBzb21lCnByb2R1Y3RzLiBUaGUgSFAgRVZBIDYwMDAgc2VyaWVzIHdvcmVk IHRoYXQgd2F5LCBhIDNQQVIgU290b3JTZXJ2IDgwMDAgc2VyaWVzCmFsc28gc2VlbXMgdG8gd29y ayB0aGF0IHdheSwgYnV0IG5vdCBQdXJlIFN0b3JhZ2UgWDcwIFIzLiBGT3IgdGhlIGxhdHRlciB5 b3UKbmVlZCBzb21ldGhpbmcgbGlrZSBhIEZDIExJUCB0byBtYWtlIHRoZSBrZXJuZWwgZGV0ZWN0 IHRoZSBuZXcgZGV2aWNlcyAoTFVOcykuCkknbSB1bnN1cmUgd2hlcmUgdGhlIHByb2JsZW0gaXMs IGJ1dCBpbiBwcmluY2lwbGUgdGhlIGtlcm5lbCBjYW4gYmUKbm90aWZpZWQuLi4KCj4gCj4gSSBo YWQgYSByYXRoZXIgbGVuZ3RoeSBkaXNjdXNzaW9uIHdpdGggRnJlZCBLbmlnaHQgQCBOZXRBcHAg YWJvdXQKPiBQb3dlcuKAkU9uL1Jlc2V0IGhhbmRsaW5nLCB3aGF0IHdpdGggaGltIGNvbXBsYWlu aW5nIHRoYXQgd2UgZG9uJ3QgaGFuZGxlCj4gaXMgY29ycmVjdGx5LiBTbyB0aGlzIHJlYWxseSBp cyBzb21ldGhpbmcgd2Ugc2hvdWxkIGJlIGxvb2tpbmcgaW50bywKPiBldmVuIGluZGVwZW5kZW50 bHkgb2YgbXVsdGlwYXRoaW5nLgo+IAo+IEJ1dCBhY3R1YWxseSBJIGxpa2UgdGhlIGlkZWEgZnJv bSBNYXJ0aW4gUGV0ZXJzZW4gdG8gZXhwb3NlIHRoZSBwYXJzZWQKPiBWUEQgaWRlbnRpZmllcnMg dG8gc3lzZnM7IHRoYXQgd291bGQgYWxsb3cgdXMgdG8gZHJvcCBzZ19pbnEgY29tcGxldGVseQo+ IGZyb20gdGhlIHVkZXYgcnVsZXMuCgpUYWxraW5nIG9mIFZQRHM6IFNvbWV3aGVyZSBpbiB0aGUg bGFzdCAxMiB5ZWFycyAod2l0aGluIFNMRVMgMTEpdGhlcmUgd2FzIGEKa2VybmVsIGNoYW5nZSBy ZWdhcmRpbmcgdHJhaWxpbmcgYmxhbmtzIGluIFZQRCBkYXRhLiBUaGF0IGNoYW5nZSBibGV3IHVw CnNldmVyYWwgY29uZmlndXJhdGlvbnMgYmVpbmcgdW5hYmxlIHRvIHJlLXJlY29nbml6ZSB0aGUg ZGV2aWNlcy4gSW4gb25lIGNhc2UKdGhlIHNvZnR3YXJlIGV2ZW4gaGFkIGJvdW5kIGEgbGljZW5z ZSB0byBhIHNwZWNpZmljIGRldmljZSB3aXRoIHNlcmlhbCBudW1iZXIsCmFuZCB0aGF0IHNvZnR3 YXJlIGZvdW5kICJuZXciIGRldmljZXMgd2hpbGUgbWlzc2luZyB0aGUgIm9sZCIgb25lcy4uLgoK UmVnYXJkcywKVWxyaWNoCgo+IAo+IENoZWVycywKPiAKPiBIYW5uZXMKPiDigJHigJEgCj4gRHIu IEhhbm5lcyBSZWluZWNrZQkJICAgICAgICBLZXJuZWwgU3RvcmFnZSBBcmNoaXRlY3QKPiBoYXJl QHN1c2UuZGUJCQkgICAgICAgICAgICAgICArNDkgOTExIDc0MDUzIDY4OAo+IFNVU0UgU29mdHdh cmUgU29sdXRpb25zIEdlcm1hbnkgR21iSCwgOTA0MDkgTsO8cm5iZXJnCj4gR0Y6IEYuIEltZW5k w7ZyZmZlciwgSFJCIDM2ODA5IChBRyBOw7xybmJlcmcpCgoKCgotLQpkbS1kZXZlbCBtYWlsaW5n IGxpc3QKZG0tZGV2ZWxAcmVkaGF0LmNvbQpodHRwczovL2xpc3RtYW4ucmVkaGF0LmNvbS9tYWls bWFuL2xpc3RpbmZvL2RtLWRldmVs