Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "NFS Traumatized Linux User" <nfstrauma@busy-byte.org>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: CentOS 8 + Kerberized NFS homes / AutoFS -> can't get this to run
 properly, many actions heavily delayed, freq. mouse/kbd freezes -> NFS issue?
Date:   Thu, 13 Aug 2020 07:45:32 -0400
Message-ID: <534BA86A-9A94-4B0A-98ED-11E171BE63A7@redhat.com>
In-Reply-To: <f68660cb18742f7dfdd8a796a610329d@webmail.busy-byte.org>
References: <f68660cb18742f7dfdd8a796a610329d@webmail.busy-byte.org>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On 12 Aug 2020, at 16:05, NFS Traumatized Linux User wrote:

> Hi there,
..
> Any pointers / help would be greatly appreciated.

Delays in the UI on the order of several minutes that are suspected to be
NFS related should be visible in a wirecapture.  Have you tried using
vanilla krb5 and if the delays are still there, what does a wirecapture of
the NFS traffic look like?  Are there long delays between each RPC call and
reply?  That's the place I would start.

I can say that this problem sounds a bit like a name resolution problem
somewhere.  Long delays that produce no errors at random times often turn
out to be systems repeatedly trying to use a name server that doesn't reply.
Perhaps either the client or server's name services are trying to look up an
identifier and there's a DNS server record that isn't replying - but that's
a wild guess.

Ben