Date: Fri, 22 Nov 2019 00:56:10 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242146] nfs root mount may loop endlessly without hint on console Message-ID: <bug-242146-227-3ACbYdf4JS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-242146-227@https.bugs.freebsd.org/bugzilla/> References: <bug-242146-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242146 --- Comment #1 from Rick Macklem <rmacklem@FreeBSD.org> --- Well, the problem with setting a limit is "how long"? I know of a FreeBSD NFS server that exports over 72,000 file systems. I suspect that startup of a server like this can take a while and some systems would simply want to retry until the server is up, I think? I also don't see much use in a panic(), since a dump or stack trace isn't useful and another reboot cycle will presumably end up in the same state. I can see that spitting out a single message to the console along the lines of "Can't connect to NFS server" would be useful, so that sysadmins would know why the boot has wedged. I'll have to take a look at the code to see if the mount root case can be identified where it loops attempting reconnects, so a message can be generated for that case. I think newnfs_connect() does the socreate() and returns an error when it fails. However, newnfs_request() ignores any error return, so a message could possibly be generated there. All of the above is just mho. I think you should ask on a mailing list (FreeBSD-fs@ maybe?) to see what others think is the correct behaviour for this case. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242146-227-3ACbYdf4JS>