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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
