Date: Thu, 21 Nov 1996 11:12:02 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Brian Tao <taob@io.org> Cc: FREEBSD-CURRENT-L <freebsd-current@FreeBSD.org> Subject: Re: "panic: nfs: sillyrename dir" Message-ID: <Pine.SV4.3.95.961121105441.16663A-100000@parkplace.cet.co.jp> In-Reply-To: <Pine.BSF.3.95.961115181627.16615A-100000@cabal.io.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961121105441.16663A-100000>