diff options
Diffstat (limited to 'Feature Planning/GlusterFS 3.6/glusterd volume locks.md')
-rw-r--r-- | Feature Planning/GlusterFS 3.6/glusterd volume locks.md | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/Feature Planning/GlusterFS 3.6/glusterd volume locks.md b/Feature Planning/GlusterFS 3.6/glusterd volume locks.md new file mode 100644 index 0000000..a8f8ebd --- /dev/null +++ b/Feature Planning/GlusterFS 3.6/glusterd volume locks.md @@ -0,0 +1,48 @@ +As of today most gluster commands take a cluster wide lock, before +performing their respective operations. As a result any two gluster +commands, which have no interdependency with each other, can't be +executed simultaneously. To remove this interdependency we propose to +replace this cluster wide lock with a volume specific lock, so that two +operations on two different volumes can be performed simultaneously. + +1. We classify all gluster operations in three different classes : +Create volume, Delete volume, and volume specific operations. + +2. At any given point of time, we should allow two simultaneous +operations (create, delete or volume specific), as long as each both the +operations are not happening on the same volume. + +3. If two simultaneous operations are performed on the same volume, the +operation which manages to acquire the volume lock will succeed, while +the other will fail. Also both might fail to acquire the volume lock on +the cluster, in which case both the operations will fail. + +In order to achieve this, we propose a locking engine, which will +receive lock requests from these three types of operations. Each such +request for a particular volume will contest for the same volume lock +(based on the volume name and the node-uuid). For example, a delete +volume command for volume1 and a volume status command for volume 1 will +contest for the same lock (comprising of the volume name, and the uuid +of the node winning the lock), in which case, one of these commands will +succeed and the other one will not, failing to acquire the lock. + +Whereas, if two operations are simultaneously performed on a different +volumes they should happen smoothly, as both these operations would +request the locking engine for two different locks, and will succeed in +locking them in parallel. + +We maintain a global list of volume-locks (using a dict for a list) +where the key is the volume name, and which saves the uuid of the +originator glusterd. These locks are held and released per volume +transaction. + +In order to acheive multiple gluster operations occuring at the same +time, we also separate opinfos in the op-state-machine, as a part of +this patch. To do so, we generate a unique transaction-id (uuid) per +gluster transaction. An opinfo is then associated with this transaction +id, which is used throughout the transaction. We maintain a run-time +global list(using a dict) of transaction-ids, and their respective +opinfos to achieve this. + +Gluster devel Mailing Thread: +<http://lists.gnu.org/archive/html/gluster-devel/2013-09/msg00042.html>
\ No newline at end of file |