Date: Fri, 14 Oct 2005 22:12:04 +0100 From: Brian Candler <B.Candler@pobox.com> To: Eric Anderson <anderson@centtech.com> Cc: max@love2party.net, freebsd-current@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: ufsstat - testers / feedback wanted! Message-ID: <20051014211204.GA21070@uk.tiscali.com> In-Reply-To: <434FEDA1.4060803@centtech.com> References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> <434FDAB2.7040402@centtech.com> <20051014164628.GA20338@uk.tiscali.com> <434FEDA1.4060803@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051014211204.GA21070>