☰

通过 sshfs 修改文件

tag-icon • tag-icon ssh filesystems synchronization sshfs touch
通过 sshfs 修改文件

机器A的文件系统B通过sshfs.运行在 上的进程，由es 已挂载的文件系统上的一个文件B启动，以传递信号；然后信号（文件）被删除。这在第一次创建/销毁文件 ( / ) 时可靠地工作。Assh touchAAtouchrm

但是，如果第二个进程（再次在 上运行B，从A）尝试接触完全相同的文件，则会出现以下错误零星地抛出：

`touch: cannot touch '/path/to/file': No such file or directory`.

该路径是有效的，根据以下事实来判断：touch抛出错误后手动尝试该路径均会成功。如前所述，该错误是偶发的（使调试尝试变得复杂），但仅在已经经历了创建/删除循环后触摸文件时才会发生。

间歇性产生错误 ( touch、rm、touch) 的操作在时间上是分开的，因此并发访问不太可能是罪魁祸首（即，直到第一次触摸生成的文件被删除后，第二次触摸才会发生）。认为原因可能源于文件系统缓冲，在删除文件后sync调用A，但无济于事。sync在触摸文件之前立即调用B也没有帮助，尽管我不知道B的sync调用是否会影响( onA的版本缺少显式文件系统规范的选项；我尝试从运行于 的进程中调用via before ing，但在sync-over-ssh调用之后，该进程似乎没有错误地退出，因为包括该语句在内的其余行未执行，可能是因为不可能在由 启动的进程上从服务器返回到客户端；从客户端到服务器）。syncB-fsyncABssh user@A synctouchtouchsshssh

如何确定此文件系统相关错误的原因？

答案1

您可以通过使用 option 运行 sshfs 来调查可能发生的情况-o debug。它打印有关命令完成的基本文件系统操作的大量信息touch test。一个示例操作是：

unique: 209, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 10641
LOOKUP /test
getattr /test
   NODEID: 44
   unique: 209, success, outsize: 144

相关部分是getattr调用已完成，并且成功结束。当您成功触摸不存在的文件时，我们看到的操作是（删除详细信息）：

getattr /test
   unique: 190, error: -2 (No such file or directory), outsize: 16
create flags: 0x8841 /test 0100644 umask=0022
fgetattr[140469187119648] /test
flush[140469187119648]
utime /test 1507647885 1507647885
getattr /test
flush[140469187119648]
release[140469187119648] flags: 0x8801

我们看到该文件的 getattr 测试失败，这是正常的，因为它不存在，因此我们继续创建该文件。

如果现在在服务器上删除该文件，并且我们在客户端上再次进行触摸，我们会看到不同的序列：

getattr /test
   unique: 215, success, outsize: 144
open flags: 0x8801 /test
   unique: 216, error: -2 (No such file or directory), outsize: 16

现在 getattr 说该文件仍然存在，因此touch继续处理open()该文件，但这会导致错误消息：该文件根本不存在。

因此，这一切似乎都是客户端缓存存在的文件太慢而无法跟上远程更改的问题。最简单的答案是使用更短的调用getattr（即stat()系统调用）超时来安装遥控器。这应该适合你

sshfs -o cache_stat_timeout=0 ...

相关内容