From owner-freebsd-fs@freebsd.org Thu Jan 28 00:20:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D2F7A70D7F for ; Thu, 28 Jan 2016 00:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24EC8DA1 for ; Thu, 28 Jan 2016 00:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0S0Kn7C047804 for ; Thu, 28 Jan 2016 00:20:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206634] "panic: ncllock1" from FreeBSD client after NFSv4 server was taken offline and brought back to life; lots of spam about "protocol prob err=10006" Date: Thu, 28 Jan 2016 00:20:49 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@uoguelph.ca X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:20:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206634 rmacklem@uoguelph.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@uoguelph.ca --- Comment #1 from rmacklem@uoguelph.ca --- I will take a look at the panic someday, to see if it can be avoided. I will note that 10006 is NFSERR_SERVERFAULT, which is a "catch-all" for "horrible bad things are happening that you want to avoid like the plague". (As such, a panic is probably a good thing to have happen.) NFSv4 servers are not like NFSv3 ones. They are stateful. As such, you need to always unmount all mounts before shutting down/rebooting or similar to the server. If the server crashes, then there is a recovery protocol after the server reboots, but the server must crash/reboot to invoke this. (If a crash/reboot happened, it is too late to figure out what went wrong, because you'd need a packet trace from the point where the server reboots to figure out what happened w.r.t. this recovery protocol. Btw, this recovery protocol is more complex than the entire NFSv3 protocol, so I wouldn't be surprised if the code does have problems.) You said "brought offline". If that didn't mean "reboot" when it came back online, then you definitely would break any NFSv4 mounts badly. The only exception would be a case where the server is offline (due to network shutdown or killing/restarting the nfsd threads or ???) for less than 1-2 minutes (the FreeBSD server uses a 2minute lease duration and that is the upper bound on how long the server can be unavailable without bad things happening). The only use for this I can think of is: - If you were running a kernel without "options NFSD", so the nfsd.ko is loaded. - You wanted to replace the nfsd.ko with one that has been patched. --> You could kill the nfsd threads, kldunload nfsd.ko, kldload the new nfsd.ko and restart the nfsd threads within 1minute. There probably isn't anywhere in the man pages that emphasizes that you can't take an NFSv4 server "offline" without unmounting all the client mounts and this should be fixed. --=20 You are receiving this mail because: You are the assignee for the bug.=