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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
