sporadic generic/154 failure

sporadic generic/154 failure

[J. Bruce Fields]

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....

--b.

Re: sporadic generic/154 failure

[Trond Myklebust]

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? 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


-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: sporadic generic/154 failure

[bfields]

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.