Currently, the warning messages about byte-range locks are throttled
only according to what the last PID of the locking process was. So, if
that same process performs a bunch of byte-range locks a bunch of
times, we log this warning message at most once every 2 minutes.
However, if we have even just one other process also performing
byte-range locks, the throttling can become pretty useless as
lastWarnPid ping-pongs back and forth between the two different PIDs.
This can happen if multiple unrelated byte-range-lock-using pieces of
software just happen to be running on the same machine, or if a piece
of software uses byte-range locks after forking into separate
processes.
To avoid flooding the log in situations like this, keep track of the
last warn time in the relevant vcache, so we don't get frequent
warnings for byte-range lock requests on the same file.
Reviewed-on: http://gerrit.openafs.org/10796
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit
9f90b12e14e5511cb1c11cbc4d85cfa291be861f)
Change-Id: Ia5426e97fa431e6b9eeb1c82e03c74c959249e9a
Reviewed-on: http://gerrit.openafs.org/10839
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
if ((now < lastWarnTime + 120) && (lastWarnPid == pid)) {
return;
}
+ if (now < avc->lastBRLWarnTime + 120) {
+ return;
+ }
procname = afs_osi_Alloc(256);
osi_procname(procname, 256);
procname[255] = '\0';
- lastWarnTime = now;
+ lastWarnTime = avc->lastBRLWarnTime = now;
lastWarnPid = pid;
#ifdef AFS_LINUX26_ENV
#ifdef AFS_SUN5_ENV
struct afs_q multiPage; /* list of multiPage_range structs */
#endif
+ afs_uint32 lastBRLWarnTime; /* last time we warned about byte-range locks */
};
#define DONT_CHECK_MODE_BITS 0