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?
signature.asc
Description: PGP signature
