[openstack-dev] [oslo][all] The lock files saga (and where we can go from here)
sean at dague.net
Tue Dec 1 17:16:34 UTC 2015
On 12/01/2015 08:08 AM, Duncan Thomas wrote:
> On 1 December 2015 at 13:40, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> The current approach means locks block on their own, are processed in
> the order they come in, but deletes aren't possible. The busy lock would
> mean deletes were normal. Some extra cpu spent on waiting, and lock
> order processing would be non deterministic. It's trade offs, but I
> don't know anywhere that we are using locks as queues, so order
> shouldn't matter. The cpu cost on the busy wait versus the lock file
> cleanliness might be worth making. It would also let you actually see
> what's locked from the outside pretty easily.
> The cinder locks are very much used as queues in places, e.g. making
> delete wait until after an image operation finishes. Given that cinder
> can already bring a node into resource issues while doing lots of image
> operations concurrently (such as creating lots of bootable volumes at
> once) I'd be resistant to anything that makes it worse to solve a
> cosmetic issue.
Is that really a queue? Don't do X while Y is a lock. Do X, Y, Z, in
order after W is done is a queue. And what you've explains above about
Don't DELETE while DOING OTHER ACTION, is really just the queue model.
What I mean by treating locks as queues was depending on X, Y, Z
happening in that order after W. With a busy wait approach they might
happen as Y, Z, X or X, Z, B, Y. They will all happen after W is done.
But relative to each other, or to new ops coming in, no real order is
More information about the OpenStack-dev