NFS挂载不断改变inode
NFS mount keep changing inode
我正在使用 MacBook Pro 和 Catalina 进行我的所有开发。我还通过 virtualbox 运行 一个带有 ubuntu 16.04 的 VM，我在其中导出了一个 NFS 共享。
导出看起来像这样：
/export/dev 192.168.0.0/16(rw,insecure,no_subtree_check,async,all_squash,anonuid=1000,anongid=1000)
我用
把它安装在我的Mac上
mount -o rw,nolocks,locallocks -t nfs 192.168.56.102:/export/dev /Users/myhome/Documents/dev
nfsstat -m 是说
NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=32768,wsize=32768,readahead=16,dsize=4096,rdirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,nomutejukebox,nonfc,sec=sys
大多数时候一切正常，但我越来越频繁地遇到奇怪的错误，并且 sublime text 中的文件夹开始看起来像带有“link”的文件夹。在控制台中调查，我收到错误消息，说 inode 已经被看到并且该文件夹在 sublime 中被认为是一个符号 link。
我对此进行了进一步调查，认为这不是一个重大错误，但更可能是 MacOS 问题。
当一切正常时，我将 ls -i in Mac OS 写在我安装的文件夹之一中，我得到与 VM 上完全相同的 inode 结果。但是 5 分钟后，我做了完全相同的事情 - 我在同一文件夹中的所有文件上得到了完全不同的 inode 和完全相同的 inode 编号。
有没有人遇到过这种情况？这是 NFS 参数问题吗？
我用谷歌搜索了这个，但没有在互联网上找到任何有类似问题的人。
你是对的。我在 Catalina 10.15.7 上看到了确切的问题。我现在的解决方法是指定 actimeo=0。默认情况下 actimeo=60，files/dirs 属性每 60 秒定期刷新一次。索引节点编号最初在安装后立即正确，但每次刷新都会更改同一目录中的文件，使其具有相同且看似随机的索引节点编号。这太糟糕了，因为它打破了很多程序的基本假设，包括 dyld，它使用 inode 编号来识别内部加载的图像。 （函数 bool ImageLoader::statMatch(const struct stat& stat_buf) const 来自 https://opensource.apple.com/source/dyld/dyld-750.6/src/ImageLoader.cpp.auto.html）。我正在尝试向 Apple 提交错误报告，看看如何推进。
更新一：引用苹果的回答：
After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue:
To work around the issue, mounting with nordirplus should fix this.
Also, the issue is resolved in macOS Big Sur (11+) so, you could try that as well.
我正在使用 MacBook Pro 和 Catalina 进行我的所有开发。我还通过 virtualbox 运行 一个带有 ubuntu 16.04 的 VM，我在其中导出了一个 NFS 共享。 导出看起来像这样：
/export/dev 192.168.0.0/16(rw,insecure,no_subtree_check,async,all_squash,anonuid=1000,anongid=1000)
我用
把它安装在我的Mac上mount -o rw,nolocks,locallocks -t nfs 192.168.56.102:/export/dev /Users/myhome/Documents/dev
nfsstat -m 是说
NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=32768,wsize=32768,readahead=16,dsize=4096,rdirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,nomutejukebox,nonfc,sec=sys
大多数时候一切正常，但我越来越频繁地遇到奇怪的错误，并且 sublime text 中的文件夹开始看起来像带有“link”的文件夹。在控制台中调查，我收到错误消息，说 inode 已经被看到并且该文件夹在 sublime 中被认为是一个符号 link。
我对此进行了进一步调查，认为这不是一个重大错误，但更可能是 MacOS 问题。
当一切正常时，我将 ls -i in Mac OS 写在我安装的文件夹之一中，我得到与 VM 上完全相同的 inode 结果。但是 5 分钟后，我做了完全相同的事情 - 我在同一文件夹中的所有文件上得到了完全不同的 inode 和完全相同的 inode 编号。
有没有人遇到过这种情况？这是 NFS 参数问题吗？ 我用谷歌搜索了这个，但没有在互联网上找到任何有类似问题的人。
你是对的。我在 Catalina 10.15.7 上看到了确切的问题。我现在的解决方法是指定 actimeo=0。默认情况下 actimeo=60，files/dirs 属性每 60 秒定期刷新一次。索引节点编号最初在安装后立即正确，但每次刷新都会更改同一目录中的文件，使其具有相同且看似随机的索引节点编号。这太糟糕了，因为它打破了很多程序的基本假设，包括 dyld，它使用 inode 编号来识别内部加载的图像。 （函数 bool ImageLoader::statMatch(const struct stat& stat_buf) const 来自 https://opensource.apple.com/source/dyld/dyld-750.6/src/ImageLoader.cpp.auto.html）。我正在尝试向 Apple 提交错误报告，看看如何推进。
更新一：引用苹果的回答：
After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue: To work around the issue, mounting with
nordirplusshould fix this. Also, the issue is resolved in macOS Big Sur (11+) so, you could try that as well.