On Jul 2 20:55, Klaus Jensen wrote: > On Jul 2 09:24, Keith Busch wrote: > > On Tue, Jul 02, 2024 at 01:32:32PM +0530, Ayush Mishra wrote: > > > Abort was not implemented previously, but we can implement it for AERs > > > and asynchrnously for I/O. > > > > Not implemented for a reason. The target has no idea if the CID the > > host requested to be aborted is from the same context that the target > > has. Target may have previoulsy completed it, and the host re-issued a > > new command after the abort, and due to the queueing could have been > > observed in a different order, and now you aborted the wrong command. > > I might be missing something here, but are you saying that the Abort > command is fundamentally flawed? Isn't this a host issue? The Abort is > for a specific CID on a specific SQID. The host *should* not screw this > up and reuse a CID it has an outstanding Abort on? > > I don't think there are a lot of I/O commands that a host would be able > to cancel (in QEMU, not at all, because only the iscsi backend > actually implements blk_aio_cancel_async). But some commands that issue > multiple AIOs, like Copy, may be long running and with this it can > actually be cancelled. > > And with regards to AERs, I don't see why it is not advantageous to be > able to Abort one?
Keith, any thoughts on this?
signature.asc
Description: PGP signature
