Date: Thu, 3 Sep 1998 13:05:45 -0400 (EDT) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: Jay <jay@oneway.com> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: .nfs files, what causes them and why do they hang around? Message-ID: <Pine.SUN.3.91.980903130102.19595I-100000@terra> In-Reply-To: <Pine.BSF.4.02.9809031225350.16712-100000@tidal.oneway.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The infamous .nfs files. An artifact of stateless servers: you can't do a remove over nfs, since it is impossible to ever know that a file is not used, since there is no server state that could tell you such a thing. In fact you're not really safe removing .nfsxxxx files unless they're pretty old, since again you can't know that there is not some client out there that may not have accessed it for a few days, but may still be paging code from it at some point (think: /usr/local/bin/whatever). So check in the nfs client-side code for the silly rename that redirects the unlink operations to renaming a file to .nfsxxxxx, so that it is not found the next time it is looked up. There you can see how it works. Sometimes you see funny things like people removing .nfs files from a client, which of course results in different .nfsxxxx files. You have to remove these clunkers via (typically) cron jobs on the server. Lock files would certainly create these. run NFS over tcp if you possibly can. ron Ron Minnich |"Using Windows NT, which is known to have some rminnich@sarnoff.com | failure modes, on a warship is similar to hoping (609)-734-3120 | that luck will be in our favor"- A. Digiorgio ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.980903130102.19595I-100000>