Control: tag -1 moreinfo

On Fri, 2022-08-19 at 13:16 +0000, Jason Breitman wrote:
> Package: nfs-common                        
> Version: 1:1.3.4-6
> Severity: important
> Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> GNU/Linux
> -- Description
>     After updating and or creating new files on our file server via
> rsync, we see many files report the error message below from NFSv4
> clients since upgrading from Debian 10.8 to Debian 11.4.
>     Clearing the dentry cache resolves the issue right away.
>     I am not sure that nfs-common is the package to blame, but listed
> it based on the bug submission recommendations. 

The NFS implementation is mostly in the kernel, so probably this issue
belongs there.  But the kernel team is responsible for both packages.

> -- Error message
>     ls: cannot access 'filename': No such file or directory
>     -????????? ? ?    ?            ?            ? filename

So we know the file's there but can't stat it.  I think this means the
client has cached the handle of the old file of that name, which has
been deleted.

- Are client and server clocks closely synchronised?  If not, that
needs to be fixed.

- Are clients likely to read this directory while rsync is running, or
shortly before?  If so, it may help to reduce the attribute caching
timeout on the client.  See the "Directory entry caching" section in
the nfs(5) manual page.

I don't know why you're only seeing this after an upgrade of the
clients, though.  I'm not aware that there has been any big change to
attribute caching.


Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to