From owner-freebsd-current Fri Nov 15 15:29:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26541 for current-outgoing; Fri, 15 Nov 1996 15:29:53 -0800 (PST) Received: from ican.net (ican.net [198.133.36.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA26536 for ; Fri, 15 Nov 1996 15:29:51 -0800 (PST) Received: from gate.ican.net(really [198.133.36.2]) by ican.net via sendmail with esmtp id for ; Fri, 15 Nov 1996 18:29:41 -0500 (EST) (Smail-3.2 1996-Jul-4 #1 built 1996-Jul-10) Received: (from smap@localhost) by gate.ican.net (8.7.5/8.7.3) id SAA18125 for ; Fri, 15 Nov 1996 18:28:32 -0500 (EST) Received: from cabal.io.org(10.1.6.2) by gate.ican.net via smap (V1.3) id sma018121; Fri Nov 15 18:28:11 1996 Received: from localhost (taob@localhost) by cabal.io.org (8.7.6/8.7.3) with SMTP id SAA16632 for ; Fri, 15 Nov 1996 18:28:16 GMT X-Authentication-Warning: cabal.io.org: taob owned process doing -bs Date: Fri, 15 Nov 1996 18:28:16 +0000 () From: Brian Tao To: FREEBSD-CURRENT-L Subject: "panic: nfs: sillyrename dir" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a new and amusing one. ;-) I have two shell servers, one running 2.2-961014-SNAP and the other running 2.2-960501-SNAP. Both have identical hardware and both mount the same nine filesystems from three NFS servers (one is NetBSD 1.1, one is FreeBSD 2.2-961014-SNAP, and one is BSD/OS 2.01). Neither act as an NFS server. A couple of days ago, both of them crashed with the same kernel panic within 97 seconds of each other, "panic: nfs: sillyrename dir". I don't know if this is significant, but it takes about that length of time for one of those shell servers to reboot. In /usr/src/sys/nfs/nfs_vnops.c, there is the following comment block before the nfs_sillyrename() function: /* * Silly rename. To make the NFS filesystem that is stateless look a little * more like the "ufs" a remove of an active vnode is translated to a rename * to a funny looking filename that is removed by nfs_inactive on the * nfsnode. There is the potential for another process on a different client * to create the same funny name between the nfs_lookitup() fails and the * nfs_rename() completes, but... */ But... what?!?! :) Was this double panic just a coincidence? -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"