> On Feb 21, 2022, at 5:48 AM, Kurt Garloff <kurt@xxxxxxxxxx> wrote: > > Hi, > > On 21.02.22 10:31, Kurt Garloff wrote: >> Hi Olga, >> >> On 21.02.22 02:19, Kornievskaia, Olga wrote: >>> [...] >>> Is it possible for you to provide a network trace? >> >> Yes. >> >> Is tcpdump what you'd like to see? wireshark's dumpcap? >> Any NFS specific tracing tools I should be using? >> >> One trace with a working kernel and one with the broken one? > > Comparing the good and the bad trace ... > > mount -t nfs 192.168.155.74:/Public /mnt/Public > against Qnap 4.3.4.xxx NFS v4.1 server. > > Both do: > > Establish conn > NFS NULL (ack) > NFS EXCHANGE_ID (4.2 -> NFS4ERR_MINOR_VERS_MISMATCH) > Teardown and reestablish > NFS NULL (ack) > NFS EXCAHNGE_ID (4.1 -> ack) > NFS EXCAHNGE_ID (4.1 -> ack) > NFS CREATE_SESSION (ack) > NFS RECLAIM_COMPLETE (CB_NULL, ack) > NFS_SECINFO_NO_NAME (ack) > NFS PUTROOTFH|GETATTR (ack) > NFS GETATTR FH:0x62d40c52 (ack), 8 times > NFS ACCESS FH_ -x62d40c52 (denied md xt dl, alllowed rd lu) > NFS LOOKUP DH:0x62d40c52/Public (ack) > NFS LOOKUP DH:0x62d40c52/Public (ack) > NFS GETATTR FH:0x8ee88cee (ack), 3 times > > > Now the differences start: > > The fixed NFS client repeatedly gets ack back, the broken NFS client gets > > NFS GETATTR FH:0x8ee88cee (NFS4ERR_DELAY), repeating forever (exp. backoff) Any idea why the server is not able to respond properly to the GETATTR request? That seems like the root of the problem. -- Chuck Lever
