On Thu August 6 2009, Ed W wrote: > Edward Capriolo wrote: > > On Thu, Aug 6, 2009 at 12:25 PM, Ed W<lists@wildgooses.com> wrote: > > > >> Edward Capriolo wrote: > >> > >>> I can make a use case for always wanting a reset as a user feature. > >>> > >>> Enter busy NFS servers. I want to be able to graph clients and servers > >>> to see, who is using the most NFS ops. Enter a 32 bit OS level > >>> counter, a counter that has been 32 bit for over 6 years of bug > >>> reporting. > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=103682&cat=bin > >>> > >>> Eventually you hit a wrap around condition (this may not be the case > >>> with vserver). The only way to fix it is restart/reboot. > >>> > >>> That stinks! because you spend half your life bragging about high *nux > >>> uptime but then you need to reboot/restart for your counters, and you > >>> lose your bragging rights. With a 64 bit counter needed a reset is > >>> unlikely, but if they are 32 bit it does come into play. So yes reset > >>> is always useful for stat guru's like myself :) > >>> > >>> > >> > >> ksplice... > >> > >> > >> > > > > Looks nice, so what is ksplice going to do for a vserver counter. Will > > updating the kernel reset it? Can i reset the counter without an > > update? Also look up the kernel and bug in question is a 32/64 bit NFS > > counter FreeBSD bug. > > > > Just being able to reset the vserver counters from user space is a nice feature. > > > > Yeah, posted without reading too carefully. > > My smart arse comment was more about being able to fix the counter > without rebooting and less about being able to reset the counter... > It should be a kernel data resident counter - Look it up in /proc/kmem an poke a zero into it. ;) Mike > Good luck > > Ed W >