Через ssh: там, откуда копировать, запускаем gzip и передачу файлов через трубу, там, куда копировать, раззиповываем.

А вообще, странно, что так медленно.

По сети? 160 гигов? Ну сутки будет копировать, мб больше. Хочешь быстро - езжай к удаленному компу, выдергивай винт и тащи его к себе.

что значит через gzip? на файловом серваке запаковать и перелить на пустой файл?

200 гиг мускульных дампов по гигу - перелились по сети за шесть часов.

это для примера.

хотят тут наверно долго изза мелкого размера файла

А вообще, странно, что так медленно.

Чего тут странного, если

160 гиг мелкого 1-2 килобайтного файла

На файл-сервере запаковываете, но выхлоп gzip'а идет не в файл, а по ssh туда, куда надо это скопировать. Там, соответственно, на выходе трубы распаковывается. Недостаток: если сеть накроется, придется все копировать снова.

пример можете показать? а что если чесно не понимаю как это сделать.

Ты упоротый? Я тебе уже говорил копируй на уровне блочного устройства (drbd) или lvm-snapshot + ssh + dd или (лоровские задроты считают что LVM-ненужен) делай dd + ssh + fsck

поднимать drbd ради одного копирований?

tar -czf - /some/file | ssh host.name tar -xzf - -C /destination

А вообще, ищущий да обрящет.

Не шлангуй. drbd был предложен в теме «каждые 15 минут синхронизировать >250 миллионов файлов»

Здесь же:

1. lvm-snapshot --> dd | ssh dd

2. нет LVM --> dd | ssh dd; fsck

Ему не нужно копировать раздел целиком. Да и от этого есть смысл, лишь в случае, когда раздел почти полностью забит. А во всех остальных случаях лучше всего - tar over ssh.

> через нфс.

Насколько мне известно, nfs работает через udp, то есть у тебя нет гарантии что все файлы доехали корректно. На сеть другой нагрузки в это время не было?

Насколько мне известно, nfs работает через udp, то есть у тебя нет гарантии что все файлы доехали корректно.

Гарантия есть: либо файлы доехали корректно, либо не доехали.

Если при передаче одного файла в середине было потеряно несколько пакетов, то как об этом узнает команда cp?

Ему не нужно копировать раздел целиком.

В случае с мелкими файлами копирование раздела целиком может оказаться быстрее копирования всех файлов по отдельности. Чтобы не копировать незанятые места раздела, можно вместо dd использовать partclone или partimage. Но проделывать такие фокусы нужно с отмонтированным разделом, иначе ФС может перенестись битой.

Если при передаче одного файла в середине было потеряно несколько пакетов, то как об этом узнает команда cp?

Команда cp об этом узнает от соответствующего системного вызова, системный вызов от VFS, VFS от драйвера NFS, а драйвер NFS узнает о потере из пропущенных номеров пакетов или неправильной контрольной суммы (я не знаю точно какой именно там способ, но он однозначно есть).

И вообще, TCP тоже работает поверх «ненадёжного» протокола IP, но целостность потока там тем не менее гарантируется =).

Неверное планирование не освобождает от титула «дебил». Проекты с таким кол-вом файлов не распологают в директории на /, впрочем ЛОРовская школота с криками «LVM не нужен» и «достаточно / и /home» может теперь жевать свои мозоли.

А ты сначала подумай сколько времени займет просто прочитать с диска ~150.000.000 метаданных файлов, а потом и сами файлы — время копирования по сети можно будет не учитывать.

Уже пару-тройку лет по умолчанию nfs в линуксе через tcp.

А так, udp пакет имеет аналогичную tcp контрольную сумму, а повторную передачу пакетов организовывал уже сам nfs. Не помню, чтобы у меня были проблемы с передачей файлов по nfs по udp по 10 Мбит коксиальному кабелю.

>Быстро перенести

libastral.so, быстро, решительно.

Плюсую за dd, ему пофиг на фс, будет копировать одним потоком.

лоровские задроты считают что LVM-ненужен

Неправда, LVM нужен! :)

time purkeent

>Быстро перенести(скопировать) мегадиректорию

Камаз болванок же! Терабайты в секунду...

Сеть то хотя бы гигабитная?

А вобще, ИМХО, такой объем по сети лучше копировать кусками, чтобы с случае обрыва связи знать какие куски перекопировать заново, например, запускать отдельно последовательно копирование по каталогам верхнего уровня. И сначала проверить скорость nfs копированием достаточно большого файла (~500 Мбайт).

Кстати, LVM-снапшот можно как то копировать кусками?

> Кстати, LVM-снапшот можно как то копировать кусками?

dd seek/skip

> Если при передаче одного файла в середине было потеряно несколько

пакетов, то как об этом узнает команда cp?

Это - задача NFS.

rsync ещё есть...

Да, в этом направлении я и думал. А то мне надо будет 850 Гб по 100 Мбит сетке слить.

Дык файлы там небось текстовые. Может таки запаковать банально и передать, а там распаковать?

про rsync молчи, пускай scp юзают

если сеть накроется, придется все копировать снова.

rsync -Pavzr from to:path

>лоровские задроты считают что LVM-ненужен

не бузи

Пора уже спросить. Копирование завершилось? :)

tar -c foldername | nc -l -p 8888

nc serveraddres 8888 | tar -x

для мелких файлов ничего лучше не придумать

gzip

и gzip -dc

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

нет ..сутки простояло - перелило только 40 гиг. это через нфс копированием cp

Быстрее уже было бы целым разделом скопировать :)

тар с лёгкой gz компрессийей на pipe .. а дальше не знаю

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

Ага, или вообще как предлагалось выше вынуть винт и напрямую слить с него нужную инфу.

Да он быстрее DVD-RW'шками бы перетаскал :)

серваки на коло стоят в заднице киева (воляматьего датацентра на отсосниных)

целым разделом не выйдет. там очень грамотный предшественник отдал весь винт под один раздел

И правильно сделал.

А что же вы не пробовали-то при помощи tar'а файлы копировать?

как?

tar + netcat

я выше написала как

можно вас попросить пример показать?. я не понимаю что нужно написать

И я писал, но через ssh.

на источнике

tar -c . | gzip | nc -l -p 9999

упаковываем текущий каталог, пакуем поток gzip, nc (netcat) будет слушать на порту 9999


на приемнике

nc serveraddress 9999 | gzip -dc | tar -x

соединяемся к serveraddress порт 9999 , расжимаем gzip, распаковываем tar

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