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.
Change-Id: I446cf6a438a75aa741c5543b93f74f4184ee6508
Reviewed-on: http://gerrit.openafs.org/10796
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
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
#if !defined(UKERNEL)
void *vpacRock; /* used to read or write in visible partitions */
#endif
+ afs_uint32 lastBRLWarnTime; /* last time we warned about byte-range locks */
};
#define DONT_CHECK_MODE_BITS 0