From owner-freebsd-current Mon Jul 23 10:47:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id DB30C37B419; Mon, 23 Jul 2001 10:46:57 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 23 Jul 2001 18:46:56 +0100 (BST) To: Matt Dillon Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: NFS client unable to recover from server crash In-Reply-To: Your message of "Mon, 23 Jul 2001 09:48:21 PDT." <200107231648.f6NGmLP17709@earth.backplane.com> Date: Mon, 23 Jul 2001 18:46:53 +0100 From: Ian Dowse Message-ID: <200107231846.aa35761@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200107231648.f6NGmLP17709@earth.backplane.com>, Matt Dillon writes: > Ian, please don't do this. The whole point of having an uninterruptable > mount is so the client can survive a server reboot or network failure. > Doing this destroys uninterruptable semantics. Firstly, I have no intention of committing this patch anytime soon, but I think you are mistaken in what it does. Unless I messed up, it will never allow "uninterruptible" mounts to be interrupted by signals or to time out. I set the socket timeout to 10 seconds, but that will have no effect because the code will simply loop around and retry again. It is nfs_sigintr() that detects signals, and it returns immediately unless the NFSMNT_INT mount flag is set. Similarly, the request only times out if rep->r_rexmit >= r_retry, but unless it is a "soft" nfs mount, r_rexmit is clamped at NFS_MAXREXMIT, and r_retry is set to NFS_MAXREXMIT + 1, so this can never happen. The only effect of changing that timeout value (again assuming I have not misread the code) is to allow any request that does get marked R_SOFTTERM to time out within a finite period. For hard mounts, the _only_ way that this can happen is via the new nfs_nmcancelreqs() which is called when you do a forced unmount. No, I haven't gone mad and decided to make all NFS mounts soft to "fix" all NFS problems :-) Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message