NFS Question

Derek D. Martin ddm+gnhlug at pizzashack.org
Thu Aug 29 16:40:06 EDT 2002


At some point hitherto, Jon Hall hath spake thusly:
> 2) What sort of problems are there with NFS on Linux? I have heard that
> there are file locking problems, but nothing really in depth. Anyone
> care to elaborate?
> 
> Depends what you mean by "file locking".  Do you mean "creating a lock file"?
> 
> Normally "creating a lock file" works fairly well with the NFS that is on
> Linux, since creation of a file is one of those things that NFS takes as
> an atomic operation, goes all the way through to the disk surface of the
> server before the client moves on.

One way of creating a lock file is done using the O_EXCL
option to open(2).  From the manpage for that system call:

              O_EXCL is broken on NFS  file  sys­
              tems,  programs  which  rely  on  it for performing
              locking tasks will contain a race  condition.   The
              solution for performing atomic file locking using a
              lockfile is to create a unique file on the same  fs
              (e.g., incorporating hostname and pid), use link(2)
              to make a link to the lockfile. If  link()  returns
              0,  the lock is successful.  Otherwise, use stat(2)
              on the unique file to check if its link  count  has
              increased to 2, in which case the lock is also suc­
              cessful.

However, kernel developers at MCL have told me that because NFS by
default uses asyncronous I/O, this also contains a race condition.
According to at least one developer, the only method of reliably
locking a file on Linux (aside from forcing NFS to use syncronous I/O,
which does make it slow) is to use fcntl(2) locking, which does not
depend on the atomic creation of a lock file.  For THIS method to work
reliably in the case of a crashed server, you must have an nfs-utils
package with a non-broken statd, meaning it will be v0.3.1 or later.
Systems current with RH 6.2 have an older, broken nfs-utils.

The trouble with this is, according to other sources I've come across
(such as W. Richard Stevens' "Advanced Programming in the Unix
Environment", many other implementations of NFS have a buggy lockd and
statd, which prevents kernel-based locking from working reliably on
those platforms.  So if you're in a homogenious environment, you may
just have to live with NFS locking being broken and unreliable.

This may well have changed; my info is about a year old, and the man
page from which I quoted may certainly be out of date.  The Stevens
reference is from a book published in 1992, so your vendor may well
have fixed their buggy lockd/statd by now.  YMMV, caveat emptor, have
a nice day.  =8^)

-- 
Derek Martin               ddm at pizzashack.org    
---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20020829/ac975cb7/attachment.bin


More information about the gnhlug-discuss mailing list