более быстрый способ монтировать удаленную файловую систему, чем sshfs?


72

Я использовал sshfs для удаленной работы, но это очень медленно и раздражает, особенно когда я использую Eclipse на нем.

Есть ли более быстрый способ монтировать удаленную файловую систему локально? Мой приоритет №1 - скорость.

Удаленный компьютер - Fedora 15, локальный компьютер - Ubuntu 10.10. Я также могу использовать Windows XP локально, если это необходимо.

Ответы:


14

sshfs использует протокол передачи файлов SSH, что означает шифрование.

Если вы просто монтируете через NFS, это, конечно, быстрее, потому что не зашифровано.

Вы пытаетесь смонтировать тома в одной сети? затем используйте NFS .


35
Он не медленный из-за шифрования, он медленный, потому что это FUSE и продолжает проверять состояние файловой системы.
1913 года

3
@ w00t Не думаю, что это замедляет FUSE, а не шифрование. Изменение шифрования на arcfour ускорило его для меня, тогда как использование scpбыло таким же медленным, как и sshfs.
Sparhawk

21
@ Sparhawk есть разница между пропускной способностью и задержкой. FUSE дает вам довольно большую задержку, потому что она должна много проверять состояние файловой системы, используя довольно неэффективные средства. arcfour дает вам хорошую пропускную способность, потому что шифрование проще. В этом случае задержка наиболее важна, потому что именно из-за этого редактор работает медленно при просмотре и загрузке файлов.
w00t

3
@ w00t. Ах хорошо. Хорошие моменты.
Sparhawk

41

Если вам нужно улучшить скорость для соединений sshfs, попробуйте следующие варианты:

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

команда будет:

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions

1
Спасибо, сработало для меня! Пришлось удалить defer_permissionsхотя (неизвестный вариант).
Матье Родик

4
Не nolocalcaches снизит ли производительность, заставляя искать каждую операцию? Это противоречит auto_cache?
earthmeLon

2
nolocalcaches и defer_permissions не кажутся действительными (больше?) в Debian Jessie.
Кто-то

4
Почему no_readahead?
Studgeek

1
Что вы подразумеваете под "oauto_cache"?
ManuelSchneid3r

18

Помимо уже предложенных решений по использованию Samba / NFS, которые являются абсолютно допустимыми, вы также можете добиться некоторого повышения скорости sshfs, используя более быстрое шифрование (аутентификация будет такой же безопасной, как обычно, но сами передаваемые данные будет легче расшифровывать), предоставляя -o Ciphers=arcfourопцию к sshfs. Это особенно полезно, если ваша машина имеет слабый процессор.


-oCipher=arcfourне сделал различий в моих тестах с файлом 141 МБ, созданным из случайных данных.
Sparhawk

6
Это потому, что в команде было несколько опечаток. Я редактировал это. Я заметил 15% ускорение от моего сервера Raspberry Pi. (+1)
Sparhawk

4
Шифр chacha20-poly1305@openssh.com также стоит рассмотреть, так как теперь arcfour устарел. Chacha20 быстрее на процессорах ARM, чем AES, но гораздо хуже на процессорах x86 с инструкциями AES (которые в наши дни являются стандартными для всех современных настольных процессоров). klingt.net/blog/ssh-cipher-performance-comparision Вы можете перечислить поддерживаемые шифры с помощью «ssh -Q cipher»
TimSC

11

У меня нет никаких альтернатив, чтобы рекомендовать, но я могу дать предложения о том, как ускорить sshfs

sshfs -o cache_timeout=115200 -o attr_timeout=115200 ...

Это должно исключить некоторые запросы туда-обратно, когда вы пытаетесь прочитать содержимое или разрешения для файлов, которые вы уже получили ранее в своем сеансе.

sshfs имитирует удаление и изменения локально, поэтому новые изменения, сделанные на локальном компьютере, должны появиться немедленно, несмотря на большие таймауты, поскольку кэшированные данные автоматически удаляются.

Но эти параметры не рекомендуются, если удаленные файлы могут обновляться без ведома локальной машины, например, другим пользователем или удаленной оболочки ssh. В этом случае более низкие тайм-ауты были бы предпочтительнее.

Вот еще несколько вариантов, с которыми я экспериментировал, хотя я не уверен, что какой-то из них имел значение:

sshfs_opts="-o auto_cache -o cache_timeout=115200 -o attr_timeout=115200   \
-o entry_timeout=1200 -o max_readahead=90000 -o large_read -o big_writes   \
-o no_remote_lock"

Вам также следует проверить варианты, рекомендованные Митаем в его ответе.

Рекурсия

Самая большая проблема в моем рабочем процессе - это когда я пытаюсь прочитать много папок, например, в глубоком дереве, потому что sshfs выполняет запрос туда-обратно для каждой папки отдельно. Это также может быть узким местом, которое вы испытываете с Eclipse.

В этом может помочь параллельное выполнение запросов к нескольким папкам, но большинство приложений этого не делают: они были разработаны для файловых систем с малой задержкой и кэшированием с опережающим чтением, поэтому они ждут завершения одной статистики файла, прежде чем переходить к следующей. ,

Предварительное кэширование

Но что-то, что может сделать sshfs, это посмотреть в будущее на удаленную файловую систему, собрать статистику папок, прежде чем я их запрошу, и отправить их мне, когда соединение не будет сразу занято. Это будет использовать большую полосу пропускания (из прогнозных данных, которые никогда не используются), но может повысить скорость.

Мы можем заставить sshfs выполнить некоторое кэширование с опережением чтения, выполнив это до того, как вы начнете выполнять свою задачу, или даже в фоновом режиме, когда ваша задача уже выполняется:

find project/folder/on/mounted/fs > /dev/null &

Это должно предварительно кэшировать все записи каталога, уменьшая некоторые последующие издержки из-за циклических переходов. (Конечно, вам нужно использовать большие тайм-ауты, подобные тем, которые я предоставил ранее, или эти кэшированные данные будут удалены до того, как ваше приложение получит к ним доступ.)

Но это findзаймет много времени. Как и другие приложения, он ожидает результатов из одной папки, а затем запрашивает следующую.

Можно сократить общее время, попросив несколько процессов поиска просматривать разные папки. Я не проверял, действительно ли это более эффективно. Это зависит от того, разрешает ли sshfs запросы параллельно. (Я думаю, что это так.)

find project/folder/on/mounted/fs/A > /dev/null &
find project/folder/on/mounted/fs/B > /dev/null &
find project/folder/on/mounted/fs/C > /dev/null &

Если вы также хотите предварительно кэшировать содержимое файла, вы можете попробовать это:

tar c project/folder/on/mounted/fs > /dev/null &

Очевидно, что это займет гораздо больше времени, передаст много данных и потребует огромного размера кэша. Но когда это сделано, доступ к файлам должен быть приятным и быстрым.


4

SSHFS действительно медленный, потому что он передает содержимое файла, даже если это не требуется (при выполнении cp). Я сообщил об этом в апстрим и в Debian, но не получил ответа: /


2
Это эффективно с mv. К сожалению, когда вы работаете cpлокально, FUSE видит только запросы на открытие файлов для чтения и записи. Он не знает, что вы делаете копию файла. Для FUSE это выглядит ничем не отличается от обычной записи файла. Поэтому я боюсь, что это не может быть исправлено, если местный не cpстанет более FUSE-осведомленным / FUSE-дружественным. (Или FUSE может отправлять хэши блоков вместо целых блоков, когда подозревает a cp, как это делает rsync, но это будет сложно и может замедлить другие операции.)
joeytwiddle

3

После поиска и проб. Я просто нашел прибавку в -o Compression=noскорости. Задержка может быть вызвана процессом сжатия и распаковки. Кроме того, использование 'Ciphers = aes128-ctr' кажется более быстрым, чем другие, в то время как некоторые посты провели некоторые эксперименты на этом. Тогда моя команда как-то так:

sshfs -o allow_other, transform_symlinks, follow_symlinks, IdentityFile = / Users / maple / .ssh / id_rsa -o auto_cache, переподключиться, defer_permissions -o Ciphers = aes128-ctr -o Сжатие = нет maple@123.123.123.123: / home / maple ~ / mntpoint


2

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


1

Или NFS или Samba, если у вас большие файлы. Использование NFS с чем-то вроде 720p фильмов и дерьма действительно PITA. Samba будет работать лучше, хотя Samba мне не нравится по ряду других причин, и я обычно не рекомендую ее.

Для небольших файлов хорошо подойдет NFS.


1

Я обнаружил, что отключение моей темы zsh, которая проверяла статус файла git, помогло - просто вход в каталог занимал более 10 минут. Аналогично отключение контроллеров состояния git в Vim.


Вау, это действительно хороший совет!
Дмитрий

-2

Войдите в систему как root.

Получите доступ к каталогу верхнего уровня, используя «cd /».

Затем убедитесь, что у вас есть созданная папка монтирования или создайте ее с помощью «mkdir folder_name».

После этого просто используйте «mount xxxx: / remote_mount_directory / local_mount_directory».

если все сработало на вашем конце, до этого у вас должно быть успешное монтирование. Вы можете проверить и убедиться, что каталог назначения является общим, используя команду "exportfs", чтобы гарантировать, что они могут быть найдены.

Надеюсь это поможет. Это не из среды lvie, оно было протестировано в локальной сети с использованием VMware и Fedora 16.


5
Это не отвечает на вопрос ...
Лео Лам
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.