[PATCH v3] nvme: core: shorten duration of multipath namespace rescan
Christoph Hellwig
hch at lst.de
Mon Aug 26 23:33:32 PDT 2024
> + /*
> + * The controller queue is going to be frozen in
> + * nvme_update_ns_info_{generic,block}(). Every freeze implies waiting
> + * for an RCU grace period to pass. For multipath devices, we
> + * need to freeze the multipath queue, too. Start freezing the
> + * multipath queue now, lest we need to wait for two grace periods.
> + */
> + if (nvme_ns_head_multipath(ns->head))
> + blk_freeze_queue_start(ns->head->disk->queue);
I really don't like how we keep this state around the calls into
the command set specific nvme_update_ns_info_* calls, and how it
feels very open coded.
And while looking at it, I think we might even want the multipath
queue frozen over the actual update as well, as there is no point
in sending the I/O even to other paths while we are updating the
information, as they'll probably fail.
Here is what might make sense:
1) move the code past the csi switch statement in nvme_update_ns_info
into a new nvme_update_ns_info_common helper and all that
from nvme_update_ns_info_block and nvme_update_ns_info_generic.
Maybe having another helper just for the multipath updates might
also be worthwhile.
2) add new nvme_freeze_ns helpers that freeze the ns and nshead
queues and use those in nvme_update_ns_info_block and
nvme_update_ns_info_generic over the entire update
3) update these new helpers to use the trick from this patch to
only require a single grace period.
More information about the Linux-nvme
mailing list