Как перенести файлы по сети максимально быстро?
На десктопе есть раздел /storage — ntfs,
800G файлов. Файлы разного размера.
На сервере есть пустой раздел /storage — ext4.
Пытался сделать так:
Увидел, что скорость скачет от десятков мегабайт, до килобайт. То есть когда scp передаёт мелкие файлики — скорость мизерная.
Видимо он передаёт их по очереди, что и убивает скорость.
Какая утилита даст мне максимальную скорость? Желательно через ssh (не поднимать отдельный сервер вроде Самбы).
Какая утилита даст мне максимальную скорость? Желательно через ssh
Заархивь в один архив все, и передай архивом. Но ты потратишь время на архивирование, равное примерно тому же времени, что и просто передача мелких файлов.
Только tar, только хардкор. В смысле, всю мелочь желательно в архив сунуть, а потом передать scp.
Если хватит места — загоняй в архив и его уже scp.
Никаких архивов на диске, все на лету.
можно исп. tar -C, но это не везде есть, так что лучше без.
И если на диске лежат хорошо сжимаемые файлы (текст), то стоит добавить опцию z к обоим tar’ам
maybe rsync
Спасибо за советы, tar без сжатия + ssh + pipeline льёт гораздо быстрее.
В данном случае nfs, скорее всего, будет иметь самую высокую скорость. «Поднятие» такового обычно сводится к полутора командам.
server1# tar -c /full/path | bzip2 -zc9 > /data.tar.bz2
server1# scp /data.tar.bz2 root@server2:/
server2# cd / ; bzip2 -dc /data.tar.bz2 | tar -x
распакуется прямо «в то же место», что и на основном сервере.
«9» — максимальный режим компрессии.
два чая этому господину
rsync имел бы смысл, если бы на втором винте была хотя бы часть данных с первого, просто копирование у него вроде бы не быстрее чем scp
dd с одного терабайтного винчестера на другой в пределах одного компьютера делается три часа, а ты по сети хочешь 🙂
Лучше пешком к серверу отправится с хардом в кармане 🙂
распакуется прямо «в то же место», что и на основном сервере.
Я для этого использую команду sdio:
cd /storage; tar cf — Dropbox | ssh root@192.168.0.1 tar xf — -C /laundry
Сервер домашний, локалка гигабитная — 43М/s.
rsync точно также медленно будет пересылать данные — проверено.
Я бы единоразово открыл ящик для такого случая или через USB-контроллер, если не хочется ждать сутками. Надеюсь, есть ещё один бэкап где-то (всегда должно быть более 1го или даже 2х копий). Зависит от ценности данных, правда.
А в будущем — регулярный инкрементальный rsync с десктопа на сервер, много не накапливая. И желательно — ещё один (раз в год например) с сервера на 3й диск — который хранить удалённо.
Кстати, ssh замедляет, пользую NFS между 2мя линукс-машинами и SMB — между десктопами и 1м сервером (так и фотографии листать, прямо с сервера, удобно, и старую почту или записи искать, особенно когда более одного десктопа)
Попробуй с другим алгоритмом.
При выборе алгоритма шифрования нужно исходить из конфиденциальности информации, которую вам нужно передать. Если информация секретна, лучше использовать алгоритмы IDEA или RSA. Если же вы просто не хотите передавать данные в открытом виде, используйте алгоритм BlowFish, поскольку он работает значительно быстрее, чем DES.
50 гб, включая кучу мелких файлов, по локалке 100мбит/с — скорость была порядка 11-12 мб/с (88-96 мбит/с), по времени почти то на то и вышло.
Особенно если использовать его over ssh. С rsyncd оно заметно быстрее работает.
Мне интересно, сколько времени займёт сжатие с 9-ым уровнем
Источник
Низкая скорость копирования
Доброго времени суток.
Проблема такая: у в mc, tuxcmd и даже cp скорость копирования на носитель раз в десять (если не больше) меньше чем скорость в nautilus’e. Собственно и сам наутилус я накатил что-бы сбэкапить важные данные быстрее. Но так в нем необходимости в моём опенбоксе нет.
Собственно вопрос, можно увеличить скорость копирования в том же mc, что-бы была как в наутилусе ?
А что за файловая система? Дистрибутив? Вообще странно всё это.
Debian, копирую на ntfs. Говорят что-то связанно с асинхроной передачей данных, но что-то я не в курсе.
А какая скорость-то? Вообще через ntfs-3g оно же еле ворочается, так сказать, by design. У меня вот скорость копирования на ntfs-раздел обычно 12 мбит/с не превышает.
Проблема такая: у в mc, tuxcmd и даже cp скорость копирования на носитель раз в десять (если не больше) меньше чем скорость в nautilus’e. Собственно и сам наутилус я накатил что-бы сбэкапить важные данные быстрее.
Говорят что-то связанно с асинхроной передачей данных, но что-то я не в курсе.
Ты, главное, диск не вынимай сразу, как он закончит копировать. Или наоборот, вынь диск сразу, а потом проверь свои «бэкапы». Тогда поймёшь.
Я надеюсь, ты делаешь отмонтирование? Попытайся «скинуть» что-нибудь большое через наутилус, а потом сразу отмонтировать. Он должен не дать тебе это сделать.
Ещё тебе может дать намёк светодиодный индикатор занятости этого диска, если он у тебя есть.
Это само собой:) Всё отмонтирываю по правилам. И данные рабочие)
Как говорит наутилус, скорость 28 или меньше мб/c. Это устраивает. А вот когда копировал фильм 3 гига через mc, и это занимало несколько часов, я расстроился.
Это все хорошо, но как разные программы влияют на параметры монтирования одной и той же точки?
Может быть, всё дело в bs (количестве байт, копируемом за раз)?
Не могу отрицать, так же как и не знаю, как это менять 🙂
>копирую на ntfs
Чтобы под вантузом видно было. // K.O.
>Чтобы под вантузом видно было.
Потому-что я съёмный винт не только в линукс вставляю.
Есть предположение, что эта самая ntfs расположена на внешнем, переносном винте или флешке, которые ТС может втыкать в компы не оборудованные предусмотрительно линуксом.
Что чтение, что запись — 30-35 Мб/с. Все, что USB-интерфейс позволяет. Вероятно, у тебя NTFS раздел сильно фрагментирован.
Угу, и при этом наутилусу фрагментация пофигу, и остальным нет.
Тем более я с момента покупки с него ничего не удалял, только копирую на него, так что фрагментация там мала.
А вот запросто, потому что прослойка может указывать свои параметры.
Ты что, не помнишь, что при монтировании через Dolphin/Plasma в KDE 4 до какой-то версии (мелкой, что-то вроде 4.1.x) флэшки с FAT показывали кракозябры вместо русских имён файлов? Вот.
Но я не совсем понимаю, при чём тут параметры монтирования, потому что ТС монтирует одинаково во всех случаях, как я понял.
Не проверял, но не должен бы.
Может быть, у наутилуса другой способ копирования ?
> потому что прослойка может указывать свои параметры.
Указывать она вряд ли что-то может, так как диск уже смонтирован. Какой-то собственный кэш использовать — да, может. Но итоговая скорость все равно бы не увеличилась.
Ты что, не помнишь, что при монтировании через Dolphin/Plasma в KDE 4 до какой-то версии (мелкой, что-то вроде 4.1.x)
Я как раз после выхода 4-ки с KDE слез.
Но я не совсем понимаю, при чём тут параметры монтирования, потому что ТС монтирует одинаково во всех случаях, как я понял.
Вот именно — диск уже смонтирован с некими заданными параметрами, а разные приложения работают с ним по-разному.
> Угу, и при этом наутилусу фрагментация пофигу, и остальным нет.
А я не тебе отвечал.
Есть предположение, что наутилус пи^Wобманывает, и просто кеширует много за раз в отличии от.
А вообще man UDF.
ХР только читает, ЕМНИП.
Указывать она вряд ли что-то может, так как диск уже смонтирован. Какой-то собственный кэш использовать — да, может. Но итоговая скорость все равно бы не увеличилась.
Ты сам заговорил про параметры монтирования, я тебе ответил.
А это — не параметры монтирования.
Вот именно — диск уже смонтирован с некими заданными параметрами, а разные приложения работают с ним по-разному.
Тому может быть много причин. От игрищ с размером блоков, до принудительной синхронизации там, где кажется, что медленно (но тогда в этом «убыстрении» смысла нет).
Тс, поиграйся с dd и размером блоков при копировании большого файла, о результатах сообщи.
Ты уверен, что вся запись синхронная? После быстрого «копирования» большого количества данных через Nautilus у тебя индикатор больше не светится, получается сразу же отмонтировать диск?
Ну выскочит не надолго маленькое окошко «Запись данных», потом отмонтируется.
Во! Тогда вопрос решён, да?
Это ненадолго равно тому, сколько копирует mc и cp. То есть <время от начала копирования через cp до конца копирования через cp>равно <времени от начала копирования через nautilus до закрытия этого окошка «запись данных»>. Ну да, во втором случае nautilus сообщил о конце копирования раньше, и ты развлёкся поиском кнопки отмонтирования за то же время.
Нет, в слушая с mc это занимало несклько часов, а тут меньше 20 минут.
У меня Наутилус врёт. И Konqueror тоже. Они говорят, что всё скопировано, а жмёшь на «Отмонтировать» и ждёшь завершения работы команды и перемигивания лампочки.
Условия были одинаковыми? Проверь ещё пару раз через mc и через наутилус с одинаковыми файлами, по очереди.
Я проверял, иначе бы сюда не постил 🙂 Я пробовал как угодно, лишь бы не ставить наутилус, но всё равно пришлось.
Ты, главное, диск не вынимай сразу, как он закончит копировать. Или наоборот, вынь диск сразу, а потом проверь свои «бэкапы». Тогда поймёшь.
Я думал это баг -__-
Вынимал диск сразу, проверял бэкапы 🙂 Всё с ними норм. Ваще не понимаю зачем это окошко без полосы прогресса.
Либо плохо проверял, либо повезло, либо все это враки.
К примеру копирую я 1.4 гиговый ави на флешку, закрылось окно прогресса, давая понять что копирование якобы завершено. Но индикатор на флешке еще минуту мигать будет. Если выну флешку сразу после закрытия окна копирования, файл будет битый. Меня это дико бесило в гноме.В кедах к счастью все нормально.
а монтировал наутилусом? а при при копировании mc и cp каким образом монтировал? а еще не советую копировать mc большое количество данных — тормоз он полный.
Это фича. Оно сложило всё в дисковый кэш, не волнуйся, оригинал можешь смело удалять.
Фича это потому что ядро само решит, когда записать данные, как ему удобнее, и может планировать нагрузку. И потому, что пользователь гораздо быстрее увидит конец операции и получит возможность переместить/переименовать/удалить/внести изменения в исходные файлы. Или открыть файлы из места, куда он их скопировал (они из дискового кэша откроются).
А вот отсутсвие внятного сообщения в KDE при попытке отмонтировать (просто выдаёт ошибку) или индикатора занятости устройства — баг. Кто оформит багрепорт?
Сравнивай nautilus и cp. Про mc забудь пока.
Читай выше, почему это нормально.
Да, врать он не должен, для этого хорошо бы иметь что-то вроде индикатора занятости (лампочка далеко не на всех внешних устройствах есть) или хотя бы внятного описания ситуации при попытке отмонтировать.
И ещё: такое поведение отключается, если оно тебе не нравится. Но ты потеряешь плюшки.
ИМХО, совет про dd и размеры блока был правильным. С учётом: http://www.tuxera.com/community/ntfs-3g-faq/#dd
>Debian, копирую на ntfs. Говорят что-то связанно с асинхроной передачей данных, но что-то я не в курсе.
С этого и надо было начинать. Значит надо копать в сторону ntfs-3g? Дай угодаю, копируется великое множество мелких файлов?
>Может быть, у наутилуса другой способ копирования ?
Конечно, через свои прослоечные функции. mc копирует системной функцией, а не cp, cp конечно же тоже.
Источник
