Date: Wed, 20 Nov 1996 11:48:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: adam@veda.is (Adam David) Cc: taob@io.org, freebsd-current@FreeBSD.org Subject: Re: "panic: nfs: sillyrename dir" Message-ID: <199611201848.LAA11518@phaeton.artisoft.com> In-Reply-To: <199611201132.LAA25850@veda.is> from "Adam David" at Nov 20, 96 11:32:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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<system id>*" 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611201848.LAA11518>