У меня возникли проблемы с NFS, и я хотел бы попробовать использовать просто старый TCP.

Я понятия не имею, с чего начать.

Аппаратно, я использую кроссовер Ethernet-кабель для подключения двух нетбуков.

Чтобы объединить их в сеть, я набираю

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

на первом нетбуке и

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

на второй

где /mnt/network1указано в / etc / fstab как

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

а также в /etc/exports(используя синтаксис этого файла), на первом нетбуке.

Выше работает отлично, но файлы и каталоги огромны. Файлы в среднем занимают около половины гигабайта за штуку, а каталоги имеют размер от 15 до 50 гигабайт.

Я использую rsyncдля их передачи, и команда (вкл 192.168.1.2)

$ rsync -avxS /mnt/network1 ~/somedir

Я не уверен, есть ли способ изменить мои настройки NFS, чтобы лучше обрабатывать огромные файлы, но я хотел бы увидеть, работает ли rsyncдемон на более старых TCP лучше, чем rsyncна NFS.

Итак, еще раз, как я могу настроить аналогичную сеть с TCP?

ОБНОВИТЬ:

Итак, после нескольких часов попыток вытащить себя из болота собственного невежества (или, как мне нравится думать, подтянуть себя своими собственными бутстрапами), я пришел к некоторым полезным фактам.

Но, прежде всего, то, что привело меня на этот путь кролика вместо того, чтобы просто принять текущий лучший ответ, заключалось в следующем: ncэто невероятно крутая программа, которая решительно не работает для меня. Я попробовал netcat-openbsdи netcat-traditionalпакеты без удачи вообще.

Ошибка, которую я получаю на принимающей машине ( 192.168.1.2):

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route дает:

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

Но вот хорошая новость: установив статические IP-адреса /etc/network/interfaces, которые я начал делать, пытаясь заставить ncработать, исправил все мои проблемы с NFS и возродил мою любовь к NFS.

Точная конфигурация, которую я использовал ( 192.168.1.1конечно, для первого нетбука):

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

С этими настройками два нетбука смогут пинговать друг друга сразу после загрузки, даже без ifup.

Во всяком случае, я все еще очень хотел бы увидеть ncв действии, поэтому я надеюсь, что кто-нибудь поможет мне отладить этот процесс.

Быстрый способ

Самый быстрый способ передачи файлов по локальной сети, скорее всего, не rsync, если только не было изменений. rsync тратит немало времени на выполнение контрольных сумм, вычисление различий и т. д. Если вы знаете, что в любом случае собираетесь передавать большую часть данных, просто сделайте что-то вроде этого (примечание: существует несколько реализаций netcat; обратитесь к руководству для правильные варианты. В частности, ваш может не захотеть -p)

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

Это использует netcat ( nc) для отправки tar через необработанное TCP-соединение через порт 1234. Шифрование, проверка подлинности не выполняется, и т. Д., Поэтому это очень быстро. Если ваша кросс-коммутация работает на гигабитах или меньше, вы подключитесь к сети; если его больше, вы будете привязывать диск (если у вас нет массива хранения или быстрого диска). В vфлаги дегтя сделать его напечатать имена файлов , как она идет (многословный режим). С большими файлами это практически не накладные расходы. Если бы вы делали тонны маленьких файлов, вы бы это отключили. Кроме того, вы можете вставить что-то вроде pvв конвейер, чтобы получить индикатор прогресса:

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

Конечно, вы можете вставить и другие вещи, например gzip -1(и добавить zфлаг на принимающей стороне - zфлаг на отправляющей стороне будет использовать более высокий уровень сжатия, чем 1, если, конечно, вы не установите переменную среды GZIP). Хотя, вероятно, gzip будет работать медленнее, если только ваши данные не сжимаются.

Если вам действительно нужен rsync

Если вы действительно передаете только небольшую часть измененных данных, rsync может быть быстрее. Вы также можете захотеть взглянуть на параметр -W/ --whole-file, как в случае очень быстрой сети (например, перекрестного соединения), которая может быть быстрее.

Самый простой способ запустить rsync - использовать ssh. Возможно, вы захотите поэкспериментировать с ssh-шифрами, чтобы увидеть, какие из них самые быстрые, это будут AES, ChaCha20 или Blowfish (хотя существуют некоторые проблемы безопасности с размером 64-битных блоков Blowfish), в зависимости от того, имеет ли ваш чип AES от Intel -NI инструкции (и ваш OpenSSL использует их). На новом достаточно ssh, rsync-over-ssh выглядит так:

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

Для старых ssh / sshd попробуйте aes128-ctrили aes128-cbcвместо aes128-gcm@openssh.com.

ChaCha20 будет chacha20-poly1305@openssh.com(также требуется достаточно новый ssh ​​/ sshd), а Blowfish будет blowfish-cbc. OpenSSH не позволяет работать без шифра. Вы, конечно, можете использовать любые параметры rsync, которые вам нравятся -avP. И, конечно, вы можете пойти в другом направлении и запустить rsync с конечного компьютера (pull) вместо исходного компьютера (push).

Сделать rsync быстрее

Если вы запустили демон rsync, вы можете избавиться от служебных данных криптографии. Во-первых, вы должны создать файл конфигурации демона ( /etc/rsyncd.conf), например, на исходном компьютере (подробнее см. Справочную страницу rsyncd.conf):

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

Затем на целевом компьютере вы запустите:

user@dest:~$ rsync -avP source-ip::big-archive/ /target

Вы можете сделать это и наоборот (но, конечно, вам нужно будет установить только чтение). Существуют варианты аутентификации и т. Д., Обратитесь к man-странице за подробностями.

Как? Или TL; DR

Самый быстрый метод , который я нашел это сочетание tar, mbufferи ssh.

Например:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Благодаря этому я добился устойчивой передачи по локальной сети со скоростью более 950 Мбит / с по каналам 1 Гбит. Замените пути в каждой команде tar, чтобы они соответствовали тому, что вы переносите.

Зачем? mbuffer!

Самым большим узким местом в передаче больших файлов по сети является, безусловно, дисковый ввод-вывод. Ответ на это mbufferили buffer. Они во многом похожи, но mbufferимеют некоторые преимущества. Размер буфера по умолчанию составляет 2 МБ для mbufferи 1 МБ для buffer. Большие буферы с большей вероятностью никогда не будут пустыми. Выбор размера блока, который является наименьшим общим кратным собственного размера блока как в целевой, так и в целевой файловой системе, даст наилучшую производительность.

Буферизация это то , что делает все различия! Используйте это, если у вас есть это! Если у вас его нет, получите! Использование (m}?bufferплюс что-либо лучше чем что-либо само по себе. это почти буквально панацея для медленной передачи файлов по сети.

Если вы передаете несколько файлов, используйте tarих для объединения их в один поток данных. Если это один файл, который вы можете использовать catили перенаправление ввода / вывода. Накладные расходы на tarvs. catстатистически незначимы, поэтому я всегда использую tar(или zfs -sendтам, где могу), если это уже не тарбол . Ни один из них не гарантирует вам метаданные (и, в частности cat, не даст). Если вы хотите метаданные, я оставлю это в качестве упражнения для вас.

Наконец, использование sshдля транспортного механизма является безопасным и несет очень мало накладных расходов. Опять же, накладные расходы по sshсравнению ncстатистически незначимы.

Вам даже не нужно использовать TCP. AoE - это реализация ATA через Ethernet, а на втором уровне это подход с меньшими издержками, без знания стека TCP / IP. Это обеспечит вам максимально быстрый перевод с наименьшими накладными расходами. ***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

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