Re: [PATCH v2 01/14] nvmet: Rapid Path Failure Recovery set controller identify fields

[Randy Jennings]

On Sat, Feb 7, 2026 at 5:41 AM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
>
>
> > Precisely my point. If CQT defaults to zero no delay will be inserted,
> > but we _still_ have CCR handling. Just proving that both really are
> > independent on each other. Hence I would prefer to have two patchsets.
>
> Agreed. I think it would be cleaner to review each separately. the CCR
> can be based
> on top of the CQT patchset, for simplicity.
>
Hannes, I have some concerns about structuring the CQT patches
separate from the CCR patches.

We are trying to fix the Ghost Write data corruption, and this has
been a long process (involving 3 modifications to the spec and a
number of proposed patch sets).  We’ve already been told (explicitly
and implicitly) that CCR is the more interesting solution (a
euphemism) for solving this data corruption.  I have some concern
that, if  separated, the CCR patches will get accepted without the CQT
patches.

CCR does not work in all cases, so I do not see them as independent as
you are saying here. Also, CQT is a natural time cap on the retries
needed for CCR to handle CCR retries when it cannot succeed down some
paths.  When used as a time cap, CQT fits well with the CCR changes.

I am concerned that it will be more complicated to review the CQT
changes, with at least more patches to review.

Structuring the patches with CQT first and CCR second would take care
of many of these concerns.

Sincerely,
Randy Jennings