швидший спосіб монтажу віддаленої файлової системи, ніж sshfs?

Я використовую sshfs для віддаленої роботи, але це дуже повільно і дратує, особливо коли я використовую затемнення.

Чи існує швидший спосіб локальної установки віддаленої файлової системи? Мій пріоритет №1 - швидкість.

Віддаленою машиною є 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. Це особливо корисно, якщо ваш апарат має слабкий процесор.

У мене немає альтернатив, які можна рекомендувати, але я можу надати пропозиції, як пришвидшити 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, - це заглянути вперед до віддаленої файлової системи, зібрати статистику папок, перш ніж я їх запитую, і надіслати їх мені, коли з'єднання не одразу зайняте. Це використовувало б більшу пропускну здатність (з даних 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). Я повідомив про це вище та в Debian, але жодної відповіді: /

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

sshfs -o enable_other, transform_symlinks, follow_symlinks, IdentityFile = / Користувачі / maple / .ssh / id_rsa -o auto_cache, підключиться, defer_permissions -o Ciphers = aes128-ctr -o Compression = no maple@123.123.123.123: / home / maple / точка точки

NFS повинен бути швидшим. Наскільки віддаленою є файлова система? Якщо через WAN закінчено, вам може бути краще просто синхронізувати файли вперед і назад, на відміну від прямого віддаленого доступу.

Або у NFS, або у Samba, якщо у вас є великі файли. Використання NFS з чимось на кшталт 720p Movies і crap - це справді PITA. Samba зробить кращу роботу, тому що мені не подобається Samba з ряду інших причин, і я зазвичай не рекомендую це.

Для невеликих файлів NFS має бути добре.

Я виявив, що вимкнення моєї теми zsh, яка перевіряла стан файлів git, допомогла надзвичайно - просто введення в каталог займало 10+ хвилин. Так само вимкнення перевірок стану git у Vim.

Вхід як корінь.

Доступ до каталогу верхнього рівня за допомогою "cd /".

Потім переконайтеся, що у вас створена папка кріплення або створіть її за допомогою "mkdir folder_name".

Після цього просто використовуйте "mount xxxx: / remote_mount_directory / local_mount_directory.

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

Сподіваюся, це допомагає. Це не з львівського середовища, його протестували в локальній мережі за допомогою VMware та Fedora 16.