[PATCH v3 13/21] nvme-fc: Use CCR to recover controller that hits an error
Randy Jennings
randyj at purestorage.com
Fri May 15 17:45:02 PDT 2026
On Thu, Mar 26, 2026 at 10:40 AM Mohamed Khalfella
<mkhalfella at purestorage.com> wrote:
>
> On Fri 2026-02-27 17:03:55 -0800, James Smart wrote:
> > On 2/13/2026 8:25 PM, Mohamed Khalfella wrote:
> > What bothers me in this process is - there are certainly conditions
> > where there is not connectivity loss where FC can send things such as
> > the ABTS or a Disconnect LS that can inform the controller to start
> > terminating. Its odd that we skip this step and go directly to the CCR
> > reset to terminate the controller. We should have been able to continue
> > to send the things that start to directly tear down the controller which
> > can be happening in parallel with the CCR.
>
> Depending on how the target is implemented ABTS or Disconnect LS do not
> guarantee inflight IOs are terminated. CCR main point is terminate
> inflight IOs making it safe to retry failed IOs.
James, yes, there are circumstances where traffic on the connection
is flowing fine, and this request is just a problem child. That is
the problem NVMe Cancel is trying to solve, and John is looking at
getting that wrapped into the code. I would expect that FC ABTS
could just substitute for NVMe Cancel (if desired) when that change
comes. For now, we are trying to overcome the data corruption, and
canceling/aborting an individual request is an important, but
subordinate, optimization.
Sincerely,
Randy Jennings
More information about the Linux-nvme
mailing list