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

[Mike Christie]

On 3/16/23 5:17 AM, Stefan Haberland wrote:
> 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?
> 

I think we are ok for dasd using BLK_STS_RESV_CONFLICT.

It thought it sounded similar to SCSI/NVMe and userspace will still
see -EBADE because the blk_status_to_errno/errno_to_blk_status will
handle this.

There was no internal dasd code checking for BLK_STS_NEXUS.

There is a pr_ops API, but dasd is not hooked into it so we don't
have to worry about behavior changes.