我认为问题不在于RENAME不是原子的，而在于通过NFS打开文件不是原子的。
NFS使用文件句柄;客户端要对文件做些什么，首先通过LOOKUP获取文件句柄，然后使用获取的文件句柄执行其他请求。最少需要两个数据报，在特定情况下，它们之间的时间可能相当“长”。
我想，在您身上发生的是客户端（client 1）执行LOOKUP;在那之后，LOOKUP文件作为RENAME的结果被删除（由client 2）; Filehandle client 1 has不再有效，因为它引用的是inode，而不是命名路径。
这一切的原因是NFS的目标是无状态。此PDF中的更多信息：http://pages.cs.wisc.edu/~remzi/OSTEP/dist-nfs.pdf
在第6页和第8页中，对这种行为进行了很好的解释。

在这种情况下，是否真的不可能获得ENOENT？
很有可能。RFC 3530说道：
该操作对于客户端是原子的。
这很可能意味着它必须对 * 调用此操作的客户端 * 是原子的，而不是所有客户端。
进一步说：
如果目标目录已包含名称为.在重命名发生之前移除现有目标。
这就是为什么 * 其他 * 客户端有时会得到ENOENT。
换句话说，rename在NFS上不是原子的。

作为开发人员，我对如何正确更新应用程序的NFS驻留配置文件感兴趣。此文件经常被读取，但是，在应用程序更新时，由于方案更新，它会被重写。重要的是，在更新时，应该保留现有的内容，同时应该创建一个“默认”配置文件（如果不存在）。而真正的 * 原子重命名 * 这是简单的，on NFS there is a small time slot，其中文件不存在。因此，读者不能仅仅因为找不到“默认”配置文件就简单地创建它。然而，在NFS上，这个问题似乎可以使用下面的脚本解决。基本程序是：

• 更新atomically create a lock_dir，重命名，同步，并删除锁定
• 读取器为不存在的文件和陈旧的读取做好准备，因此它们本身成为更新器。一旦他们得到了锁，他们会尝试再次读取配置文件，以区分file-in-update和file-not-exist。

这个概念的C++实现可以在here中找到，下面是一个独立的Python脚本。
使用方法：

# start writer with
$ echo abc > foo; rm tmp*; rmdir foo_LOCK/; ./renametest.py foo 1
# On another machine, start reader with
$ ./renametest.py foo 0

很快，你就会看到这样的信息

iter 481 stale file handle
iter 16811 file not found
iter 16811 failed to obtain lock. Giving up.

这表明某些进程在试图获得锁时饥饿太久。但是，该文件要么已成功读取/更新，要么未成功。没有腐败。不错啊
剧本：

#!/usr/bin/env python3

import os
import sys
import tempfile
import errno
import time

def eprint(*args, **kwargs):
    print('iter', g_iter, *args, file=sys.stderr, **kwargs)

def lock_file_name(filename):
    return filename + '_LOCK'

def try_lock(filename):
    try:
        os.mkdir(lock_file_name(filename))
        return True
    except FileExistsError:
        return False

def abc_or_die(filename):
    with open(filename, 'r') as f:
        content = f.read()
    if content != "abc\n":
        eprint("ERROR - bad content:", content)
        exit(1)

def update_it(filename):
    cwd = os.getcwd()
    for i in range(10):
        if not try_lock(filename):
            time.sleep(1)
            continue

        # 'Updating' a cfg file usually means to read it first,
        # which should now be safe:
        abc_or_die(filename)

        tmp_file = tempfile.NamedTemporaryFile(delete=False, dir=cwd).name
        with open(tmp_file, 'w') as f:
            f.write("abc\n")

        # almost-atomic-replace on NFS
        os.rename(tmp_file, filename)
        # sync, before releasing the lock. Otherwise, there is still a small slot,
        # where the lockdir is removed, while the config-file rename is still in progress
        os.sync()
        os.rmdir(lock_file_name(filename))
        return True

    eprint('failed to obtain lock. Giving up.')

def handle_read_fail(filename):
    for i in range(10):
        if not try_lock(filename):
            time.sleep(1)
            continue
        # got the lock
        if not os.path.exists(filename):
            # TODO: in the real world, we would create the config file now.
            # Here we require it to exist
            eprint('ERROR: got lock but file does not exist')
            exit(1)
        abc_or_die(filename)
        os.rmdir(lock_file_name(filename))
        return True

    eprint('failed to obtain lock. Giving up.')



def read_it(filename):
    try:
        with open(filename, 'r') as f:
            content = f.read()
            if len(content) == 0:
                eprint('file is empty')
                handle_read_fail(filename)
                return

            if content != "abc\n":
                eprint("ERROR - bad content:", content)
                exit(1)
            # eprint('red success on first try!')
            return True
    except OSError as e:
        if e.errno == errno.ENOENT:
            eprint('file not found')
        elif e.errno == errno.ESTALE:
            eprint('stale file handle')
        else:
            eprint("unhandled error", e)
            exit(1)
        handle_read_fail(filename)

def main():
    global g_iter
    filename=sys.argv[1]
    do_update=int(sys.argv[2])

    g_iter = 0
    if do_update == 1:
        while True:
            update_it(filename)
            g_iter += 1
    else:
        while True:
            read_it(filename)
            g_iter += 1

if __name__ == '__main__':
    try:
        main()
    except (BrokenPipeError, KeyboardInterrupt):
        pass
    # avoid additional broken pipe error. s. https://stackoverflow.com/a/26738736
    sys.stderr.close()

作为旁注，首先，我在库调用flock中使用了建议锁--一个用于阅读的共享锁，一个用于写的排他锁。这样，我根本没有使用rename，一切都工作正常（代码也很简单）。但是，当有很多其他流量正在进行时，通过NFS进行锁定可能会很慢，所以我寻找一种没有锁的“安全”重命名实现。

我想我现在知道发生了什么。我在这里添加它，因为虽然其他人在到达那里时非常有帮助，但问题的实际根源是这样的：
阅读主机：

79542  10.643148 10.0.0.52 -> 10.0.0.24 NFS 222  ACCESS allowed   testfile  V3 ACCESS Call, FH: 0x76a9a83d, [Check: RD MD XT XE]
79543  10.643286 10.0.0.24 -> 10.0.0.52 NFS 194 0 ACCESS allowed 0600 Regular File testfile NFS3_OK V3 ACCESS Reply (Call In 79542), [Allowed: RD MD XT XE]
79544  10.643335 10.0.0.52 -> 10.0.0.24 NFS 222  ACCESS allowed     V3 ACCESS Call, FH: 0xe0e7db45, [Check: RD LU MD XT DL]
79545  10.643456 10.0.0.24 -> 10.0.0.52 NFS 194 0 ACCESS allowed 0755 Directory  NFS3_OK V3 ACCESS Reply (Call In 79544), [Allowed: RD LU MD XT DL]
79546  10.643487 10.0.0.52 -> 10.0.0.24 NFS 230  LOOKUP    testfile  V3 LOOKUP Call, DH: 0xe0e7db45/testfile
79547  10.643632 10.0.0.24 -> 10.0.0.52 NFS 190 0 LOOKUP  0755 Directory  NFS3ERR_NOENT V3 LOOKUP Reply (Call In 79546) Error: NFS3ERR_NOENT
79548  10.643662 10.0.0.52 -> 10.0.0.24 NFS 230  LOOKUP    testfile  V3 LOOKUP Call, DH: 0xe0e7db45/testfile
79549  10.643814 10.0.0.24 -> 10.0.0.52 NFS 190 0 LOOKUP  0755 Directory  NFS3ERR_NOENT V3 LOOKUP Reply (Call In 79548) Error: NFS3ERR_NOENT

写作主持人：

203306  13.805489  10.0.0.6 -> 10.0.0.24 NFS 246  LOOKUP    .nfs00000000d59701e500001030  V3 LOOKUP Call, DH: 0xe0e7db45/.nfs00000000d59701e500001030
203307  13.805687 10.0.0.24 -> 10.0.0.6  NFS 186 0 LOOKUP  0755 Directory  NFS3ERR_NOENT V3 LOOKUP Reply (Call In 203306) Error: NFS3ERR_NOENT
203308  13.805711  10.0.0.6 -> 10.0.0.24 NFS 306  RENAME    testfile,.nfs00000000d59701e500001030  V3 RENAME Call, From DH: 0xe0e7db45/testfile To DH: 0xe0e7db45/.nfs00000000d59701e500001030
203309  13.805982 10.0.0.24 -> 10.0.0.6  NFS 330 0,0 RENAME  0755,0755 Directory,Directory  NFS3_OK V3 RENAME Reply (Call In 203308)
203310  13.806008  10.0.0.6 -> 10.0.0.24 NFS 294  RENAME    testfile_temp,testfile  V3 RENAME Call, From DH: 0xe0e7db45/testfile_temp To DH: 0xe0e7db45/testfile
203311  13.806254 10.0.0.24 -> 10.0.0.6  NFS 330 0,0 RENAME  0755,0755 Directory,Directory  NFS3_OK V3 RENAME Reply (Call In 203310)
203312  13.806297  10.0.0.6 -> 10.0.0.24 NFS 246  CREATE    testfile_temp  V3 CREATE Call, DH: 0xe0e7db45/testfile_temp Mode: EXCLUSIVE
203313  13.806538 10.0.0.24 -> 10.0.0.6  NFS 354 0,0 CREATE  0755,0755 Regular File,Directory testfile_temp NFS3_OK V3 CREATE Reply (Call In 203312)
203314  13.806560  10.0.0.6 -> 10.0.0.24 NFS 246  SETATTR  0600  testfile_temp  V3 SETATTR Call, FH: 0x4b69a46a
203315  13.806767 10.0.0.24 -> 10.0.0.6  NFS 214 0 SETATTR  0600 Regular File testfile_temp NFS3_OK V3 SETATTR Reply (Call In 203314)

如果你打开同一个文件进行阅读，这是 * 唯一 * 可重复的-所以除了一个简单的C写-重命名循环：

#!/usr/bin/env perl

use strict;
use warnings;

while ( 1 ) {
  open ( my $input, '<', 'testfile' ) or warn $!;
  print ".";
  sleep 1;
}

这会导致我的测试用例很快失败（几分钟），而不是看起来根本没有失败。这取决于'.nfsXXX'文件，该文件是在打开文件句柄时创建的，然后被删除（或被RENAME覆盖）。
因为NFS是无状态的，它必须为客户端提供一些持久性，所以它仍然可以像在本地文件系统上执行打开/取消链接一样读取/写入该文件。要做到这一点-我们得到一个双RENAME和一个非常短的（亚毫秒）的间隔，我们的目标文件 * 不 * 存在的LOOKUP NFS RPC找到。