[PATCH v4 02/18] block: Rename BLK_STS_NEXUS to BLK_STS_RESV_CONFLICT

Stefan Haberland sth at linux.ibm.com
Thu Mar 16 03:17:06 PDT 2023


Am 15.03.23 um 14:30 schrieb Christoph Hellwig:
> On Wed, Mar 15, 2023 at 11:04:22AM +0100, Stefan Haberland wrote:
>> This also fits for the DASD case. We use this error code for a
>> reservation/locking conflict of the DASD device when the lock we
>> previously held was stolen.
> But that's not really a reservation conflict in the sense
> of the reservation API.  Given that DASD doesn't support it it
> might not matter.  Do you have applications that checks for
> the translated errno value?  We'll probably at least want
> a comment documenting this status code.

Well, I might completely misunderstand the use case for this error code.
Sorry if that is the case.

Beside that I thought that the return codes are generic blocklayer 
return codes
and not bound to a specific API. I am not familiar with the reservation 
API you
are talking about.

What I understood from the reservation in NVMe context is that a namespace
might be reserved to a host. If there is a conflict with this reservation
this error code is provided for the IO request.

For DASDs we have the possibility to reserve a disk for a host. If there 
is a
conflict with this platform specific reservation we would present this 
error
for an IO request.

This sounded quite similar for me.

I am completely open to using another return code and I am not aware of an
application checking for this specific return code.

Is there any that would fit better from your point of view?




More information about the Linux-nvme mailing list