私たちの大学では、学生の大学アカウントへのSSHアクセスを提供しています。私はリモートアカウントのいくつかのフォルダにアクセスするためにSSHFを設定しました。
私のローカルコンピュータでpop_osを実行し、次のオプションを指定してsystemdを使用して自動マウントしています。noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,workaround=rename,IdentityFile=/home/me/.ssh/identityfile,allow_other,default_permissions,uid=1000,gid=1000,ServerAliveInterval=15
質問
自動マウントが正常に機能し、リモートフォルダを参照できますが、ファイルを置き換えてフォルダをリモートで再帰的にコピーすることにはいくつかの問題があります。
ただし、vimを使用してリモートファイルシステムのファイルを編集しようとするたびに、エディタはファイルを開く前に60秒間停止します（非常に正確です。接続タイムアウトパラメータに関連しているようです）。ファイルが最終的に開かれるとエラーが発生し、E297: Write error in swap filevimでファイルを閉じます。E72: Close error on swap file
ただし、場合によっては（特に/ etc / fstabでオプションを更新した後にデーモンを再ロードして自動マウントサービスを再起動した後）、ファイルはエラーなしですぐに開きます。
私が試したこと
sshfsでファイルを開くときにstraceを実行しましたが、これは問題が発生したように見えるログの例です。
0.000032 openat(AT_FDCWD, ".../myremotefile.c", O_RDONLY) = 3
0.041890 readlink(".../myremotefile.c", 0x7ffd99b19540, 4095) = -1 EINVAL (Invalid argument)
0.000302 openat(AT_FDCWD, ".../.myremotefile.c.swp", O_RDONLY) = -1 ENOENT (No such file or directory)
0.029883 openat(AT_FDCWD, ".../.myremotefile.c.swp", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
0.103207 openat(AT_FDCWD, ".../.myremotefile.c.swx", O_RDONLY) = -1 ENOENT (No such file or directory)
0.074409 openat(AT_FDCWD, ".../.myremotefile.c.swx", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
0.116541 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
0.000419 fstat(5, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
0.000318 close(5) = 0
0.000268 unlink(".../.myremotefile.c.swx") = 0
0.075053 close(4) = 0
0.000448 unlink(".../.myremotefile.c.swp") = 0
0.061916 stat(".../.myremotefile.c.swp", 0x7ffd99b1a4d0) = -1 ENOENT (No such file or directory)
0.077126 lstat(".../.myremotefile.c.swp", 0x7ffd99b1a660) = -1 ENOENT (No such file or directory)
0.041249 openat(AT_FDCWD, ".", O_RDONLY) = 4
0.000218 fchdir(4) = 0
0.000197 chdir(".../myremotefolder") = 0
0.000086 getcwd("/home/myhomefolder/.../myremotefolder", 4096) = 34
0.000029 fchdir(4) = 0
0.000025 close(4) = 0
0.000027 lstat(".../.myremotefile.c.swp", 0x7ffd99b1a9e0) = -1 ENOENT (No such file or directory)
0.043704 openat(AT_FDCWD, ".../.myremotefile.c.swp", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 4
0.127965 fcntl(4, F_GETFD) = 0
0.000331 fcntl(4, F_SETFD, FD_CLOEXEC) = 0
0.000347 openat(AT_FDCWD, ".", O_RDONLY) = 5
0.000221 fchdir(5) = 0
0.000145 chdir(".../myremotefolder") = 0
0.046751 getcwd("/home/myhomefolder/.../myremotefolder", 4096) = 34
0.000375 fchdir(5) = 0
0.000351 close(5) = 0
0.000262 lseek(4, 0, SEEK_SET) = 0
0.000082 write(4, "b0VIM 8.1\0\0\0\0\20\0\0\217\266\235]>\0\0\0\335\16\0\0balo"..., 4096) = 4096
0.000645 select(1, [0], [], [0], {tv_sec=0, tv_usec=0}) = 0 (Timeout)
0.000176 chmod("..../.myremotefile.c.swp", 0644) = -1 EIO (Input/output error)
60.064610 close(3) = -1 ENOTCONN (Transport endpoint is not connected)
プロセスが終了して60秒間停止することがわかります。
この問題は、vimが.swpファイルを生成しようとしたときに発生するようです。
私はこの問題を自分で解決するのにsshfsとfusionについて十分に知りません。
また、gccとmvのstraceログを提供することもできます。正確さが必要かどうか尋ねてください。
ご回答ありがとうございます。
編集する：vimrcでオプションを設定して、directoryvimがローカルの.vimフォルダにスワップファイルを生成するようにしました。これによって発生したスワップファイルのエラーが修正されました。
しかし、他のタスクを実行するとまだI / Oエラーが発生するため、vimで発生する問題は私が調査するより複雑な問題の症状にすぎないと思います。
@roaimaが言ったように、vimがリモートファイルシステムからスワップファイルを作成しようとしたときに発生する接続が予期せず閉じられて問題が発生したようです。
最近何があっても特定のファイルをコピーできないことがわかりました。今はわかりませんが、ファイルが特定のサイズより大きくなる可能性があるため、いくつかのテストを実行する必要があります。
編集2：今日いくつかのテストを行ったところ、MTUサイズ（1500）を超えるsshを介してファイルをアップロードしようとしたとき（sshfs、scp、およびsftpセッションを介してファイルをアップロードしようとしました）、ServerAliveIntervalsshオプションを設定したときに接続に60秒かかりました後に切断されました。
答え1
FUSEファイルシステムは、ファイル転送プロトコルの上にファイルシステムを提供することによってsshfs実装されます。sftpしたがって、すべてのファイルアクセス（編集）を実行するには、サブシステムが最初にファイルをローカルファイルシステムのキャッシュにコピーする必要がありますvi[m]。sshfsファイルが特に大きい場合、またはクライアントとサーバー間のネットワークが特に遅い場合は、ファイルにローカルにアクセスする前に転送するのにかなりの時間がかかることがあります。
それは（非常に）おおよそ次のとおりです（代わりに使用することを除いsftpてscp）
# Copy the remote file to a temporary local cache
scp -p remote:/path/to/file /tmp/file.tmp
checksum=$(cksum /tmp/file.tmp)
# Action on remote file is implemented by performing the action locally
vi /tmp/file.tmp
# Simplified; we would also need to handle local rm/mv -> remote rm/mv, etc.
[[ "$(cksum /tmp/file.tmp)" != "$checksum" ]] && scp -p /tmp/file.tmp remote:/path/to/file
gccしたがって、ローカルで実行するのがリモートサーバーにログインして実行するよりもはるかに遅いことがわかります。正直、あまり驚くべきことではない」リモートファイルシステムでファイルをコンパイルしようとすると、gccがクラッシュします。「…もちろんそうではないけれど、その背景で実際に何が起こっているのか考えてみてください。
答え2
MTUサイズを下げると、SSHFSで経験したすべてのI / O問題が解決したようです。 @roaimaが指摘したように、大学のサーバーのファイアウォールはICMPパケットを厳しくブロックしすぎて問題を引き起こす可能性があります。
この問題を案内してくれた@roaimaに感謝します。 MTUを下げるよう提案した@derobertに感謝します。