Return-Path: Received: from fieldses.org ([174.143.236.118]:57959 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752150Ab0HRSOu (ORCPT ); Wed, 18 Aug 2010 14:14:50 -0400 Date: Wed, 18 Aug 2010 14:12:40 -0400 From: "J. Bruce Fields" To: "Patrick J. LoPresti" Cc: Alan Cox , Andi Kleen , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel Subject: Re: Proposal: Use hi-res clock for file timestamps Message-ID: <20100818181240.GA13050@fieldses.org> References: <87aaolwar8.fsf@basil.nowhere.org> <20100817174134.GA23176@fieldses.org> <20100817182920.GD18161@basil.fritz.box> <20100817190447.GA28049@fieldses.org> <20100817203941.729830b7@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=utf-8 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Tue, Aug 17, 2010 at 12:34:58PM -0700, Patrick J. LoPresti wrote: > On Tue, Aug 17, 2010 at 12:39 PM, Alan Cox wrote: > > >        if (time_now == time_last) > >                return { time_last , ++ct }; > >        else { > >                ct = 0; > >                time_last = time_now > >                return { time_last , 0 }; > >        } > > > > providing it is done with the same 'ct' across the fs and you can't do > > enough ops/second to wrap the nanosecs - which should be fine for now, > > your ordering is still safe is it not ? > > Yes, that would work. Assuming you use atomic counters, else there > is a risk of the visible time ticking backwards. It seems like a lot > of effort just to avoid having accurate timestamps on your files, > though. > > I am having trouble seeing why this is a better idea than a simple > mount option to obtain decent resolution timestamps. (Not that we > can't have both...) Is there any objection to the mount option I am > proposing? I'm completely ignorant about higher-resolution time sources. Any recommended reading? What resolution do they actually provide, what's the expense of reading them, how reliable are they, and how do the answers to those questions vary across different hardware and kernel versions? A quick look at drivers/clocksource/ doesn't suggest simple answers. -b.