Red Hat Bugzilla – Bug 245776
Purge count math is not correct in glock trimming patch
Last modified: 2010-01-11 22:18:33 EST
Description of problem: Previous CVS check-in did a last minute change with the way purge count was calculated. The intention was to trim glocks evenly across all the hash buckets and apparently the size of hash array was overlooked. It ends up with zero trimming count most of the time. This virtually makes glock trimming patch a void feature. Need to fix this asap. Version-Release number of selected component (if applicable): RHEL 4.5 How reproducible: Most of the time unless accumulated glock count is well above 8k. Steps to Reproduce: 1. Untar a tar file with lots of small files 2. Issue gfs_tool lockdump to see the glock count. 3. Issue "gfs_tool settune <mnt> glock_purge 100" to trim the glock Actual results: Glock count could stay constant for the duration of the mount time. Expected results: Glock count should go down gradually (around 6~10 minutes) Additional info:
Thanks to Barry Marson. The regression was found in his SPECsfs runs.
Checked into RHEL4 and RHEL4.5 CVS branches.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0998.html