Hi Olga,
On 21.02.22 02:19, Kornievskaia, Olga wrote:
On 2/20/22, 6:17 PM, "Kurt Garloff" <kurt@xxxxxxxxxx> wrote:
Hi Olga,
two updates:
On 20.02.22 23:26, Kurt Garloff wrote:
> Hi Olga,
>
> your upstream commit 1976b2b3, applied to 5.15.24 as 6f283634 breaks NFS
> for me.
>
> This is while mounting many NFS filesystems from two NFS servers, one
> Qnap (nfs v4.1) and one linux 5.15.16 knfsd (nfs v4.2).
I have to correct myself. All volumes broken by 5.15.24 come from Qnap.
> The NFS mounts just would not succeed. This appears to happen to all
> Qnap mounts and one of the mounts from the linux knfsd.
This mount also cam from Qnap -- in my mind I had migrated it already,
but not in reality :-O
> I did some bisecting in 5.15.24 ... reverting 6f283634 and subsequent
> NFS/sunRPC patches from you and Xiyu, Anna did the trick to recover from
> this failure.
> To be precise: I reverted 4403233b 4b22aa42 5ca123c9 c5ae18fa be67be6a
> 6f283634 2df6a47a 0c5d3bfb 3cb5b317 58967a23 bbf647ec and 38ae9387 in
> 5.15.24. I started reenabling and 2df6aa647a is the last patch that
> still results a working NFS for me.
Also, taking plain 5.15.24 and just reverting 6f283634 creates a
kernel that works well with Qnap NFS shares.
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?
Best,
--
Kurt Garloff <kurt@xxxxxxxxxx>
Cologne, Germany
