Существует ли высокопроизводительный локальный протокол обмена файлами?

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

Я сижу здесь и смотрю на iTunes, пытаясь отсканировать мультимедийную библиотеку по SMB, и она работает со скоростью около 2 МБ в секунду. Он подключен через проводную гигабитную сеть, и общий ресурс живет в массиве RAID, который может увеличить пропускную способность в 50 раз даже при поиске. Это смешно!

Некоторые протоколы обмена файлами из прошлого могут включать:

• Эндрю Файловая Система
• 9P / Styx протокол от Plan9 / Inferno
• RFS из старой системы V
• Протокол AppleShare
• Протокол Novell Netware

Мои требования достаточно просты:

• Современная безопасность - в идеале, использует открытые / закрытые ключи, такие как SSH. Туннелирование по TLS было бы здорово.
• Высокая производительность - сканирование файловой системы или чтение объемных данных должно выполняться со скоростью, поддерживаемой сервером и сетью.
• Нативные клиенты для Windows и Linux - другие были бы серьезными, но не интересными для меня.
• Блокировка файлов совместима с Linux и Windows.
• Изменение уведомлений совместимо с Linux и Windows.
• В идеале доступны высококачественные реализации с открытым исходным кодом, но я бы согласился с небольшой платой за лицензию. (И, нет, не "маленький" для всего предприятия - я обычный парень с семьей и ипотекой)

Я что-то пропустил?

Что не так с NFS 4?

Современная безопасность - в идеале, использует открытые / закрытые ключи, такие как SSH. Туннелирование по TLS было бы здорово.

NFS 4 предлагает современную аутентификацию. Безопасность данных должна осуществляться через VPN.

Высокая производительность - сканирование файловой системы или чтение объемных данных должно выполняться со скоростью, поддерживаемой сервером и сетью.

NFS 4 - разумная высокая производительность для общего случая. Много кеширования, агрегация команд и т. Д.

Нативные клиенты для Windows и Linux - другие были бы серьезными, но не интересными для меня.

Я ничего не знаю здесь. Любое разумное широко распространенное решение исходит из одного угла и поддерживается только как вторичный гражданин в другом мире. Тем не менее, я думаю, будет справедливо сказать, что, например, SMB лучше поддерживается в мире Unix (через Samba), чем, например, NFS в мире Windows.

Блокировка файлов совместима с Linux и Windows.

NFS дает вам это.

Изменение уведомлений совместимо с Linux и Windows.

Хороший вопрос. Я не думаю, что NFS хорошо это поддерживает. По крайней мере, я не знаю ни одной команды, которая, например, вызывала бы обратный вызов, если что-то изменилось на сервере (метаданных).

Чтобы ваши 2 МБ / с с SMB? Там должно быть что-то неправильно настроено. SMB, безусловно, способен на большее. 100 МБ / с (скорость соединения в ГБ) не должно быть проблемой при разумной конфигурации.

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

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