Ho usato sshfs per lavorare in remoto, ma è davvero lento e fastidioso, in particolare quando uso eclissi su di esso.
Esiste un modo più veloce per montare il file system remoto localmente? La mia priorità n. 1 è la velocità.
La macchina remota è Fedora 15, la macchina locale è Ubuntu 10.10. Posso anche usare Windows XP localmente se necessario.
Risposte:
sshfs sta usando il protocollo di trasferimento file SSH, che significa crittografia.
Se monti semplicemente tramite NFS, è ovviamente più veloce, perché non crittografato.
stai provando a montare volumi sulla stessa rete? quindi utilizzare NFS .
scpstato altrettanto lento sshfs.
Se è necessario migliorare la velocità per le connessioni sshfs, provare queste opzioni:
oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead
il comando sarebbe:
sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
defer_permissionsperò (opzione sconosciuta).
nolocalcaches diminuirai le prestazioni forzando le ricerche in ogni operazione? Questo contraddice auto_cache?
no_readahead?
Oltre alle soluzioni già proposte di utilizzo di Samba / NFS, che sono perfettamente valide, potresti anche ottenere un aumento della velocità con la sshfscrittografia più rapida (l'autenticazione sarebbe sicura come al solito, ma i dati trasferiti sarebbero più facili da decrittografare) fornendo l' -o Ciphers=arcfouropzione a sshfs. È particolarmente utile se la tua macchina ha una CPU debole.
-oCipher=arcfournon ha fatto alcuna differenza nei miei test con un file di 141 MB creato da dati casuali.
Non ho alternative da raccomandare, ma posso fornire suggerimenti su come velocizzare sshfs:
sshfs -o cache_timeout=115200 -o attr_timeout=115200 ...
Ciò dovrebbe evitare alcune delle richieste di andata e ritorno quando si tenta di leggere il contenuto o le autorizzazioni per i file già recuperati in precedenza nella sessione.
sshfs simula le eliminazioni e le modifiche localmente, quindi le nuove modifiche apportate sul computer locale dovrebbero apparire immediatamente, nonostante i grandi timeout, poiché i dati memorizzati nella cache vengono automaticamente eliminati.
Ma queste opzioni non sono consigliate se i file remoti potrebbero essere aggiornati senza che il computer locale lo sappia, ad esempio da un altro utente o una shell ssh remota. In tal caso, sarebbe preferibile un timeout inferiore.
Ecco alcune altre opzioni con cui ho sperimentato, anche se non sono sicuro che qualcuno di loro abbia fatto la differenza:
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"
Dovresti anche dare un'occhiata alle opzioni raccomandate da Meetai nella sua risposta.
Il problema più grande nel mio flusso di lavoro è quando provo a leggere molte cartelle, ad esempio in un albero profondo, perché sshfs esegue una richiesta di andata e ritorno per ogni cartella separatamente. Questo potrebbe anche essere il collo di bottiglia che si verifica con Eclipse.
Fare richieste per più cartelle in parallelo potrebbe essere d'aiuto, ma la maggior parte delle app non lo fa: sono state progettate per filesystem a bassa latenza con memorizzazione nella cache read-ahead, quindi attendono il completamento di una statistica del file prima di passare alla successiva .
Ma qualcosa che sshfs potrebbe fare sarebbe guardare avanti al file system remoto, raccogliere le statistiche delle cartelle prima che io le richieda e inviarle a me quando la connessione non viene immediatamente occupata. Ciò richiederebbe una maggiore larghezza di banda (dai dati lookahead che non vengono mai utilizzati) ma potrebbe migliorare la velocità.
Possiamo forzare sshfs a fare un po 'di cache read-ahead, eseguendolo prima di iniziare l'attività, o anche in background quando l'attività è già in corso:
find project/folder/on/mounted/fs > /dev/null &
Ciò dovrebbe preconfigurare tutte le voci della directory, riducendo alcune delle spese generali successive da round trip. (Ovviamente, devi utilizzare i timeout di grandi dimensioni come quelli che ho fornito in precedenza, altrimenti questi dati memorizzati nella cache verranno cancellati prima che la tua app acceda ad essi.)
Ma findci vorrà molto tempo. Come altre app, attende i risultati da una cartella prima di richiedere quella successiva.
Potrebbe essere possibile ridurre il tempo complessivo chiedendo a più processi di ricerca di esaminare cartelle diverse. Non ho testato per vedere se questo è davvero più efficiente. Dipende se sshfs consente richieste in parallelo. (Penso di si.)
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 &
Se si desidera anche pre-memorizzare nella cache il contenuto del file, è possibile provare questo:
tar c project/folder/on/mounted/fs > /dev/null &
Ovviamente ciò richiederà molto più tempo, trasferirà molti dati e richiede di avere una dimensione della cache enorme. Ma una volta terminato, l'accesso ai file dovrebbe essere piacevole e veloce.
SSHFS è molto lento perché trasferisce il contenuto del file anche se non è necessario (quando si esegue cp). Ho segnalato questo a monte e a Debian, ma nessuna risposta: /
mv. Sfortunatamente quando si esegue cplocalmente, FUSE vede solo richieste di apertura di file per la lettura e la scrittura. Non sa che stai facendo una copia di un file. Per FUSIBILE non sembra diverso dalla scrittura di un file generale. Quindi temo che questo non possa essere risolto a meno che il locale non cpsia reso più sensibile ai FUSE / ai FUSE. (O FUSE potrebbe essere in grado di inviare hash di blocco anziché interi blocchi quando sospetta un cp, come fa rsync, ma sarebbe complesso e potrebbe rallentare altre operazioni.)
Dopo la ricerca e il processo. Ho appena scoperto di aggiungere -o Compression=novelocità molto. Il ritardo può essere causato dal processo di compressione e decompressione. Inoltre, usare 'Ciphers = aes128-ctr' sembra più veloce di altri mentre alcuni post hanno fatto alcuni esperimenti su questo. Quindi, il mio comando è in qualche modo così:
sshfs -o allow_other, transform_symlink, follow_symlink, IdentityFile = / Users / maple / .ssh / id_rsa -o auto_cache, riconnetti, defer_permissions -o Ciphers = aes128-ctr -o Compression = no maple@123.123.123.123: / home / maple ~ / mntpoint
NFS dovrebbe essere più veloce. Quanto è remoto il filesystem? Se è sulla WAN, potresti stare meglio sincronizzando i file avanti e indietro, invece dell'accesso remoto diretto.
NFS o Samba se hai file di grandi dimensioni. Usare NFS con qualcosa di simile a film a 720p e merda è davvero un PITA. Samba farà un lavoro migliore, anche se non mi piace Samba per una serie di altri motivi e di solito non lo consiglierei.
Per file di piccole dimensioni, NFS dovrebbe andare bene.
Ho scoperto che disattivare il mio tema zsh che stava controllando lo stato del file git mi ha aiutato in modo enigmatico - entrare nella directory impiegava più di 10 minuti. Allo stesso modo, disattivando i controlli di stato git in Vim.
Accedi come root.
Accedi alla tua directory di livello superiore, usando "cd /".
Quindi assicurati di avere una cartella mount creata o crearne una usando "mkdir nome_cartella".
Successivamente, usa semplicemente "mount xxxx: / remote_mount_directory / local_mount_directory.
se tutto ha funzionato alla tua fine, prima di questo dovresti avere una cavalcatura di successo. Potresti voler controllare e assicurarti che la directory di destinazione sia condivisa usando il comando "exportfs" per garantire che possano essere trovati.
Spero che sia di aiuto. Questo non proviene da un ambiente Lvie, è stato testato su una LAN usando VMware e Fedora 16.