ufsstat - testers / feedback wanted!

[Brian Candler]

On Fri, Oct 14, 2005 at 12:40:49PM -0500, Eric Anderson wrote:
> >Losing the odd count probably isn't a problem, but I think there's the
> >possibility of a badly wrong value if you're updating a 64-bit word in two
> >halves. For example, it might be possible to wrap around from
> >00000000ffffffff to 0000000000000000 instead of 0000000100000000.
> 
> I suppose one could argue that this problem is no worse than using 32bit 
> integers, except it would be right more often than not.  (right?)

Well, then it's perhaps better just to have a 32 bit counter in the first
place - and the client which reads it _knows_ it has to deal with wraparound
itself. If you were graphing rates of filesystem operations via SNMP, for
example, that would be fine.

Having a 64 bit value is nice if you want to see the total number of
operations since you rebooted your machine 3 years ago - but that's arguably
more for interest sake than for anything practical. Still, losing 2^32
counts when the above error occurs would make that value even less useful
and potentially very misleading.

Personally, I think I would err on the side of accurate counters, which can
disabled entirely (e.g. via compile-time option or FS mount option), rather
than having inaccurate counters.

There must be lots of other cases in the kernel of stats counters (e.g.
network interface stats) - how do they treat the same problem?

Regards,

Brian.