Details
-
New Feature
-
Resolution: Unresolved
-
Medium
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
When reclaiming locks on the server side, the Least Recently Used (LRU) algorithm is employed based on the locks' last used time. However, when a client finds a compatible cached lock in its local lock namespace, it can directly use it without intract to the lock server. In this case, only the client-side lock's last used time is updated, while the corresponding server-side lock's LRU timestamp remains unchanged.
In large-scale Lustre systems with hundreds or thousands of clients, the server-side lock namespace must manage all locks granted to clients. And these locks are cached on server side memory. Due to limited server memory capacity, when lock reclaim is triggered, the server's LRU timestamps may not reflect recent used accurately.
This can lead to premature reclaim of locks that are actually still in active use or may be reused repeatedly in the near future by clients, resulting in unnecessary lock communication overhead and degraded system performance.
According to the analysis above, the core issue is that when clients use locally cached locks, they update their local LRU timestamp but don't propagate this to the server. The server's LRU list becomes stale and may incorrectly revoke actively used locks during memory pressure situations. This could cause significant performance issues in large-scale deployments with hundreds of clients.
This is a deep technical issue in distributed systems where client-side caching causes server-side lock management inaccuracies.
