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
