Details
-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
3
-
9223372036854775807
Description
Originally, LDLM always had a static LRU size defined by the lru_size parameter. When dynamic LRU sizing was implemented, setting "lru_size=0" was taken as "change to dynamic LRU sizing".
For historic reasons, reading from the ldlm.namespaces.*.lru_size parameter returns the number of locks currently in the LRU for that lock namespace. This usage to fetch the current lock count was replaced long ago by the "...lock_count" parameter (similar to the "resource_count parameter, unless there are multiple DLM locks on a single object (eg. read locks, non-overlapping write locks, etc.).
Any usage of "lru_size" in the test scripts to get the current lock count should be replaced by "lock_count". A second patch should be made to return the actual setting of lru_size (including zero), not the current lock count in case of dynamic LRU size.
Attachments
Activity
| Description |
Original:
Originally, LDLM always had a static LRU size defined by the {{lru_size}} parameter. When dynamic LRUsizing was implemented, setting "lru_size=0" was taken as "change to dynamic LEU sizing".
For historic reasons, reading from lru_size returns the number of locks currently in the LRU for that lock namespace. This usage to fetch the current lock count was replaced long ago by the "lock_count" parameter (similar to the "resource_count parameter, unless there are multiple DLM locks on a single object (eg. read locks, non-overlapping write locks, etc.). Any usage of "lru_size" in the test scripts to get the current lock count should be replaced by "lock_count". A second patch should be made to return the actual setting of lru_size (including zero), not the current lock count in case of dynamic lru size. |
New:
Originally, LDLM always had a static LRU size defined by the {{lru_size}} parameter. When dynamic LRU sizing was implemented, setting "lru_size=0" was taken as "change to dynamic LRU sizing".
For historic reasons, reading from the {{ldlm.namespaces.\*.lru_size}} parameter returns the number of locks currently in the LRU for that lock namespace. This usage to fetch the current lock count was replaced long ago by the "{{...lock_count}}" parameter (similar to the "resource_count parameter, unless there are multiple DLM locks on a single object (eg. read locks, non-overlapping write locks, etc.). Any usage of "{{lru_size}}" in the test scripts to get the current lock count should be replaced by "{{lock_count}}". A second patch should be made to return the actual setting of {{lru_size}} (including zero), not the current lock count in case of dynamic LRU size. |