SSHFS/SFTP :Vim зависает при попытке редактирования файла по sshfs и не может загрузить файл с размером MTU по sftp

Вы можете просто добавить еще один блок -execс командой echoдля записи в лог-файл, т.е.

find $1* -prune -name "*.$2" -mtime +$3 -exec mv {} $4 \; -exec echo mv {} $4 >> /path/to/log \;

Если вам нужно меньше информации, просто измените последний блок -exec, например.-exec echo {} >> /path/to/log \;

Регистрация ошибок

Если вы также хотите зарегистрировать, была ли команда успешной или нет, вы также можете передать стандартную ошибку из команды mvв файл журнала. Я не думаю, что гарантировано, что первый -execобязательно действует первым, поэтому в этом случае я бы использовал один -exec. Н.Б. здесь синтаксис становится немного сложнее.

find $1* -prune -name "*.$2" -mtime +$3 -exec mv {} $4 \; -exec sh -c 'echo mv $1 $2 >> /path/to/log; mv $1 $2 2>> /path/to/log'. {} $4 \;

Некоторые комментарии

Я не уверен в вашем точном варианте использования, но рекомендуется заключать ваши переменные в кавычки, например. find "$1"* …, если есть имена файлов с пробелами/и т.д. в них.

Во-вторых, -execdirпредпочтительнее -exec. Изman find:

There are unavoidable security problems surrounding use of the -exec action; you should use the -execdir option instead.

mv -v вместо

В качестве альтернативы, согласно комментарию steeldriver , если ваша версия mvподдерживает подробный параметр -v, вместо этого вы можете изменить исходный блок -execна

-exec mv -v {} $4 >> /path/to/log \;

, который будет выдавать результат, аналогичный renamed 'foo' -> 'bar'.

6
15.10.2019, 20:14
2 ответа

Итак, снижение размера MTU решило все мои проблемы с вводом-выводом через SSHFS. Как указал @roaima, проблемы, вероятно, были вызваны тем, что брандмауэр университетского сервера слишком активно блокировал пакеты ICMP.

Спасибо @roaima за помощь в решении этой проблемы. И спасибо @derobert за предложение снизить MTU.

0
27.01.2020, 20:30

Файловая система sshfsFUSE реализована путем представления файловой системы поверх 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 падает при попытке скомпилировать файлы на удаленной файловой системе ». Не должно, конечно, но тогда подумайте о том, что на самом деле происходит на заднем плане...

1
27.01.2020, 20:30

Теги

Похожие вопросы