On Mon, Mar 12, 2018 at 8:20 PM, Maged Mokhtar <mmokh...@petasan.org> wrote:
> On 2018-03-12 21:00, Ilya Dryomov wrote:
> On Mon, Mar 12, 2018 at 7:41 PM, Maged Mokhtar <mmokh...@petasan.org> wrote:
> On 2018-03-12 14:23, David Disseldorp wrote:
> On Fri, 09 Mar 2018 11:23:02 +0200, Maged Mokhtar wrote:
> 2)I undertand that before switching the path, the initiator will send a
> TMF ABORT can we pass this to down to the same abort_request() function
> in osd_client that is used for osd_request_timeout expiry ?
> IIUC, the existing abort_request() codepath only cancels the I/O on the
> client/gw side. A TMF ABORT successful response should only be sent if
> we can guarantee that the I/O is terminated at all layers below, so I
> think this would have to be implemented via an additional OSD epoch
> barrier or similar.
> Cheers, David
> Hi David,
> I was thinking we would get the block request then loop down to all its osd
> requests and cancel those using the same  osd request cancel function.
> All that function does is tear down OSD client / messenger data
> structures associated with the OSD request.  Any OSD request that hit
> the TCP layer may eventually get through to the OSDs.
> Thanks,
>                 Ilya
> Hi Ilya,
> OK..so i guess this also applies as well to osd_request_timeout expiry, it
> is not guaranteed to stop all stale ios.

Yes.  The purpose of osd_request_timeout is to unblock the client side
by failing the I/O on the client side.  It doesn't attempt to stop any
in-flight I/O -- it simply marks it as failed.


ceph-users mailing list

Reply via email to