Return-Path: Received: from mail-ew0-f46.google.com ([209.85.215.46]:54732 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753834Ab0HMSav convert rfc822-to-8bit (ORCPT ); Fri, 13 Aug 2010 14:30:51 -0400 In-Reply-To: <20100813123635.GA8945@fieldses.org> References: <87lj8ckb1e.fsf@patl.com> <8762zgmmer.fsf@patl.com> <1281628195.2873.12.camel@heimdal.trondhjem.org> <1281634004.14329.14.camel@heimdal.trondhjem.org> <20100813123635.GA8945@fieldses.org> Date: Fri, 13 Aug 2010 11:30:49 -0700 Message-ID: Subject: Re: [PATCH] nfs: lookupcache coherence bugs in WCC update path (revised) From: "Patrick J. LoPresti" To: "J. Bruce Fields" Cc: linux-nfs@vger.kernel.org, Trond Myklebust , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Fri, Aug 13, 2010 at 5:36 AM, J. Bruce Fields wrote: > > If you have an easy reproducer it might also be worth experimenting with > NFSv4 exports of an ext4 system mounted with the i_version option. I may give that a try. > Actually: should the NFSv4 server always be using i_version as the > change attribute for directories? ?(Does every exportable filesystem > update it on every directory modification?) It appears to be an option for ext4. I do not see it referenced in XFS. > (And if so, maybe on directories we should factor the i_version into the > low bits of the mtime reported to NFSv3 client?) Probably a bad idea. Runs the risk of "change file A then change file B" resulting in backwards timestamps, which is even worse than 4 millisecond timestamps. - Pat