LINUX.ORG.RU

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

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

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

legolegs ★★★★★ ()
Последнее исправление: legolegs (всего исправлений: 1)

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

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 2)
Ответ на: комментарий от sniper21

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

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

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

whiteout ()

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

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

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

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

vertexua ★★☆☆☆ ()
Последнее исправление: vertexua (всего исправлений: 5)
Ответ на: комментарий от legolegs

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

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

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

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

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

Serge10 ★★ ()
Ответ на: комментарий от legolegs

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

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

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

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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

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

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

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

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

vbuf

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

legolegs ★★★★★ ()
Последнее исправление: legolegs (всего исправлений: 1)
Ответ на: комментарий от Jopich1

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

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

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

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

anc ★★★★★ ()
Ответ на: комментарий от Jopich1

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от legolegs

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

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

scp -C -r srcdir sshhost:/tmp

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

dr15 ()

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

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

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

onhydro ()
Ответ на: комментарий от vertexua

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

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

https://vimeo.com/11280885

i-rinat ★★★★★ ()
Ответ на: комментарий от legolegs

Внешний НГМД через 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 ядро

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)