linux - 即使在 "close"操作成功后,NFS 软挂载是否会导致静默损坏

标签 linux nfs

我读过的几乎所有内容都说 NFS 软挂载会导致静默损坏。我认为这是因为以下情况:

  • 用户应用程序写入 NFS
  • NFS 客户端接受写入请求并返回成功给用户应用
  • NFS 客户端有数据队列/缓冲等待写入 NFS 服务器
  • 某些问题阻止写入队列/缓冲数据(例如 NFS 服务器出现故障)

我的问题是,使用 NFS 软挂载的这种情况会发生什么情况:

  • 与上述步骤相同,但另外...
  • 用户应用程序继续在同一个文件句柄上写入更多数据
  • 用户应用关闭文件

使用软挂载,NFS 会为刚刚关闭的文件刷新它的缓存吗?而且,如果无法做到这一点(因为 NFS 软挂载因错误而放弃),用户应用程序不应该在关闭命令时返回错误吗?

即,我想知道成功关闭软挂载 NFS 文件是否能保证没有静默损坏。

稍后编辑: 看着http://www.avidandrew.com/understanding-nfs-caching.html ,它说,

In NFSv3, the close() will cause the client to flush all data to stable storage. The client will also flush data to stable storage on a chmod, since that could potentially affect its ability to write back the data. It will not bother to do so for rename. An application should normally be able to rely on the data being safely on disk in both these situations provided that the server honours the NFS protocol (with a caveat that an ill-timed 'kill -9' could interrupt the process of flushing).

但随后它还表示,如果 NFS 卷是使用异步选项挂载的(据我所知,这是默认设置),那么 NFS“提交”将被忽略,所以这可能仅适用于显式挂载 NFS 卷的情况使用同步选项?但是 NFS 手册页说 sync 选项不进行缓存,这与此相矛盾。好吧。

最佳答案

Linux NFS FAQ指出

A8. What is close-to-open cache consistency?

[...]

When the application closes the file, the NFS client writes back any pending changes to the file so that the next opener can view the changes. This also gives the NFS client an opportunity to report any server write errors to the application via the return code from close(). This behavior is referred to as close-to-open cache consistency.

关于linux - 即使在 "close"操作成功后,NFS 软挂载是否会导致静默损坏,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32173372/

相关文章:

linux - 了解 Chromium 源代码结构

linux - ll、ls 和 block 大小 M 或 G 之间哪个文件大小最准确?

更改 glibc 但没有任何反应

linux - 下载某种类型的所有文件,不带目录

PHP 无法从 NFS 共享中读取 session

使用 Ansible 的 Docker NFS 卷

linux - 如何判断两个 NFS 挂载是否在同一个远程文件系统上?

amazon-ec2 - Amazon Elastic File System Policy (EFS) - 允许通过 IAM 角色访问 EC2 实例不起作用

c# - 在 mono/Linux 下从命名管道读/写

ubuntu - Ubuntu 主机的 Vagrant nfs 同步文件夹问题