如果我mount --bind /a在/b并且如果我mv /a/bigfile /b/将花费很多时间（如果源文件很大）。这实际上会复制文件，然后删除源文件，而不是简单地更新文件系统的文件表。
我了解如何以及为何mount --bind有效。正如其他人指出的那样，对此有一些很好的解释：
有没有什么方法可以告诉 mount amount --bind在同一个文件系统中，以便通过实际更新文件系统的文件表来完成这样的操作（移动）？
我问的是如何解决这个问题，而不是如何理解它：也许我不知道的内核补丁已经可用，或者我还没有找到丢失的参数（等等）。
原因：在我当前的设置中，有一个服务（nextcloud）仅支持mount --bind.我无法使用符号链接。例如，如果我需要在 nextcloud 的每个帐户内都有一个共享文件夹，则必须使用绑定。我可以接受任何适用于 nextcloud 的解决方案，如果它是在文件系统/内核级别制定的。这是因为当前设置还包括以其他方式访问这些文件，例如 ssh。换句话说，我希望能够使用任何命令或应用程序来移动文件，例如示例。
答案1
显然不是，手册页rename(2)提到了这一点：
EXDEV旧路径和新路径不在同一个安装的文件系统上。 （Linux 允许在多个点挂载一个文件系统，但rename()不能跨不同的挂载点工作，即使在两个挂载点上挂载相同的文件系统也是如此。
如果我没记错的话，绑定安装与多次安装相同的文件系统相同，即事后绑定没有“源”和“目标”。
还有另一个回答几个月前关于同一主题的另一个问题。该链接指向与内核开发人员进行的讨论。所以去投票吧。
答案2
我在 docker 容器中的 nextcloud 和 samba 也遇到同样的问题。我通过将所有数据移动到 nextcloud 中并让其他人从该卷绑定安装它们来解决这个问题。
因此，从任何服务的角度来看，mv 始终只位于一个绑定挂载内。
不确定这是否对你有帮助
答案3
使用rsync代替mv应该可以解决问题。尝试使用以下命令
rsync -avP /a/bigfile /b/bigfile
问题是因为 的视点mount --bind位于内核中，并且对诸如 之类的更高级别程序是隐藏的mv。与 不同的是mv，rsync仅移动文件的已修改部分。
这解释了关于mount --bind 什么是绑定安装？