On Fri, Jan 27, 2023 at 4:09 PM Frank Schilder <frans@xxxxxx> wrote:
>
> Hi Ilya,
>
> yes, it has race conditions. However, it seems to address the specific case that is causing us headaches.
>
> About possible improvements. I tried to understand the documentation about rbd image locks, but probably failed. I don't understand what the difference between an exclusive lock and a shared lock is. As far as I understood, neither of these locks have any influence on client IO, nor do they affect the exclusive write-lock transition.
An exclusive lock can be held by only one client at a time. A shared
lock can be held by multiple clients as long as they all pass the same
lock tag ("--shared <lock tag>" option on the CLI).
>
> Does omitting --shared make the rbd lock command an atomic operation, meaning that lock operations become serialised and two clients cannot add the same lock in a race (only one client will succeed in a race)?
Yes.
> Or does it mean that only one client gets write access?
No -- "rbd lock" locks are advisory. They are there for the
orchestration layer to take advantage of. Any client that hasn't been
prevented from doing so by the orchestration layer is going to be able
to write to the image, whether it's holding such a lock or not.
This is similar in concept to Unix file locking ("man 2 flock").
> If it does have influence on client IO, how would the hand-over during live migration have to happen?
Being advisory, "rbd lock" locks don't have a direct influence on
client I/O. Only the lock provided by the exclusive-lock image feature
does.
Thanks,
Ilya
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
