Exclusive Local Locks for Distributed File System Cache
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Distributed file systems face performance degradation due to the need for exclusive locks, which can bring all shared lock requests to a halt when a single thread takes an exclusive lock, especially in systems with thousands of shared lockers, as existing locking mechanisms require calls to a coordinator node for every lock operation.
Innovation Solution
Implementing exclusive local locks over a null type lock, which bypasses the coordinator node and allows for quick acquisition of locks by treating the null lock as a shared lock with a contention type of 'LK_CONTEND_ALL', enabling local consistency without relying on cluster-wide arbitration for operations relevant only to the local node.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single thread takes an exclusive lock in a distributed system with thousands of shared lockers, then data consistency is maintained, but all shared lock requests are brought to a halt until all existing shared owners release their locks
Solution Approach 1:
The locking mechanism is segmented into two independent parts: a shared lock component that allows multiple owners and an exclusive lock component that ensures data consistency. This segmentation enables shared locks to proceed in parallel without being blocked by exclusive lock acquisitions, resolving the contradiction between maintaining data consistency and preserving lock acquisition speed.
Solution Approach 2:
An intermediary lock structure is introduced between the shared lock and exclusive lock. This intermediary component coordinates the acquisition process, allowing shared locks to be granted without requiring all shared owners to release their locks before an exclusive lock can be acquired, thus eliminating the blocking behavior while maintaining data consistency.
2Reliability
If existing locking mechanisms require calls to a coordinator node for every lock operation, then cluster-wide arbitration is achieved, but performance degrades due to unnecessary coordination overhead
Solution Approach 1:
The locking mechanism implements local quality by allowing nodes to perform lock operations locally without requiring coordination from a central coordinator node. Each node can independently manage its own lock state, achieving fast local lock acquisition while still maintaining cluster-wide arbitration through a simplified notification mechanism that only activates when necessary.
3Productivity
If shared locks allow multiple owners simultaneously, then concurrency is improved, but exclusive lock acquisition becomes costly and blocks all shared lock requests
Solution Approach 1:
The locking mechanism is segmented into independent shared lock and exclusive lock components. The shared lock component manages multiple owners and enables high concurrency, while the exclusive lock component handles data consistency requirements. This segmentation allows the system to achieve both high concurrency and data consistency without increasing overall complexity.
Solution Approach 2:
The system implements partial action by allowing shared locks to proceed without requiring full coordination for exclusive lock acquisition. The exclusive lock mechanism only intervenes when necessary to ensure data consistency, rather than blocking all shared lock requests, thus achieving high concurrency with minimal complexity overhead.
Data Source
AI summary
Facilitating exclusive local locks on a distributed file system is provided herein. An embodiment relates to a node device of a cluster of node devices. The node device can comprise a processor and a memory that stores executable instructions that, when executed by the processor, facilitate performance of operations. The operations can comprise determining at least one resource is to be removed from a cache of the node device. The operations also can comprise implementing an exclusive local lock over a defined lock. The defined lock can indicate interest in the at least one resource by other node devices of the cluster of node devices other than the node device. Further, the operations can comprise removing the at least one resource from the cache. The other node devices are not notified of the removing.