我有一个无盘主机“A”，它有一个目录NFS安装在服务器“B”上。 A上的进程向该目录中的两个文件F1和F2进行写入，并且B上的进程监视这些文件以进行更改。 假设B的调查速度比A预计的更快。 进程A寻找文件头，写入数据和刷新。 过程B寻找文件的头，并读取。
B有没有保证A的变化顺序会被检测到？
具体来说，如果A交替写入一个文件，然后另一个，是否有理由期望B会注意交替改变F1和F2？ 或者B可以想像到在F1上检测到一系列变化，然后在F2上进行一系列变化？
我知道这个问题里有很多假设。 例如，我几乎可以肯定，即使只在一个文件上运行，如果A对文件执行100次操作，B可能会看到更less数量的更改，从而得到相同的结果，这是由于NFScaching了A之前的一些操作它们被传送给B.当然，即使没有涉及NFS，也存在并发文件访问的问题，并且读取和写入过程都在相同的真实文件系统上运行。
我甚至在这里提出这个问题的原因是，似乎在大多数情况下，上面描述的设置确实按照它们在A处的相同顺序检测到B处的变化，但是偶尔有些事件经过转置订购。 那么，是否值得尝试做这个工作？ 有没有一些方法来调整NFS，使其工作，也许caching设置或东西？ 或者像这样的细粒度行为对NFS来说太期望了？
这个
假设B调查变化
和
具体来说，如果A交替写入一个文件，然后另一个，是否有理由期望B会注意交替改变F1和F2？ 或者B可以想像到在F1上检测到一系列变化，然后在F2上进行一系列变化？
意味着无论文件系统如何保证竞争条件。
那就是：你不能指望进程B检测到更改的顺序。
考虑如果发生什么事情
我不会依靠networking上一致的sorting。 NFS本身通常只保证一个客户端closures一个文件后，另一个客户端打开它应该看到这些更改。 （这并没有说明在服务器的文件系统上观察到的行为。）
你的NFS客户端，服务器和协议版本是什么？ 例如，Linux内核的NFS客户端在2.6.18版本的基础上改变（默认）属性caching行为，并且可以使用-o sync进行挂载，无需任何写入caching（数据或属性）。 与NFSv3相比，NFSv4还可以更好地控制caching行为。
您可能希望看到另一个问题的答案，该问题链接到Transactional NTFS的描述。 这真的很酷，可能会帮助你的情况。