Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 22 Jan 2021 09:47:53 -0500
From:   "J. Bruce Fields" <bfields@redhat.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        Trond Myklebust <trondmy@hammerspace.com>,
        Anna Schumaker <schumakeranna@gmail.com>,
        Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH 2/3] nfsd: move change attribute generation to filesystem
Message-ID: <20210122144753.GA52753@pick.fieldses.org>
References: <1611084297-27352-1-git-send-email-bfields@redhat.com>
 <1611084297-27352-3-git-send-email-bfields@redhat.com>
 <20210120084638.GA3678536@infradead.org>
 <20210121202756.GA13298@pick.fieldses.org>
 <20210122082059.GA119852@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210122082059.GA119852@infradead.org>
Precedence: bulk

On Fri, Jan 22, 2021 at 08:20:59AM +0000, Christoph Hellwig wrote:
> On Thu, Jan 21, 2021 at 03:27:56PM -0500, J. Bruce Fields wrote:
> > I also have a vague idea that some filesystem-specific improvements
> > might be possible.  (E.g., if a filesystem had some kind of boot count
> > in the superblock, maybe that would be a better way to prevent the
> > change attribute from going backwards on reboot than the thing
> > generic_fetch_iversion is currently doing with ctime.  But I have no
> > concrete plan there, maybe I'm dreaming.)
> 
> Even without the ctime i_version never goes backward, what is the
> problem here?

Suppose a modification bumps the change attribute, a client reads
the new value of the change attribute before it's committed to disk,
then the server crashes.  After the server comes back up, the client
requests the change attribute again and sees an older value.

That's actually not too bad.  What I'd mainly like to avoid is
incrementing the change attribute further and risking reuse of an old
value for a different new state of the file.

Which is why generic_fetch_iversion is adding the ctime in the higher
bits.

So we depend on good time for correctness.  Trond has had some concerns
about that.

Something like a boot counter might be more reliable.

Another interesting case is after restore from backup.

--b.