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):
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
Glock count could stay constant for the duration of the mount time.
Glock count should go down gradually (around 6~10 minutes)
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.