On Wed, 2022-02-23 at 18:06 +0000, Chuck Lever III wrote: > > > > 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. > The GETATTR is a request for fs_locations in order to probe for alternative IP addresses. IIRC, some earlier implementations of knfsd had this response when the mountd daemon wasn't configured to expect a referral upcall for that location. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
