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

Наверное всё-таки рсинк. Но можно и так:

tar -C srcdir -c . | pigz | ssh host tar -C destdir -zx

Тут есть такой затык: создание файлов даже 0 размера требует относительно много времени из-за всяких сбросов буферов, журналирования и прочих предосторожностей авторов ФС. С другой стороны линейная запись файлов даже на шпинделе как правило быстрее сети. Из-за постоянных спотыканий на создание файлов и прочее обновление метаинформации полная скорость не достигается. С NFS/FTP/SMB этот эффект усиливается (по моему опыту).

Вот у меня вродебы и 2x8ядерных Xeon, Raid5 и SAS диски и сеть гигабитная, а 7000 файлов, в сумме на 2Tb копируются долго.

Будто ядра в этом деле сильно помогают, лол.

Да, понятно, я так, описать что крутая система впринцпе, а почемуто все мееееедлееено, несмотря на всю крутость.

FXP, но про эту FTP магию 80-го уровня знают немногие.

способ передачи файлов между двумя FTP-серверами напрямую, не закачивая их на свой компьютер. При FXP-сессии клиент открывает два FTP-соединения к двум разным серверам, запрашивая файл на первом сервере, указывая в команде PORT IP-адрес второго сервера.

Долго каким методом? Как долго? Так-то даже в теории быстрее 4.5 часов 2тб через 1gbit не пролезут.

Сейчас rsync копирует 80Mb/s разумеется не напрямую, а через циску.

netcat?

target> ( mkdir dir && cd dir && nc -l PORT | tar xvvf - )

sorce> ( cd updir && tar -c -f - dir | nc target PORT )

Ну нормально, на гигабите-то. Не забываем, что гигабит в 8 раз меньше гигабайта. Плюс накладные расходы, усушка-утруска.

По желанию приправить gzip/bzip2/xz

Только pigz, всё остальное медленнее винтов и сети.

scp, samba

rsync копирует 80Mb/s разумеется не напрямую, а через циску

NFS/CIFS у меня выдают 100+ на igb/e1000 в зависимости от раздаваемых файлов.

Если есть деньги на крутые серверы, то рекомендую купить к ним 2 10GbE-карточки и DAC, для гладких и шелковистых волос.

Вы сами копируете терабайты? как?

DAC, для гладких и шелковистых волос.

Что это? И почему волосы станут гладкими и шелковистыми?

pigz

lzop ещё, вроде.

Нет, у меня сотни гигабайт. рсинком.

Direct-attached cable. Для SFP+ сетевых карт.

И почему волосы станут гладкими и шелковистыми?

Это так, из одной вирусной рекламы.

samba постабильнее будет и побыстрее чем NFS

Рекламу, да, знаю. Про DAC не нашёл подходящей расшифровки :)

На винде я что-то каких-то сногсшибательных скоростей не наблюдаю.

iSCSI экспорт диска с одного и импорт с другого

На Линуксе она реально быстрее чем NFS

Но можно и так:

Будут накладные расходы на шифрование трафика (ssh).

Как мне кажется, на ПК и серверах это пустяки. Но можно и через nc, конечно.

Торрент - как протокол. Если запустишь свой трекер, автоматизируешь создание torrent файла и файлы не изменяются (так что нужен rsync).

Особенно если файлы большие и если надо копировать на много машин

Надо что ли написать такую копировалку, которая если есть доступ к удаленной машине по ssh, то она туда залогинится, запустит консольный rtorrent с magnet ссылкой на локально запущеный трекер, скачает все. И потом если копируешь на еще кучу машин, то оно реюзает трекер и уже существующие копии. Вот это было бы норм.

Если нужно больше технических решений на грани больной фантазии, обращайтесь

А ты хитрец. Оп вот он файл тут, закрываем глаза, открываем глаза, вот от «там».

Как мне кажется, на ПК и серверах это пустяки.

На современных, да. Но еще лет 15 назад разница между rcp и scp была в несколько раз (2 MB/s у scp против 13 MB/s у rcp).

Я бы промолчал, если бы автор специально не подчеркнул в исходном сообщении, что шифрование не нужно.

Но можно и через nc, конечно.

Угу, на мой взгляд, самый быстрый способ.

все это бесполезно, если скорость записи меньше скорости передачи по сети :(

Если «tar -C srcdir -c . |pv >/dev/zero» меньше скорости сети, то паковать бесполезно :)

конструкция «tar -C srcdir -c . | pigz | pv >/dev/zero» должна показывать скорость близкую к скорости сети (1Gbit/s), иначе оно бесполезно. Подбирая степень компрессии и число потоков можно подобрать скорость близкую к скорости сети.

Я бы еще перед pigz вставил что-то типа vbuf на 20-100Мб если скорость чтения и компрессии сильно скачет.

Это что-же антиквариат такой должен быть вместо НЖМД, чтобы линейная запись была [заметно] медленнее гигабитной сети? Даже десктопные WD green уж 80мб/сек могут выдать. Ну может быть бюджетные SSD сейчас достаточно медленные, но они и маленькие вдобавок, так что некуда спешить.

Если «tar -C srcdir -c . |pv >/dev/zero» меньше скорости сети, то паковать бесполезно

Не бесполезно:

1) мы в сети иногда не одни

2) гзип считает контрольную сумму, а тар - нет.

vbuf

О, прикольная штука. Хотя можно и простой fifo подтюнить, на стековерфло был перловый скрипт.

samba .... побыстрее чем NFS

Аж поперхнулся. Ну да, конечно...

постабильнее

Сильно относительно. На неустойчивых каналах, в целом да, nfs лагает. Но в каждом «но» есть свое «но», как пример, был поддиванный nas (WD) так на smb лагал по полной, а вот через nfs стало все зашибись.

Jumbo frames и многопоточный rsync

На Линуксе она реально быстрее чем NFS

ЛПИП, по определению быть такого не могет. Вы когда-нидь смотрели на внутренности smb? Там костыль над костылем и завернуто все в костыли и снизу все теже костыли, которые стоят на трех костылях, а те стоят на большом костыле. Оверхэда просто дофига. Это исторически так сложилось, мс при разработке думала что земля плоская.

А какой use case у топикстартера?

А то мы тут фантизируем...

Я это даже в lorquotes добавил.

tar -C srcdir -c . | pigz | ssh host tar -C destdir -zx

У ssh (включая scp) есть встроенный компрессор. Там есть определенные тонкости, разрешена ли компрессия на ssh-сервере, но можно попробовать как-то так:

scp -C -r srcdir sshhost:/tmp

Вот только у меня это обычно замедляло скорость, но на хорошо сжимаемых данных может дать выигрыш.

На 10g сетке давал прикольный прирост костыль из связки netcat запущенных по количество ядер(12шт).

Но это крайне не удобно, и я даже не воспроизведу сейчас это наколенное творчество. Но, прирост по сравнению с scp/rsync был больше чем в 3 раза, что делало игру стоящей свеч.

Имеет смысл развелкаться только если надо реально дофига данных передать в общем.

Надо что ли написать такую копировалку, которая если есть доступ к удаленной машине по ssh, то она туда залогинится, запустит консольный rtorrent с magnet ссылкой на локально запущеный трекер, скачает все. И потом если копируешь на еще кучу машин, то оно реюзает трекер и уже существующие копии. Вот это было бы норм.

https://blog.twitter.com/engineering/en_us/a/2010/murder-fast-datacenter-code...

https://vimeo.com/11280885

Yep, все логично. В принципе достаточно очевидное решение, которое хорошо подойдет для распространения образов

Внешний НГМД через USB2.0 :)

Вместо ssh взять nc.

Вопрос в выборе компрессора.

Для примера /dev/sda3 это ssd/sata3, 4 ядра AMD A10-6700

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | pv | wc -c
1.22GiB 0:00:02 [ 515MiB/s]
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 2.42297 s, 541 MB/s
1310720000

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | zstd -1 -T4 -c - | pv | wc -c
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 2.79946 s, 468 MB/s
 363MiB 0:00:02 [ 129MiB/s]
381347723

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | zstd -8 -T4 -c - | pv | wc -c
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 16.9145 s, 77.5 MB/s
 326MiB 0:00:18 [17.8MiB/s]
342067615

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | lz4 -1 -c - | pv | wc -c
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 5.37503 s, 244 MB/s
 432MiB 0:00:05 [80.4MiB/s]
453689489

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | pigz -1 -c - | pv | wc -c
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 6.85417 s, 191 MB/s
 378MiB 0:00:06 [55.2MiB/s]
397369828

root@gw3: ~# dd if=/dev/sda3 bs=64k count=20000 | gzip -1 -c - | pv | wc -c
1310720000 bytes (1.3 GB, 1.2 GiB) copied, 21.4842 s, 61.0 MB/s
 380MiB 0:00:21 [17.7MiB/s]
398796489

«echo 3 >/proc/sys/vm/drop_caches» перед каждым запуском.

lz4 и gzip - 1 ядро

rsync работает медленнее, чем два тара через пайп. проверял

torrents. Из плюсов - если сразу нужно на много машин - то будет быстрее

может - тестировали на практике samba vs nfs - samba оказалась быстрее ..

Ну значит что-то у вас было не так или в настойках или в самой сети. nfs к нестабильности в сети достаточно «чувствителен» это факт.

Скорее zstandard.