open O_CREAT | O_EXCL on NFS in Linux?

Question

When in the Linux 2.6 kernel and in NFSv3 did open("fname", O_CREAT|O_EXCL) became valid? The current canonical open(2) system call documentation (http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html) says everything is fine:

• O_EXCL
  
  • ...
On NFS, O_EXCL is only supported when using NFSv3 or later on kernel
2.6 or later. In NFS environments where O_EXCL support is not
provided, programs that rely on it for performing locking tasks will
contain a race condition. Portable programs that want to perform
atomic file locking using a lockfile, and need to avoid reliance on NFS
support for O_EXCL, can ...

This reads as though all 2.6 kernels are OK, but the man page changelog (ca late kernel 2.6.23) begins indicating validity four years after 2.6.0 went live, and the web is rife with boards users censuring this use within the last year or two. I'd like to use this setup on RHEL 5 (2.6.18) systems, but I couldn't pin down when it truly became safe. Does anyone have a definitive answer? Thanks!

Answer 1

Apparently, the NFS guys claim that anything from NFSv3 and Linux 2.6.5 on is OK.

From http://nfs.sourceforge.net/#faq_d10:

• D10. I'm trying to use flock()/BSD locks to lock files used on multiple clients, but the files become corrupted. How come?
  • A. flock()/BSD locks act only locally on Linux NFS clients prior to 2.6.12. Use fcntl()/POSIX locks to ensure that file locks are visible to other clients.
  • Here are some ways to serialize access to an NFS file.
    • Use the fcntl()/POSIX locking API. This type of locking provides byte-range locking across multiple clients via the NLM protocol, or via NFSv4.
    • Use a separate lockfile, and create hard links to it. See the description in the O_EXCL section of the creat(2) man page.
  • It's worth noting that until early 2.6 kernels, O_EXCL creates were not atomic on Linux NFS clients. Don't use O_EXCL creates and expect atomic behavior among multiple NFS client unless you are running a kernel newer than 2.6.5.
  • ...