Effect of modifications to /proc/cluster/lock_dlm/drop_count & drop_period

A Service request was logged to obtain more information regarding the impact of changing the default values set in the /proc/cluster/lock_dlm/* files.

# cat /proc/cluster/lock_dlm/drop_count
50000
# cat /proc/cluster/lock_dlm/drop_period
60

There is no documentation to highlight the impacts on the gfs cluster of modifying these two values, so an advanced configuration request was logged to obtain this information.

Response from RedHat

Greetings,

I do not have a definitive answer to your question, but I would request you to refer to below Red Hat Cluster list threads.
http://www.redhat.com/archives/linux-cluster/2005-February/msg00129.html
http://www.redhat.com/archives/linux-cluster/2005-January/msg00080.html
Can you let me know the reasons why you want to modify these parameters, is there any problem you are facing ?
I would request you to send me a sysreport of all the nodes so that I can consult with Sr.Engineer, and advice you.
Regards

This is obviously not what we were looking for, so I updated the ticket to inform them of this fact.

Update From Redhat

Hello Scott,
Am looking into this and will update you soon. I don’t think that sysreports are required at this point of time.

I will update this entry as and when I get a response from RedHat.

Further Update From RH:

Setting drop_count to 0 (or increasing it) will allow gfs to cache more locks which can dramatically improve performance in some cases. Allowing gfs to cache more locks will increase the chances that the dlm may run out of memory during recovery. I don’t think there’s any point in changing drop_period; it governs how often gfs will get drop-locks callbacks while the number of locks exceeds drop_count.