[PATCH v7 1/1] nvmet: support reservation feature

[Sagi Grimberg]

On 11/03/2024 13:19, Guixin Liu wrote:
>>>
>>> What do you think Sagi? Or may be we can declare that 
>>> preempt_and_abort is not supported, just
>>>
>>> like SPDK does.
>>
>> It can definitely come incrementally, but at the very least it should 
>> be incorrectly supported.
>>
>> Out of curiosity, doesn't your use-case need a fencing protection 
>> against inflight I/Os reordering during
>> preemption?
>
> The cluster use stonith(shoot the other node in the head) to protect 
> sources,
>
> and the backend storage(our storage system goes like this, so does 
> disk firmware I think.)
>
> can process write I/O operations on a first-come,first-served basis if 
> the range of
>
> data accessed by two I/O operation overlaps, for example, hostB 
> preempt and abort
>
> hostA, then host B send I/Os, the backend storage will handle hostA's 
> I/O first(by the timestamp).

So I understand from you that there is out-of-band mechanism for fence 
guarantee?

In any event, Christoph reminded me that preempt and abort is mandatory, 
so we cannot
get away without doing it.

I suggest to introduce a per-ns-per-controller percpuref, with an xarray 
that is rcu protected.

btw, I also think that reservations on nsid=0xffffffff should also work. 
IIRC there were at least
two use-cases that would have benefited from reservations on all 
subsystem namespaces.
It can also be a lot more lightweight to implement that (outside of 
conflicting reservations checks).