NFS (.nfs files) causing problems with application
2007-12-25 9:26:00
terrific explanation on these .nfs files
that get generated by NFS:
Kevin Sheehan <Kevin.Sheehan@uniq.com.au>
David Thorburn-Gundlach <david@bae.uga.edu>
Stefan Voss <s.voss@terradata.de>
Jeff Wasilko <jeffw@smoe.org>
Birger Wathne <birger@sdata.no>
Ralph Dell <ralph@mail.co.catawba.nc.us>
Based on what almost everyone said, I need to take a
look at the application that is causing the problem
or get around NFS by not using it for this application
(Netscape Profiler for those who were wondering)
which may be what we'll end up doing.
Below is the summary. Thanks again!
Ju
==================
Original Question:
==================
Can anyone tell me about the .nfs files that get
generated by doing NFS mounting? Below is my
filesystem layout which also shows how I'm mounting
these NFS mount points. We were forced to mount it
the way these mount points this way because our
web-related (all back-end) application will not work
with links. Now the problem comes from these .nfs
files that get generated in various directories in
the mount points that cause numerous other problems
with our program... If anyone has experienced
problems with .nfs files, I would also appreciate
hearing from you.
Below is my filesystem layout:
Filesystem Mounted on
/dev/dsk/c0t3d0s0 /
/dev/dsk/c0t3d0s6 /usr
/dev/dsk/c0t3d0s7 /tmp
/dev/dsk/c0t0d0s6 /archive
/dev/dsk/c0t0d0s7 /usr/local
/dev/dsk/c0t1d0s6 /u01
/dev/dsk/c0t2d0s2 /u02
/dev/dsk/c0t4d0s2 /u03
g16.gweb.com:/u02/gg/docs /u01/gg/docs
g16.gweb.com:/u03/gg/docs/dq /u01/gg/docs/dq
g16.gweb.com:/u03/gg/docs/dq /u02/gg/docs/dq
========
Summary:
========
The .nfs files are created when an open file is
removed but is still being accessed. When a file
that is opened by a client is unlinked (by the
server), a file with a name of the form .nfsXXX
(RENAME -> .nfs<inodeinhex>) is created by the client.
Since the file is not local, the client has to let
the server take care of managing open inodes and
finally removing the file. By renaming the file, it
will appear to have been removed from the directory,
but in reality it is still usable by the process that
has the file open. When the open file is closed,
the
.nfsXXX file is removed. If the client crashes
before the file can be closed, the .nfsXXX file is
not removed.
Birger Wathne <birger@sdata.no>
In the Unix world, an application can hold a file
open even if it has been deleted from the file
system. When the application closes the file it gets
deallocated and disappears. If you remove a file that
is being held open by one or more processes, the
space used by that file will not be freed until the
last application
closes the file.
This semantic cannot easily be transferred to
NFS-mounted file systems, since NFS is stateless.
This means that the server doesn't really know which
hosts are using a file. Each NFS transaction is a
complete
stand-alone and self-sustained transaction.
So what happens if a process on a client machine is
using a file, and it gets deleted on the server?
Obviously, the server immediately removes the file,
as it doesn't know that processes are holding on to
it. If a client process tries to read from the file
it will
receive an I/O error. If the process tries to write
to the removed file, the NFS client software
redirects the write to a file called .nfsXXXX to make
sure you don't accidentally loose any data.
So the problem here seems to be that you have
processes trying to write to files that have been
removed.
Ralph Dell writes:
At the moment I don't have any answers, but I do have
a problem with .nfs files. Our system is a Sparc
1000E, Solaris 2.5.1, patches are current through
11/97. Where we have the problem is in a GIS
(Geographic Information System) application
"Arc/Info". The vendor is ESRI. At times certain
commands will fail because a .nfs file shows up in
the directory where the application is removing
files, and then copying files back into the
directory. When a .nfs file is present the arc/info
command fails and the application generates an error.
ESRI has had a lot of calls on this error but they
have not been able to reproduce it. It is a sporadic
error on our system sometimes happening
a few times a day, and sometimes we will go weeks
without the error.
If I remember correctly I've done a ls -la on the
offending directory, have seen the .nfs, and then
done another ls -la and the file is no longer there.
In other words the file appears and disappears. Also,
and I need to confirm this the next time we have the
problem, if we use a unix rm command to remove the
.nfs file it will be recreated with a slightly
different name. Once the application is exited the
.nfs file disappears.
Please let me know what application you are using and
what you are learning. If you hear from others,
especially arc/info users, you may pass my name on to
them. I would be glad to discuss the problem with
other poor souls out there.
The problem exists on platforms other than Solaris. I
know the arc/info problem has shown up on AIX and
other unix platforms.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
Comments
Got something to say?
You must be logged in to post a comment.
