On Tue, Jun 27, 2023 at 11:21:36AM -0600, Keith Busch wrote: > On Sun, Jun 25, 2023 at 08:26:48AM +0800, Ming Lei wrote: > > 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? Thanks, Ming
