Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752045Ab0HQTST (ORCPT ); Tue, 17 Aug 2010 15:18:19 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:53237 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241Ab0HQTSO (ORCPT ); Tue, 17 Aug 2010 15:18:14 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vCHYGs8dbjqKeLgGt5MA7UgSUWnK8Q1ZNQB85aM8EZtedhePwAetEip+dfrQpl4tth WBZMlhKAAJnW1eAiAlj5L8YVsjpH67cX8bu8zQ1dsrvRaRoxYFIsZFMFRXDScFYoU6fB WwcZdK1sZGc78MF+Eu4+p+Cn0B8cxT5P+L6ZY= MIME-Version: 1.0 In-Reply-To: <20100817190447.GA28049@fieldses.org> References: <87aaolwar8.fsf@basil.nowhere.org> <20100817174134.GA23176@fieldses.org> <20100817182920.GD18161@basil.fritz.box> <20100817190447.GA28049@fieldses.org> Date: Tue, 17 Aug 2010 12:18:12 -0700 Message-ID: Subject: Re: Proposal: Use hi-res clock for file timestamps From: "Patrick J. LoPresti" To: "J. Bruce Fields" Cc: Andi Kleen , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1460 Lines: 36 On Tue, Aug 17, 2010 at 12:04 PM, J. Bruce Fields wrote: > > Right, I think that we probably have to give up ext3 as a lost cause. > But perhaps we could get away with a hack like this on filesystems that > can store nanoseconds. I do not think so. The problem with "increment mtime by a nanosecond when necessary" is that timestamps can wind up out of order. As in: 1) Do a bunch of operations on file A 2) Do one operation on file B Imagine each operation on A incrementing its timestamp by a nanosecond "just because". If all of these operations happen in less than 4 ms, you can wind up with the timestamp on B being EARLIER than the timestamp on A. That is a big no-no (think "make" or anything else relying on timestamps for relative times). If you can prove that the last modification on B happens after the last modification on A, then it is very bad for the mtime on B to be earlier than the mtime on A. I guarantee that will break things in the real world. As you say, high-resolution timestamps "will extend the useful lifetime of NFSv3 by quite a bit". They are also a good idea in principle, IMO. Correctness is almost always more important than performance. - Pat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/