If it really becomes an issue we
should rework the nvme code to also skip the multipath code for any
private namespace, even if that could mean some trouble when rescanning.
This requires some explanation? skip the multipath code how?
We currently always go through the multipath node as
On Mon, Dec 03, 2018 at 05:11:43PM -0800, Sagi Grimberg wrote:
>> If it really becomes an issue we
>> should rework the nvme code to also skip the multipath code for any
>> private namespace, even if that could mean some trouble when rescanning.
>>
>
> This requires some explanation? skip the
If it really becomes an issue we
should rework the nvme code to also skip the multipath code for any
private namespace, even if that could mean some trouble when rescanning.
This requires some explanation? skip the multipath code how?
Other than that,
Reviewed-by: Sagi Grimberg
On Sun, Dec 02, 2018 at 08:46:25AM -0800, Christoph Hellwig wrote:
> The ->poll_fn has been stale for a while, as a lot of places check for mq
> ops. But there is no real point in it anyway, as we don't even use
> the multipath code for subsystems without multiple ports, which is usually
> what
The ->poll_fn has been stale for a while, as a lot of places check for mq
ops. But there is no real point in it anyway, as we don't even use
the multipath code for subsystems without multiple ports, which is usually
what we do high performance I/O to. If it really becomes an issue we
should
The ->poll_fn has been stale for a while, as a lot of places check for mq
ops. But there is no real point in it anyway, as we don't even use
the multipath code for subsystems without multiple ports, which is usually
what we do high performance I/O to. If it really becomes an issue we
should
The ->poll_fn has been stale for a while, as a lot of places check for mq
ops. But there is no real point in it anyway, as we don't even use
the multipath code for subsystems without multiple ports, which is usually
what we do high performance I/O to. If it really becomes an issue we
should
