Re: 6f283634 / 1976b2b3 breaks NFS (QNAP/Linux kNFSD)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Feb 23, 2022, at 5:00 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
> 
> 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.

knfsd, or mountd? Is there known to be a server-side fix available?


--
Chuck Lever







[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux