sshfs보다 원격 파일 시스템을 마운트하는 더 빠른 방법?

sshfs를 사용하여 원격으로 작업했지만 특히 일식을 사용할 때 실제로 느리고 성가시다.

원격 파일 시스템을 로컬로 마운트하는 더 빠른 방법이 있습니까? 나의 최우선 과제는 속도입니다.

원격 시스템은 Fedora 15이고 로컬 시스템은 Ubuntu 10.10입니다. 필요한 경우 Windows XP를 로컬로 사용할 수도 있습니다.

sshfs는 SSH 파일 전송 프로토콜을 사용하고 있으며 이는 암호화를 의미합니다.

NFS를 통해 마운트하는 경우 암호화되지 않았기 때문에 속도가 더 빠릅니다.

같은 네트워크 에 볼륨을 마운트하려고 합니까? 그런 다음 NFS를 사용하십시오 .

sshfs 연결 속도를 향상시켜야하는 경우 다음 옵션을 시도하십시오.

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

명령은 다음과 같습니다.

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

완벽하게 유효한 Samba / NFS를 사용하는 이미 제안 된 솔루션 외에도 옵션 sshfs을 제공하여보다 빠른 암호화 (인증은 평소와 같이 안전하지만 전송 된 데이터 자체는 해독하기 쉬움)를 사용하여 속도 향상을 달성 할 수도 -o Ciphers=arcfour있습니다. 에 sshfs. 컴퓨터에 CPU가 약한 경우 특히 유용합니다.

권장 할 대안이 없지만 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"

또한 Meetai 가 그의 답변에서 권장하는 옵션을 확인해야합니다 .

재귀

sshfs는 각 폴더에 대해 개별적으로 왕복 요청을 수행하기 때문에 워크 플로에서 가장 큰 문제는 딥 트리와 같이 많은 폴더를 읽으려고 할 때입니다. 이것은 Eclipse에서 경험하는 병목 현상 일 수도 있습니다.

여러 폴더를 병렬로 요청하면 도움이 될 수 있지만 대부분의 앱은 그렇지 않습니다. 미리 읽기 캐싱 기능을 사용하여 대기 시간이 짧은 파일 시스템을 위해 설계되었으므로 한 파일 통계가 완료 될 때까지 기다렸다가 다음 파일로 넘어갑니다. .

프리 캐싱

그러나 sshfs가 할 수있는 일은 원격 파일 시스템을 미리보고 요청하기 전에 폴더 통계를 수집하여 연결이 즉시 차지되지 않을 때 나에게 보내는 것입니다. 이것은 사용되지 않는 lookahead 데이터에서 더 많은 대역폭을 사용하지만 속도를 향상시킬 수 있습니다.

작업을 시작하기 전에 또는 작업이 이미 진행중인 백그라운드에서이를 실행하여 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 &

분명히 이것은 훨씬 오래 걸리고, 많은 양의 데이터를 전송하며, 큰 캐시 크기가 필요합니다. 그러나 완료되면 파일에 액세스하는 것이 좋고 빠릅니다.

SSHFS는 (cp를 수행 할 때) 필요하지 않더라도 파일 내용을 전송하기 때문에 실제로 느립니다. 나는 이것을 업스트림과 데비안에보고했지만 아무런 반응이 없다 : /

검색 및 시험 후. 방금 추가 -o Compression=no속도를 많이 발견 했습니다. 압축 및 압축 해제 프로세스로 인해 지연이 발생할 수 있습니다. 또한 'Ciphers = aes128-ctr'을 사용하는 것이 다른 것보다 빠르지 만 일부 게시물 은 이에 대한 실험을 수행했습니다. 그런 다음 내 명령은 어떻게 든 다음과 같습니다.

sshfs -o allow_other, transform_symlinks, follow_symlinks, IdentityFile = / Users / maple / .ssh / id_rsa -o auto_cache, reconnect, defer_permissions -o Ciphers = aes128-ctr -o 압축 = no maple@123.123.123.123 : / home / maple ~ / mntpoint

NFS가 더 빨라야합니다. 파일 시스템이 얼마나 원격입니까? WAN을 사용하는 경우 직접 원격 액세스가 아닌 파일을 앞뒤로 동기화하는 것이 좋습니다.

큰 파일이있는 경우 NFS 또는 Samba입니다. 720p Movies 및 crap과 같은 NFS를 사용하는 것은 실제로 PITA입니다. 삼바는 다른 여러 가지 이유로 삼바를 싫어하므로 일반적으로 권장하지 않습니다.

작은 파일의 경우 NFS가 양호해야합니다.

git 파일 상태를 확인하는 zsh 테마를 끄는 것이 큰 도움이되었습니다. 디렉토리를 입력하는 데 10 분 이상이 걸렸습니다. 마찬가지로 Vim에서 git status checker를 끄십시오.

루트로 로그인하십시오.

"cd /"를 사용하여 최상위 디렉토리에 액세스하십시오.

그런 다음 "mkdir folder_name"을 사용하여 마운트 폴더를 작성하거나 작성하십시오.

그런 다음 "mount xxxx : / remote_mount_directory / local_mount_directory"를 사용하십시오.

모든 것이 끝났다면 성공적으로 마운트해야합니다. "exportfs"명령을 사용하여 대상 디렉토리를 찾을 수 있는지 확인하여 대상 디렉토리를 공유하고 있는지 확인할 수 있습니다.

도움이 되었기를 바랍니다. 이것은 lvie 환경이 아니며 VMware 및 Fedora 16을 사용하여 LAN에서 테스트되었습니다.