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