On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch <jamesbrandongo...@gmail.com> wrote: > On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill <da...@catwhisker.org> wrote: >> I'm using a little shell script to capture selected sysctl OID >> values periodically, in an attempt to get a better idea how the >> resources of a system are being used during a long-running (usually >> measured in hours), mission-critical workload. >> >> In the process of testing this, I've seen some of the VFS sysctl >> OIDs (in particular) report negative values ... when the description >> looks to me as if the OID in question is intended to be a monotonically >> increasing counter. >> >> For example: >> >>> sysctl -d vfs.getnewbufcalls >> vfs.getnewbufcalls: Number of calls to getnewbuf >>> sysctl vfs.getnewbufcalls >> vfs.getnewbufcalls: -348909432 >> >> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls >> appears to be: >> >> ... >> static int getnewbufcalls; >> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0, >> "Number of calls to getnewbuf"); >> ... >> >> Many of the other OIDs defined nearby are also SYSCTL_INT (or >> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding >> variables are defined as static int (or static long) vs. static u_int >> (or static u_long). >> >> Is this both correct and reasonable? If so, how should I interpret such >> negative values? >> >> [GSoC project, anyone?] >> >> Thanks! >> >> Peace, >> david > > The following initiative may factor heavily into any decision to > change sysctl declarations at this point: > > http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Type-Safety
The intent of the type-safety is to make sure that the types assumed for the kernel's sysctl handler match the type of the variable. This project won't fix issues where a signed type is being used and the value wraps (at least, I presume that's what happened in this case?) Thanks, matthew _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
