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:   Mon, 23 Aug 2021 11:11:27 -0400
From:   "bfields@fieldses.org" <bfields@fieldses.org>
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: sporadic generic/154 failure
Message-ID: <20210823151127.GB883@fieldses.org>
References: <20210823144802.GA883@fieldses.org>
 <e3ea3f425fb8765d13e7b73aaf7df5022c4183e5.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e3ea3f425fb8765d13e7b73aaf7df5022c4183e5.camel@hammerspace.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Mon, Aug 23, 2021 at 03:06:21PM +0000, Trond Myklebust wrote:
> On Mon, 2021-08-23 at 10:48 -0400, J. Bruce Fields wrote:
> > I'm seeing generic/154 failing sometimes.
> > 
> > It does a "cp --reflink" (which uses FI_CLONE, which results in a
> > ->remap_file_range call that NFS maps to the CLONE operation), then
> > overwriting parts of the fire, and checking free blocks (with "stat -f
> > /path -c "%f") at various points, and failing when the number of free
> > blocks is outside an expected range.
> > 
> > I don't know if it might be some caching issue, or something about how
> > NFS reports free blocks.
> > 
> > Honestly it looks unlikely to be critical, so for now I'm ignoring
> > it....
> > 
> 
> XFS backend?

Yes.

> It could be speculative preallocation. The fact that NFS
> can defer closing the file (either due to delegations or due to the
> NFSv3 file cache) typically results in it taking longer for XFS to free
> up the blocks it preallocated. That again means it takes longer for the
> 'space used' to settle to the correct final value.
> 
> https://linux-xfs.oss.sgi.narkive.com/jjjfnyI1/faq-xfs-speculative-preallocation

That sounds plausible.

--b.