From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: i_version changes Date: Wed, 13 Feb 2008 08:12:05 -0700 Message-ID: <20080213151205.GC3029@webber.adilger.int> References: <20080210073041.GA23529@lst.de> <20080212200625.GE18625@fieldses.org> <20080213125214.GA12362@lst.de> <1202911630.11904.8.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Christoph Hellwig , "J. Bruce Fields" , jean-noel.cordenner@bull.net, linux-fsdevel@vger.kernel.org To: Trond Myklebust Return-path: Received: from sca-es-mail-1.Sun.COM ([192.18.43.132]:63740 "EHLO sca-es-mail-1.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753083AbYBMPMM (ORCPT ); Wed, 13 Feb 2008 10:12:12 -0500 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1DFCA4S006251 for ; Wed, 13 Feb 2008 07:12:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW600701NEWNC00@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Wed, 13 Feb 2008 07:12:10 -0800 (PST) In-reply-to: <1202911630.11904.8.camel@heimdal.trondhjem.org> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Feb 13, 2008 09:07 -0500, Trond Myklebust wrote: > On Wed, 2008-02-13 at 13:52 +0100, Christoph Hellwig wrote: > > Btw, stupid question: the commit message for the i_version changes > > mentions this is to work around lack of granularity for ctime updates. > > But all modern filesystems (and I includ ext4 in that here) have 64bit > > timestamps already, so that should be enough. It would certainly > > avoid all this additional code, and especially the additional space > > used in struct inode which can hurt quite a lot. > > Support for 64-bit on-disk time stamps alone does not suffice. In order > to label all file/directory changes unambiguously, you would also need > nanosecond timekeeping support. > > An example is XFS, which has had on-disk support for 64-bit time stamps > since forever, but is in practice limited by the Linux default 250Hz > internal clock. We've seen plenty of examples of NFS clients missing > updates on the resulting filesystem due to the fact that they occurred > within 1/250 sec of each other. The other issue which unfortunately makes ctime a non-starter is the ability of ctime to go backward due to clock changes. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.