On Tue, Dec 2, 2008 at 12:36 PM, Ben Rockwood <benr at cuddletech.com> wrote: > Mike Gerdts wrote: >> Over the last couple of months I have noticed lots of .nfs files being >> left around while using cvs. >> >> A typical command: >> >> cvs -d $cvsroot co -d dotnfs-`uname -r` -r $release jass >> >> On snv_99: >> >> $ find dotnfs-5.11 -name .nfs\* | wc -l >> 822 >> >> That number does not diminish over time, unless I use rm to get rid of >> the .nfs files. >> >> However, Solaris 10 looks lots better: >> >> $ find dotnfs-5.10 -name .nfs\* | wc -l >> 0 >> >> I saw similar things on snv_93. I have confirmed that only NFSv3 is >> in use on each system using "nfsstat -c". >> >> Any clues? >> > > .nfs files are created when a file is deleted that is still open. You > should see a cronjob in the root crontab: > > /usr/lib/fs/nfs/nfsfind
The NFS server is a NetApp, so there is likely a different solution needed. It does seem as though it automatically cleans them up on the first read. Unfortunately, if that first read is part of a software release process, the release code may have .nfs files in it. > That cleans up the .nfs* files each week. > > So far the party line has been "fix your app". I've suffered a lot of > .nfs* pain, but I'm not aware of any related bugs atm. $ type cvs cvs is hashed (/usr/bin/cvs) $ cvs --version Concurrent Versions System (CVS) 1.12.13 (client/server) ... Based upon the pstamp for SUNWcvs my guess is that the "go fix your app" is directed at the SFW consolidation. $ pkgparam SUNWcvs VERSION PSTAMP 11.11.0,REV=2008.09.17.14.32 sfwnv20080917143303 FWIW the problem exists with CSWcvs 1.11.22,REV=2006.12.11 as well. Unless there is some long-latent bug in CVS, this looks to be a regression in the NFSv3 client. -- Mike Gerdts http://mgerdts.blogspot.com/
