[PATCH] nvme-loop: set blocking flag

[Sagi Grimberg]

On 18/10/2024 8:10, Christoph Hellwig wrote:
> On Thu, Oct 17, 2024 at 12:04:21PM -0600, Keith Busch wrote:
>>> Looks fine to me, but might be worth looking at doing that a bit
>>> differently so that the target loop driver can remain non-blocking
>>> as it should be considerably more efficient.
>> That's what I first looked at, but it's too hard. Maybe if we can make a
>> lookup that doesn't rely on searching the configfs group, but it's
>> definitely not this nice one-liner patch. :)
> Searching configfs in the I/O path sounds like a train wreck no matter
> what.  I feel a bit bad for not noticing that earlier.
>
> Let me see what I can do.

Note, the search is ONLY in the error case, i.e. when nsid is not found in
subsys->namespaces.

I agree its a shame to make the loop driver blocking for this niche case.

Note that this doesn't do anything, because it is really designed to 
make the
host failover work correctly (i.e. not fail IO) when nvmet disabled the 
ns in
one server, and the namespace is available in the same nvmet subsystem 
on another server.

We could escape this entirely for loop transport because it there are no 
multi-server nvmet
subsystems for loop? There is a weird case where one can use mpath 
device where one
path is loop and another is tcp/rdma... Which is very weird but maybe 
possible with nvmet.