From: Erwin van Londen <erwin@erwinvanlonden.net> To: "Ewan D. Milne" <emilne@redhat.com>, Martin Wilck <martin.wilck@suse.com>, "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: Mon, 03 May 2021 12:34:16 +1000 [thread overview] Message-ID: <9ff34a69d89e49b4faeadb74eb73732ff6892529.camel@erwinvanlonden.net> (raw) In-Reply-To: <ba1ed6166b285d4ccb90f5f17b971983092d382e.camel@redhat.com> On Fri, 2021-04-30 at 19:44 -0400, Ewan D. Milne wrote: > On Wed, 2021-04-28 at 10:09 +1000, Erwin van Londen wrote: > > > > > > Perhaps an array might abort I/Os it has received in the Device > Server when > something changes. I have no idea if most or any arrays actually do > that. > > But, what about I/O that has already been queued from the host to the > host bus adapter? I don't see how we can abort those I/Os properly. > Most high-performance HBAs have a queue of commands and a queue > of responses, there could be lots of commands queued before we > manage to notice an interesting status. And AFAIK there is no > conditional > mechanism that could hold them off (and, they could be in-flight on > the > wire anyway). > > I get what you are saying about what SAM describes, I just don't see > how > we can guarantee we don't send any further commands after the status > with the UA is sent back, before we can understand what happened. > > -Ewan I agree there is only so much we can do especially when IO's have been dispatched to hardware queues. I think if anything happens to those, too bad, these ones will incur an abort or status check as well. These would just need to be identified and subsequent IO's then sent to a different path but that is a different topic. My primary concern is that if anything happens on a lun that changes its attributes or access characteristics a UA should be sent in order to inform a host. It cannot be that an array shuffles a lun id onto a different physical volume without the host knowing. This will for sure cause data corruption. > > > > > > > > > > > > > -- > > dm-devel mailing list
WARNING: multiple messages have this Message-ID (diff)
From: Erwin van Londen <erwin@erwinvanlonden.net> To: "Ewan D. Milne" <emilne@redhat.com>, Martin Wilck <martin.wilck@suse.com>, "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>, "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "dgilbert@interlog.com" <dgilbert@interlog.com>, "systemd-devel@lists.freedesktop.org" <systemd-devel@lists.freedesktop.org>, "hch@lst.de" <hch@lst.de> Subject: Re: [dm-devel] RFC: one more time: SCSI device identification Date: Mon, 03 May 2021 12:34:16 +1000 [thread overview] Message-ID: <9ff34a69d89e49b4faeadb74eb73732ff6892529.camel@erwinvanlonden.net> (raw) In-Reply-To: <ba1ed6166b285d4ccb90f5f17b971983092d382e.camel@redhat.com> On Fri, 2021-04-30 at 19:44 -0400, Ewan D. Milne wrote: > On Wed, 2021-04-28 at 10:09 +1000, Erwin van Londen wrote: > > > > > > Perhaps an array might abort I/Os it has received in the Device > Server when > something changes. I have no idea if most or any arrays actually do > that. > > But, what about I/O that has already been queued from the host to the > host bus adapter? I don't see how we can abort those I/Os properly. > Most high-performance HBAs have a queue of commands and a queue > of responses, there could be lots of commands queued before we > manage to notice an interesting status. And AFAIK there is no > conditional > mechanism that could hold them off (and, they could be in-flight on > the > wire anyway). > > I get what you are saying about what SAM describes, I just don't see > how > we can guarantee we don't send any further commands after the status > with the UA is sent back, before we can understand what happened. > > -Ewan I agree there is only so much we can do especially when IO's have been dispatched to hardware queues. I think if anything happens to those, too bad, these ones will incur an abort or status check as well. These would just need to be identified and subsequent IO's then sent to a different path but that is a different topic. My primary concern is that if anything happens on a lun that changes its attributes or access characteristics a UA should be sent in order to inform a host. It cannot be that an array shuffles a lun id onto a different physical volume without the host knowing. This will for sure cause data corruption. > > > > > > > > > > > > > -- > > dm-devel mailing list -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-05-03 3:02 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 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 [this message] 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=9ff34a69d89e49b4faeadb74eb73732ff6892529.camel@erwinvanlonden.net \ --to=erwin@erwinvanlonden.net \ --cc=Ulrich.Windl@rz.uni-regensburg.de \ --cc=dgilbert@interlog.com \ --cc=dm-devel@redhat.com \ --cc=emilne@redhat.com \ --cc=hare@suse.com \ --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.