From owner-freebsd-current Wed Nov 20 18:12:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26960 for current-outgoing; Wed, 20 Nov 1996 18:12:35 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA26947 for ; Wed, 20 Nov 1996 18:12:30 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id CAA16848; Thu, 21 Nov 1996 02:12:03 GMT Date: Thu, 21 Nov 1996 11:12:02 +0900 (JST) From: Michael Hancock To: Brian Tao cc: FREEBSD-CURRENT-L Subject: Re: "panic: nfs: sillyrename dir" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I haven't looked at the sillyname algorithm. It really depends on how well it picks out a name. NFS is stateless so it is hard to preserve Unix semantics when deleting a file that is open by another process. In Unix when a file is deleted, any process that has the file open can continue to use it. The inactive call detects last close of a deleted file and does the actual remove. When the nfs client detects an attempt to delete an open file, it renames to the file to a name that is unlikely to conflict and then removes the file on last close. If you have more than 1 nfs client it is possible to get sillyname collisions. If another client deletes the file then you will get a stale file error. If the server crashes between the rename and the remove, you get garbage files left behind. Regards, Mike Hancock On Fri, 15 Nov 1996, Brian Tao wrote: > 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" >