Bug#962254: NFS(v4) broken at 4.19.118-2
Hi Elliott,
Thanks for the additional information.
On Fri, Jun 05, 2020 at 10:43:49AM -0700, Elliott Mitchell wrote:
> On Fri, Jun 05, 2020 at 08:44:26AM +0200, Salvatore Bonaccorso wrote:
> >
> > On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote:
> > > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
> > > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken.
> > > Mounting an appropriate filesystem became unreliable, and once mounted
> > > behavior is unpredictable.
> > >
> > > In particular in the problematic case `umask 022 ; touch foo ; ls -l foo`
> > > yields a -rw-rw-rw- file.
> > >
> > > This occurs if *both* the server *and* client are on 4.19.118+2. I have
> > > confirmed this does NOT occur if the server is on a 4.9 kernel. I have
> > > also confirmed this does NOT occur if the client is on a 4.9 or
> > > 4.19.98+1+deb10u1 kernel.
> >
> > I cannot reproducde the described behaviour. Can you give more details
> > on your setup?
> >
> > How do you export the filesystem?
> > What is the underlying filesystem exported?
> > How and whith which options do clients mount the NFS share?
>
> Presently it is a whole directories being exported to hosts. The
> filesystem on the server is ZFS.
>
> Client is mounting hard,intr. Client is using cachefilesd, but that
> appears unrelated to the issue.
>
> As this is NFSv4 (v2 and v3 are thoroughly disabled on the server), TCP
> is being used. The port is non-standard.
>
> I'm uncertain I properly tried server on 4.9, client on 4.19.118+2 (could
> be this is strictly 4.19.118+2 NFSv4 client code).
This now let some rings bell, the described scenario is very similar
to what was reported in https://bugs.debian.org/934160
Respectively
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and
https://bugzilla.redhat.com/show_bug.cgi?id=1667761 .
Salvatore
Reply to: