From owner-freebsd-bugs@freebsd.org Sat Sep 26 15:48:45 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E3F14221B7 for ; Sat, 26 Sep 2020 15:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BzCqx0WX0z3TxV for ; Sat, 26 Sep 2020 15:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0FF0F4222C0; Sat, 26 Sep 2020 15:48:45 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FBBA422235 for ; Sat, 26 Sep 2020 15:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzCqw6lVpz3VCr for ; Sat, 26 Sep 2020 15:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C80BC262F4 for ; Sat, 26 Sep 2020 15:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 08QFmi6O008858 for ; Sat, 26 Sep 2020 15:48:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 08QFmiPu008857 for bugs@FreeBSD.org; Sat, 26 Sep 2020 15:48:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 249871] NFSv4 faulty directory listings under heavy load Date: Sat, 26 Sep 2020 15:48:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 15:48:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249871 --- Comment #1 from Rick Macklem --- Yep, that is weird. Assuming the clients are FreeBSD and not Linux, the only thing I can think of to try is take the "intr" option off the mounts. The BUGS section of "man mount_nfs" notes it should never be used. If somehow a signal were to be posted to the process on the client, that might explain this, if a sleep() returns ERESTART or something like that. --> Anyhow, for reasons mostly related to sessions (or lock sequencing for NFSv4.0) you should never use "intr" nor "soft" on NFSv4 mounts. I'll look through the code, but the NFSv3 and NFSv4 code is very similar for Readdir. One more question: - Are you using nfsuserd or uids in strings? If the former, you could try setting vfs.nfs.enable_uidtostring=3D1 vfs.nfsd.enable_stringtouid=3D1 and then don't run nfsuserd. (When the uid<->name cache misses, the upcall to the nfsuserd could take a long time on the heavily loaded server. However, I cannot think why slow response could cause this unless it is related to using "intr" on the mounts. If the clients are Linux, then I vaguely recall mention of problems with reading large directories being discussed on linux-nfs@vger.kernels.org. --=20 You are receiving this mail because: You are the assignee for the bug.=