Distributed File System Delete Lock Contention Handling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Distributed file systems face inefficiencies in managing lock resources, particularly when thousands of shared lockers are involved, as a single thread taking an exclusive lock can halt all shared lock requests until all locks are released, leading to costly and inefficient lock upgrades.
Innovation Solution
The introduction of a flag in the inode definition to denote if an inode is marked for deletion, along with a contention callback that sets the flag when another node attempts to upgrade to an exclusive delete lock while a shared lock is held, allowing conditional lock upgrades and reducing unnecessary lock requests.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single thread takes an exclusive lock in a distributed file system, then data consistency is maintained, but all shared lock requests are halted until all existing shared owners release their locks
Solution Approach 1:
The patent segments the lock upgrade process by introducing a flag in the inode definition to mark objects scheduled for removal. This allows the system to identify and handle delete lock contention cases separately from regular lock upgrades, enabling shared lockers to release their locks without waiting for exclusive lock acquisition when the object is already marked for deletion.
Solution Approach 2:
The system performs preliminary action by setting a flag in the inode definition before the actual lock upgrade attempt. This flag indicates that the object is scheduled for removal, allowing subsequent lock operations to bypass the traditional exclusive lock acquisition process and proceed directly to releasing shared locks, thus avoiding the blocking behavior.
2Productivity
If a contention callback is implemented to track delete lock attempts, then unnecessary lock upgrades are reduced, but additional overhead is introduced for tracking and managing contention states
Solution Approach 1:
The patent introduces a contention callback as an intermediary mechanism that is invoked when another node attempts to upgrade to an exclusive delete lock while a shared lock is held. This callback sets a flag in the inode definition, serving as a mediator between the lock management system and the object removal process, enabling the system to track delete lock contention without requiring complex communication protocols between nodes.
Solution Approach 2:
The system implements self-service by using the flag in the inode definition to automatically indicate delete lock contention status. When the contention callback is invoked, it sets this flag, which then guides subsequent lock operations to bypass unnecessary exclusive lock acquisition attempts. The system uses its own internal state (the flag) to manage the lock upgrade process without requiring external coordination.
Data Source
AI summary
Facilitating object deletion based on delete lock contention in distributed file systems is provided herein. A first node device of a cluster of node devices. The first 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 whether a contention callback is assigned to an object scheduled to be removed from cache of the first node device. The operations also can comprise, based on the contention callback being assigned to the object, granting a write lock to a second node device of the cluster of node devices and removing from the cache a link to the object. Further, the operations can comprise, based on the contention callback not being assigned to the object, releasing from the cache the link to the object without interactions with other node devices of the cluster of node devices, the other node devices including the second node device and being other than the first node device.