From: Erwin van Londen <erwin@erwinvanlonden.net> To: Martin Wilck <martin.wilck@suse.com>, "hare@suse.de" <hare@suse.de>, "Ulrich.Windl@rz.uni-regensburg.de" <Ulrich.Windl@rz.uni-regensburg.de>, "martin.petersen@oracle.com" <martin.petersen@oracle.com> Cc: "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "dgilbert@interlog.com" <dgilbert@interlog.com>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "systemd-devel@lists.freedesktop.org" <systemd-devel@lists.freedesktop.org>, Hannes Reinecke <hare@suse.com>, "hch@lst.de" <hch@lst.de> Subject: Re: [dm-devel] RFC: one more time: SCSI device identification Date: Fri, 30 Apr 2021 00:47:57 +1000 [thread overview] Message-ID: <d26cbf916bbff974cda28536b128129ea3a0f13b.camel@erwinvanlonden.net> (raw) In-Reply-To: <643e5f7eb3e2d48517a3288c07af001b30e22075.camel@suse.com> On Wed, 2021-04-28 at 06:34 +0000, Martin Wilck wrote: > On Wed, 2021-04-28 at 11:01 +1000, Erwin van Londen wrote: > > > > The way out of this is to chuck the array in the bin. As I mentioned > > in one of my other emails when a scenario happens as you described > > above and the array does not inform the initiator it goes against the > > SAM-5 standard. > > > > That standard shows: > > 5.14 Unit attention conditions > > 5.14.1 Unit attention conditions that are not coalesced > > Each logical unit shall establish a unit attention condition whenever > > one of the following events occurs: > > a) a power on (see 6.3.1), hard reset (see 6.3.2), logical > > unit reset (see 6.3.3), I_T nexus loss (see 6.3.4), or power loss > > expected (see 6.3.5) occurs; > > b) commands received on this I_T nexus have been cleared by > > a command or a task management function associated with another I_T > > nexus and the TAS bit was set to zero in the Control mode page > > associated with this I_T nexus (see 5.6); > > c) the portion of the logical unit inventory that consists > > of administrative logical units and hierarchical logical units has > > been changed (see 4.6.18.1); or > > d) any other event requiring the attention of the SCSI > > initiator device. > > > > Especially the I_T nexus loss under a is an important trigger. > > > > --- > > 6.3.4 I_T nexus loss > > An I_T nexus loss is a SCSI device condition resulting from: > > > > a) a hard reset condition (see 6.3.2); > > b) an I_T nexus loss event (e.g., logout) indicated by a Nexus Loss > > event notification (see 6.4); > > c) indication that an I_T NEXUS RESET task management request (see > > 7.6) has been processed; or > > d) an indication that a REMOVE I_T NEXUS command (see SPC-4) has > > been processed. > > An I_T nexus loss event is an indication from the SCSI transport > > protocol to the SAL that an I_T nexus no > > longer exists. SCSI transport protocols may define I_T nexus loss > > events. > > > > Each SCSI transport protocol standard that defines I_T nexus loss > > events should specify when those events > > result in the delivery of a Nexus Loss event notification to the SAL. > > > > The I_T nexus loss condition applies to both SCSI initiator devices > > and SCSI target devices. > > > > If a SCSI target port detects an I_T nexus loss, then a Nexus Loss > > event notification shall be delivered to > > each logical unit to which the I_T nexus has access. > > > > In response to an I_T nexus loss condition a logical unit shall take > > the following actions: > > a) abort all commands received on the I_T nexus as described in 5.6; > > b) abort all background third-party copy operations (see SPC-4) that > > are using the I_T nexus; > > c) terminate all task management functions received on the I_T nexus; > > d) clear all ACA conditions (see 5.9.5) associated with the I_T > > nexus; > > e) establish a unit attention condition for the SCSI initiator port > > associated with the I_T nexus (see 5.14 > > and 6.2); and > > f) perform any additional functions required by the applicable > > command standards. > > --- > > > > This does also mean that any underlying transport protocol issues > > like on FC or TCP for iSCSI will very often trigger aborted commands > > or UA's as well which will be picked up by the kernel/respected > > drivers. > > Thanks a lot. I'm not quite certain which of these paragraphs would > apply to the situation I had in mind (administrator remapping an > existing LUN on a storage array to a different volume). That scenario > wouldn't necessarily involve transport-level errors, or an I_T nexus > loss. 5.14.1 c) or d) might apply, is that what you meant? I was indeed mostly referring to: c) the portion of the logical unit inventory that consists of administrative logical units and hierarchical logical units has been changed (see 4.6.18.1); or d) any other event requiring the attention of the SCSI initiator device. The IT nexus status itself might not have changed but if an abstraction layer representing a totally different set of data that would most definitely fall under d. I think swapping between a volume and one of its snapshots also falls under this > > Regards > Martin >
WARNING: multiple messages have this Message-ID (diff)
From: Erwin van Londen <erwin@erwinvanlonden.net> To: Martin Wilck <martin.wilck@suse.com>, "hare@suse.de" <hare@suse.de>, "Ulrich.Windl@rz.uni-regensburg.de" <Ulrich.Windl@rz.uni-regensburg.de>, "martin.petersen@oracle.com" <martin.petersen@oracle.com> Cc: Hannes Reinecke <hare@suse.com>, "systemd-devel@lists.freedesktop.org" <systemd-devel@lists.freedesktop.org>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "dgilbert@interlog.com" <dgilbert@interlog.com>, "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "hch@lst.de" <hch@lst.de> Subject: Re: [dm-devel] RFC: one more time: SCSI device identification Date: Fri, 30 Apr 2021 00:47:57 +1000 [thread overview] Message-ID: <d26cbf916bbff974cda28536b128129ea3a0f13b.camel@erwinvanlonden.net> (raw) In-Reply-To: <643e5f7eb3e2d48517a3288c07af001b30e22075.camel@suse.com> On Wed, 2021-04-28 at 06:34 +0000, Martin Wilck wrote: > On Wed, 2021-04-28 at 11:01 +1000, Erwin van Londen wrote: > > > > The way out of this is to chuck the array in the bin. As I mentioned > > in one of my other emails when a scenario happens as you described > > above and the array does not inform the initiator it goes against the > > SAM-5 standard. > > > > That standard shows: > > 5.14 Unit attention conditions > > 5.14.1 Unit attention conditions that are not coalesced > > Each logical unit shall establish a unit attention condition whenever > > one of the following events occurs: > > a) a power on (see 6.3.1), hard reset (see 6.3.2), logical > > unit reset (see 6.3.3), I_T nexus loss (see 6.3.4), or power loss > > expected (see 6.3.5) occurs; > > b) commands received on this I_T nexus have been cleared by > > a command or a task management function associated with another I_T > > nexus and the TAS bit was set to zero in the Control mode page > > associated with this I_T nexus (see 5.6); > > c) the portion of the logical unit inventory that consists > > of administrative logical units and hierarchical logical units has > > been changed (see 4.6.18.1); or > > d) any other event requiring the attention of the SCSI > > initiator device. > > > > Especially the I_T nexus loss under a is an important trigger. > > > > --- > > 6.3.4 I_T nexus loss > > An I_T nexus loss is a SCSI device condition resulting from: > > > > a) a hard reset condition (see 6.3.2); > > b) an I_T nexus loss event (e.g., logout) indicated by a Nexus Loss > > event notification (see 6.4); > > c) indication that an I_T NEXUS RESET task management request (see > > 7.6) has been processed; or > > d) an indication that a REMOVE I_T NEXUS command (see SPC-4) has > > been processed. > > An I_T nexus loss event is an indication from the SCSI transport > > protocol to the SAL that an I_T nexus no > > longer exists. SCSI transport protocols may define I_T nexus loss > > events. > > > > Each SCSI transport protocol standard that defines I_T nexus loss > > events should specify when those events > > result in the delivery of a Nexus Loss event notification to the SAL. > > > > The I_T nexus loss condition applies to both SCSI initiator devices > > and SCSI target devices. > > > > If a SCSI target port detects an I_T nexus loss, then a Nexus Loss > > event notification shall be delivered to > > each logical unit to which the I_T nexus has access. > > > > In response to an I_T nexus loss condition a logical unit shall take > > the following actions: > > a) abort all commands received on the I_T nexus as described in 5.6; > > b) abort all background third-party copy operations (see SPC-4) that > > are using the I_T nexus; > > c) terminate all task management functions received on the I_T nexus; > > d) clear all ACA conditions (see 5.9.5) associated with the I_T > > nexus; > > e) establish a unit attention condition for the SCSI initiator port > > associated with the I_T nexus (see 5.14 > > and 6.2); and > > f) perform any additional functions required by the applicable > > command standards. > > --- > > > > This does also mean that any underlying transport protocol issues > > like on FC or TCP for iSCSI will very often trigger aborted commands > > or UA's as well which will be picked up by the kernel/respected > > drivers. > > Thanks a lot. I'm not quite certain which of these paragraphs would > apply to the situation I had in mind (administrator remapping an > existing LUN on a storage array to a different volume). That scenario > wouldn't necessarily involve transport-level errors, or an I_T nexus > loss. 5.14.1 c) or d) might apply, is that what you meant? I was indeed mostly referring to: c) the portion of the logical unit inventory that consists of administrative logical units and hierarchical logical units has been changed (see 4.6.18.1); or d) any other event requiring the attention of the SCSI initiator device. The IT nexus status itself might not have changed but if an abstraction layer representing a totally different set of data that would most definitely fall under d. I think swapping between a volume and one of its snapshots also falls under this > > Regards > Martin > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-04-29 23:56 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-29 9:58 RFC: one more time: SCSI device identification Martin Wilck 2021-03-29 9:58 ` [dm-devel] " Martin Wilck 2021-04-06 4:47 ` Martin K. Petersen 2021-04-06 4:47 ` [dm-devel] " Martin K. Petersen 2021-04-16 23:28 ` Martin Wilck 2021-04-16 23:28 ` [dm-devel] " Martin Wilck 2021-04-22 2:46 ` Martin K. Petersen 2021-04-22 2:46 ` [dm-devel] " Martin K. Petersen 2021-04-22 9:07 ` Martin Wilck 2021-04-22 9:07 ` [dm-devel] " Martin Wilck 2021-04-22 16:14 ` Benjamin Marzinski 2021-04-22 16:14 ` [dm-devel] " Benjamin Marzinski 2021-04-23 1:40 ` Martin K. Petersen 2021-04-23 1:40 ` [dm-devel] " Martin K. Petersen 2021-04-23 10:28 ` Martin Wilck 2021-04-23 10:28 ` [dm-devel] " Martin Wilck 2021-04-26 11:14 ` Antw: [EXT] Re: [systemd-devel] " Ulrich Windl 2021-04-26 11:14 ` [dm-devel] " Ulrich Windl 2021-04-26 13:16 ` Martin Wilck 2021-04-26 13:16 ` [dm-devel] " Martin Wilck 2021-04-27 3:48 ` Erwin van Londen 2021-04-27 7:02 ` Antw: [EXT] " Ulrich Windl 2021-04-27 7:02 ` [dm-devel] Antw: [EXT] " Ulrich Windl 2021-04-27 8:10 ` [dm-devel] " Martin Wilck 2021-04-27 8:10 ` Martin Wilck 2021-04-27 8:21 ` Hannes Reinecke 2021-04-27 8:21 ` Hannes Reinecke 2021-04-27 10:52 ` Antw: [EXT] " Ulrich Windl 2021-04-27 10:52 ` [dm-devel] Antw: [EXT] " Ulrich Windl 2021-04-27 20:04 ` Antw: [EXT] Re: [dm-devel] " Ewan D. Milne 2021-04-27 20:04 ` [dm-devel] Antw: [EXT] " Ewan D. Milne 2021-05-04 7:32 ` Antw: [EXT] Re: [dm-devel] " Hannes Reinecke 2021-05-04 7:32 ` [dm-devel] Antw: [EXT] " Hannes Reinecke 2021-04-28 1:01 ` [dm-devel] " Erwin van Londen 2021-04-28 6:34 ` Martin Wilck 2021-04-28 6:34 ` Martin Wilck 2021-04-29 14:47 ` Erwin van Londen [this message] 2021-04-29 14:47 ` Erwin van Londen 2021-04-27 20:14 ` Ewan D. Milne 2021-04-27 20:14 ` [dm-devel] " Ewan D. Milne 2021-04-27 20:33 ` Martin Wilck 2021-04-27 20:33 ` [dm-devel] " Martin Wilck 2021-04-27 20:41 ` Ewan D. Milne 2021-04-27 20:41 ` [dm-devel] " Ewan D. Milne 2021-04-28 0:09 ` Erwin van Londen 2021-04-30 23:44 ` Ewan D. Milne 2021-05-03 2:34 ` Erwin van Londen 2021-05-03 2:34 ` Erwin van Londen 2021-04-28 6:30 ` [systemd-devel] " Martin Wilck 2021-04-28 6:30 ` [dm-devel] " Martin Wilck
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=d26cbf916bbff974cda28536b128129ea3a0f13b.camel@erwinvanlonden.net \ --to=erwin@erwinvanlonden.net \ --cc=Ulrich.Windl@rz.uni-regensburg.de \ --cc=dgilbert@interlog.com \ --cc=dm-devel@redhat.com \ --cc=hare@suse.com \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=jejb@linux.vnet.ibm.com \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=martin.wilck@suse.com \ --cc=systemd-devel@lists.freedesktop.org \ /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: linkBe 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.