Yeah, but you can't remove the gap at all with start_freeze, that said
the current code has to live with the situation of new mapping change
and old request with old mapping.
Actually I considered to handle this kind of situation before, one approach
is to reuse the bio steal logic taken in nvme mpath:
1) for FS IO, re-submit bios, meantime free request
2) for PT request, simply fail it
It could be a bit violent for 2) even though REQ_FAILFAST_DRIVER is
always set for PT request, but not see any better approach for handling
PT request.
I think that's acceptable for PT requests, or any request that doesn't
have a bio. I tried something similiar a while back that was almost
working, but I neither never posted it, or it's in that window when
infradead lost all the emails. :(
If you are fine to fail PT request, I'd suggest to handle the
problem in the following way:
1) moving freeze into reset
2) during resetting
- freeze NS queues
- unquiesce NS queues
- nvme_wait_freeze()
- update_nr_hw_queues
- unfreeze NS queues
3) meantime changes driver's ->queue_rq() in case that ctrl state is NVME_CTRL_CONNECTING,
- if the request is FS IO with data, re-submit all bios of this request,
and free the request
- otherwise, fail the request
With this way, not only freeze is paired with unfreeze. More
importantly, it becomes not possible to trigger new timeout during
handling NVME_CTRL_CONNECTING, then fallback to ctrl removal can
be avoided.
Any comment on this approach?
As aid, for tcp/rdma I agree with this approach. No need to worry
about the non-mpath case, I don't think it is really used anyway
nowadays.
