From owner-freebsd-current Wed Nov 20 11:03:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27624 for current-outgoing; Wed, 20 Nov 1996 11:03:08 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA27617 for ; Wed, 20 Nov 1996 11:03:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11518; Wed, 20 Nov 1996 11:48:24 -0700 From: Terry Lambert Message-Id: <199611201848.LAA11518@phaeton.artisoft.com> Subject: Re: "panic: nfs: sillyrename dir" To: adam@veda.is (Adam David) Date: Wed, 20 Nov 1996 11:48:24 -0700 (MST) Cc: taob@io.org, freebsd-current@FreeBSD.org In-Reply-To: <199611201132.LAA25850@veda.is> from "Adam David" at Nov 20, 96 11:32:27 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I am seeing .nfs* files left in the filesystem long after they are active, > perhaps this simply results from rebooting the client machine? Yes. The state that says "delete this object with a real delete on 1->0 reference count" exists only on the client, and is destroyed when the client crashes. It is the NFS "close" on the client that destroys objects tagged this way. In general, there will not be file name collisions, since the name is supposed to be manufactured from sysid and pid. If a lookup succeeds, it will succeed in the name space segment of the system with the same systemid... thus, it is legal for a system to do a lookup and a create, as long as the client process isn't multithreaded (ie: more than one kernel entry on a PID simultaneously), or the client access is per process mutexed. In the general kernel multithreading case, this is not a problem, since the remote PID is replaced by the remote LWP ID on the way to the NFS host, and they are unique, no matter how many threads you have in the same process. Either way, collisions will not occur, and you are safe (FreeBSD is not process reentrant for deletes anyway). It is the responsibility of the NFS server to run a process (after sufficient time has passed for NFS clients to reestablish their mount instances) to clean up these files (generally, using a cron job that references RPC.statd to ensure that deletion by ".nfs*" will not selete any active files. An rcp.statd client reboot detection is a license to log rename events of the appropriate pattern and exclude them from the deletion pass for the system ID, but allow the deletion of unprotected objects otherwise. In general, the rpc.statd now works, so this could be implemented on the server side). > I am also noticing 'make clean' sometimes needs to be repeated multiple times > on an NFS mounted directory, because of an infamous "rm: directory not empty". A cached file in the client buffer cache will maintain a reference even after deletion for the cache timeout duration if there is a vnode reference in the name cache for the object. This is an issue you need to take up with the VM guru's. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.