Date: Fri, 15 Nov 1996 18:28:16 +0000 () From: Brian Tao <taob@io.org> To: FREEBSD-CURRENT-L <freebsd-current@freebsd.org> Subject: "panic: nfs: sillyrename dir" Message-ID: <Pine.BSF.3.95.961115181627.16615A-100000@cabal.io.org>
next in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961115181627.16615A-100000>