Open Stack

On 1 December 2015 at 13:40, Sean Dague <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.


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/6c719796/attachment.html>