From owner-freebsd-current Thu Aug 1 03:13:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA08301 for current-outgoing; Thu, 1 Aug 1996 03:13:05 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA08296 for ; Thu, 1 Aug 1996 03:13:03 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id DAA07104; Thu, 1 Aug 1996 03:12:38 -0700 (PDT) To: Tony Jago cc: freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... In-reply-to: Your message of "Thu, 01 Aug 1996 11:30:56 +1000." Date: Thu, 01 Aug 1996 03:12:38 -0700 Message-ID: <7102.838894358@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 1. The inability to mount file systems. The clients start barfing with > something like "RPC mount timeout". This problem goes away after a > while as the clients retry. I think its the mountd getting too many > requests at once. Each client mounts 9 file systems. I think that this is a more generic NFS bug in -current. I can reproduce this, even causing mountd to silently exit (no core, no syslog msg) with just one client and some fierce AMD-assisted pounding on a 2.2-current NFS server. Debugging this will be challenging, so all the help we can get will be useful. If you can add some extra logging to strategic spots in your mountd, perhaps, and analyse the data generated you might even find the fix yourself. > 2. Files permissions are read incorrectly. Files that should be able to > be executed are giving "permission denied" messages. Sometimes even > the kernel can't be loaded by netboot.com but if you persist by > typing "autoboot" it will magically start to work. Machines fail to > boot correctly as programms called in /etc/rc don't start > (permission denied). Probably more NFS bogosity. > 3. Pageing in of binaries cause the system to panic. Vnode_pager does > not seem to like it when it can't page in executables, even when the See #2. :-) > version 2 with hard mounts. I tryed NFSv3 (both TCP and UDP) for a while > but it was even worse. The servers have 16 nfsd's running and the That's not surprising. > clients have 4 nfsiod's. The most stable configuration I have found at > this stage has been 2.2-960612-SNAP but I am open to suggestions. 2.1.5? Its NFS is still unstable, but I don't believe anywhere near the state it's in with -current. Jordan