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.Received on Fri Oct 14 2005 - 19:12:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:45 UTC