Return-Path: Received: from casper.infradead.org ([85.118.1.10]:45008 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752211Ab0HRSVI (ORCPT ); Wed, 18 Aug 2010 14:21:08 -0400 Subject: Re: Proposal: Use hi-res clock for file timestamps From: David Woodhouse To: Andi Kleen Cc: "J. Bruce Fields" , "Patrick J. LoPresti" , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel In-Reply-To: <20100817182920.GD18161@basil.fritz.box> References: <87aaolwar8.fsf@basil.nowhere.org> <20100817174134.GA23176@fieldses.org> <20100817182920.GD18161@basil.fritz.box> Content-Type: text/plain; charset="UTF-8" Date: Wed, 18 Aug 2010 19:20:58 +0100 Message-ID: <1282155658.13405.36.camel@localhost> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Tue, 2010-08-17 at 20:29 +0200, Andi Kleen wrote: > > > - Increment mtime by a nanosecond when necessary. > > You cannot be more precise than the backing file system: this causes > non monotonity when the inodes are flushed (has happened in the past) Um, can't you? You can't *store* timestamps which are more precise, but they can be in cache can't they? And since you're not going to drop it from cache and bring it back in again within 4ms, that ought to suffice? -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation