Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-wg0-f50.google.com ([74.125.82.50]:55450 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933889AbaKNAng (ORCPT ); Thu, 13 Nov 2014 19:43:36 -0500 Received: by mail-wg0-f50.google.com with SMTP id k14so120123wgh.9 for ; Thu, 13 Nov 2014 16:43:35 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20141113235400.GM28565@dastard> References: <20141111162849.GA12527@lst.de> <20141111162704.GA12103@lst.de> <20141111222710.GY23575@dastard> <20141112102440.GA31344@lst.de> <20141113002846.GC23575@dastard> <20141113235400.GM28565@dastard> Date: Thu, 13 Nov 2014 19:43:33 -0500 Message-ID: Subject: Re: [PATCH 2/2] nfsd: implement chage_attr_type attribute From: Trond Myklebust To: Dave Chinner Cc: Christoph Hellwig , "J. Bruce Fields" , Linux NFS Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Nov 13, 2014 at 6:54 PM, Dave Chinner wrote: > On Thu, Nov 13, 2014 at 08:02:43AM -0500, Trond Myklebust wrote: >> On Wed, Nov 12, 2014 at 7:28 PM, Dave Chinner wrote: >> > On Wed, Nov 12, 2014 at 09:26:16AM -0500, Trond Myklebust wrote: >> >> On Wed, Nov 12, 2014 at 5:24 AM, Christoph Hellwig wrote: >> >> > On Wed, Nov 12, 2014 at 09:27:10AM +1100, Dave Chinner wrote: >> >> >> To clarify what Christoph wrote, XFS updates i_version is updated >> >> >> once per transaction that modifies the inode. So if a VFS level >> >> >> operation results in multiple transactions then each transaction >> >> >> will but the version. >> >> >> >> >> >> It was implemented that way because nobody could tell me what the >> >> >> actual granularity requirement for change detection was. Hence what >> >> >> I implemented was "be able to detect any persistent change that is >> >> >> made" to cover all bases. > > FWIW, ext4 takes the same approach. See Ted's post today: > > http://www.spinics.net/lists/linux-ext4/msg46194.html > > "The inode_inc_iversion() in mark4_ext4_iloc_dirty() is probably not > necessary, since we already should be incrementing i_version whenever > ctime and mtime gets updated. The inode_inc_iversion() there is more > of a "belt and suspenders" safety thing, on the theory that the extra > bump in i_version won't hurt anything." > It will hurt if it causes all the NFS clients to blow their caches unnecessarily. Who asked for this? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com