.nfsXXXX - NFS

This is a discussion on .nfsXXXX - NFS ; Hello, on an AIX 5.1 I make many file oparations in a directory 'mydir' with a python script. At the end of the script I want to remove all files in 'mydir' with the python function os.remove(). In some runs ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: .nfsXXXX

  1. .nfsXXXX

    Hello,

    on an AIX 5.1 I make many file oparations in a directory 'mydir' with a
    python script.
    At the end of the script I want to remove all files in 'mydir' with the
    python function os.remove().
    In some runs I can not remove all files, because a file .nfsXXXX exists.

    Why does a .nfsXXXX file exist?
    How can I remove this file?

    Thank you for your hints, Thomas





  2. Re: .nfsXXXX

    In article <35kaauF4npmfmU1@individual.net>,
    Thomas Rademacher wrote:
    >Hello,
    >
    >on an AIX 5.1 I make many file oparations in a directory 'mydir' with a
    >python script.
    >At the end of the script I want to remove all files in 'mydir' with the
    >python function os.remove().
    >In some runs I can not remove all files, because a file .nfsXXXX exists.
    >
    >Why does a .nfsXXXX file exist?
    >How can I remove this file?
    >
    >Thank you for your hints, Thomas
    >


    The .nfsXXXX file is created by the NFS client. This is done in order
    to preserve the UNIX file system semantics which dictate that a file's
    contents are available as long as at least one reference to the file
    exists in the system.

    Here is how this works:

    - The end of your script - which is running on the client for reasons
    we shall see immediately - removes the last file system reference to
    the file (i.e., the last - and in most cases only - directory entry
    which points to the file).

    - However, also on the client machine, a *process* still has the same
    file opened.

    - Since NFS is a stateless protocol (or at least nearly so, with the
    only state shared between client and server being the NFS cookies),
    the server has no information about how many files of it are opened
    on remote machines.

    - Hence, if something (even a client) removes the last file system
    reference (i.e., directory entry) to a file on the server, *and*
    no process on the server itself has the file open, the server will
    free all storage associated with the file, thus losing the file
    contents.

    - But, as said above, a process on the client machine still has the
    file in question open. Losing any possibility of accessing this
    file would therefore break UNIX file access semantics, at least from
    this client machine's point of view.

    - Therefore, in order to force the server to keep the file's contents,
    the *client* tells the server that instead of really deleting the
    file, it should rather rename it to a .nfsXXXX file (UNIX's famous
    "sillyrename" function). This way, the "real"/"old" name (and file
    system reference) of the file is deleted, but the file's contents
    are still available (because the server has to keep them for the
    .nfsXXXX directory entry), thereby fulfilling the UNIX file system
    semantics.

    - Later, when the (last) process on the client which holds the (last)
    reference to the file closes this file, the *client* will silently
    delete the .nfsXXXX file.

    The rename and actual deletion are all handled by the client OS, which
    is the only entity holding the full state information.

    All of this has the following implications:

    - Using scripts on the *same* client that has the file in question
    open to delete the .nfsXXXX file will just result in another file
    with a new number being generated.

    - You just need to wait until all processes on the *same* client which
    have the file open, close it, and the .nfsXXXX file will vanish
    "automagically".

    - If the client crashes before the "automagic" remove happens, .nfsXXXX
    files will accumulate on the server.

    - Let us call the client machine with the process holding the open
    reference to the file "machine A". If a process on either the NFS
    server or any other NFS client machine besides "machine A" deletes
    the file, then "machine A"'s OS clearly has no chance of doing its
    automagic sillyrename thingie, and the file will be gone for good.
    In this case, any further operations the process on "machine A" tries
    to do on this file will fail with "stale file handle" (ESTALE in errno.h).

    Which leads to the conclusion that NFS probably contributed quite a bit
    to what the http://www.simson.net/ref/ugh.pdf is ranting about. :-)

    Regards,

    Martin
    --
    Martin Birgmeier

    Vienna
    Austria

  3. Re: .nfsXXXX


    Martin Birgmeier wrote:

    > Which leads to the conclusion that NFS probably contributed quite a

    bit
    > to what the http://www.simson.net/ref/ugh.pdf is ranting about. :-)


    There's an SMB client on Linux. Go use that. :-)


+ Reply to Thread