On Tue, 02 Dec 2008 23:04:39 +0100, Mike Gerdts <mgerdts at gmail.com> wrote:
> Unless there is some long-latent bug in CVS, this looks to be a > regression in the NFSv3 client. quite possibly: nfs3_inactive can leave .nfsXXX files behind http://bugs.opensolaris.org/view_bug.do?bug_id=5029852 I've moved the comments to the description, but they are not yet visible, so here they are for the time being: <snip> While testing fix for 4903465, I found an error path which could leave behind .nfsXXX files on the server. If a open file has been renamed or unlinkied then r_unldvp will be set. nfs3_inactive() checks if r_unldvp is present and if so does the remove operation for the .nfs file on the server. Before we do the remove we unset r_unldvp. If the thread which is doing the remove gets signalled before entering rfscall(), then rfscall() will fail returning RPC_INTR as the status. Back in nfs3_inactive() we do not do anything with unldvp if the call has failed. And we add the rnode to the free list. So the .nfsXXX file gets left behind. The number of files left behind can be huge if we are entering nfs3_inactive() through nfs_purge_caches() of a directory and the thread gets signalled in between. Since the only place we check for the signal is rfscall() in the code path of nfs_purge_caches() -> dnlc_purge_vp() -> nfs3_inactive() -> rfs3call() -> rfscall() we will end up with lot of .nfsXXX files on the server. <snip end> -- frankB It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
