From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 05:25:41 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 391B81065672; Mon, 31 Jan 2011 05:25:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id B89AA8FC0C; Mon, 31 Jan 2011 05:25:40 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0V5PWQE003310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 16:25:35 +1100 Date: Mon, 31 Jan 2011 16:25:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Matuska In-Reply-To: <4D45F359.4040402@FreeBSD.org> Message-ID: <20110131160644.P2539@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 05:25:41 -0000 On Mon, 31 Jan 2011, Martin Matuska wrote: > I have re-checked OpenSolaris, and discovered that long is a int32_t. > > I agree, we should go for int64_t in our case. Why be different from both OpenSolaris and FreeBSD? clock_t is 32 bits on all, and only bogusly signed on some. Also, there must be another bug for overflow to occur after only 24 days. clock_t is only specified for holding statclock ticks, which have a frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of ticks. 32-bit signed ints hold 194 days of ticks. It is a units/type error to use clock_t for any other type of ticks. I used this an excuse to not expand clock_t on i386 about 15 years ago when I worked on this most. Clock ticks should be virtual and have a frequency much higher than 128, especially 15 years later. 1 MHz would have been OK 15 years ago, and some broken standards (XSI?) even required this. 1 GHz would have been good to cover the next 15 years, but it actually only lasted about 5 years since CPU frequencies exceeded it in about 2001. Now that CPU frequencies have stopped growing rapidly, there seem to be no clock periods much smaller than 0.1 nsec on the horizon, so 1 THz might last more than 5 years. But even 1 GHz will overflow a 32-bit signed int in about 2 seconds. IIRC, POSIX only requires clock_t to work for 24 hours, so overflow after 24 days isn't necessarily a bug, but overflow after 2 or 2000 seconds (the latter for 1 MHz) would be. POSIX mostly uses timespecs when more resolution is required, but this has only been standard for 23 years so support and use of them for are patchy. [Context lost to top posting] Bruce