Передача больших (8 ГБ) файлов по ssh

27

Я попробовал это с SCP, но там написано "Отрицательный размер файла".

>scp matlab.iso xxx@xxx:/matlab.iso
matlab.iso: Negative file size

Также пытался использовать SFTP, работал нормально, пока 2 ГБ файла не были переданы, затем остановился:

sftp> put matlab.iso
Uploading matlab.iso to /home/x/matlab.iso
matlab.iso                                           -298% 2021MB -16651.-8KB/s   00:5d
o_upload: offset < 0

Есть идеи, что может быть не так? Разве SCP и SFTP не поддерживают файлы размером более 2 ГБ? Если так, то как я могу передавать большие файлы через SSH?

Файловая система назначения - ext4. Дистрибутив Linux - это CentOS 6.5. Файловая система в настоящее время имеет (доступны) большие файлы (до 100 ГБ).

scp sftp large-files eimrek
источник
5
Похоже на переполнение переменной размера. Но AFAIK scp / sftp не имеет ограничений по размеру. Что такое файловая система назначения? Поддерживает ли он LARGEFILES?
Милинд Думбаре
1
Как насчет приложений sftp и scp? Вы можете узнать это, используя команду file для их двоичных файлов.
MDPC
1
@ Шеперд - да.
MDPC
2
32-битные приложения могут получать доступ к большим файлам, если они скомпилированы -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. Но если вы используете 64-битную систему 6.5, вероятно, было бы проще установить администраторов openssh-5.3p1-94.el6_6.1.x86_64и openssh-server-5.3p1-94.el6_6.1.x86_64из стандартных репозиториев.
Марк Плотник
1
LOL в программном обеспечении, использующем целые числа со знаком для размера файла
Легкость Гонки с Моникой

Ответы:

9

Первоначальная проблема (основанная на чтении всех комментариев к вопросу OP) заключалась в том, что scpисполняемый файл в 64-битной системе был 32-битным приложением. 32-разрядное приложение, которое не скомпилировано с поддержкой больших файлов, заканчивается указателями поиска, которые ограничены 2^32 =~ 4GB.

Вы можете сказать, scpявляется ли 32-битным, используя fileкоманду:

file `which scp`

В большинстве современных систем он будет 64-битным, поэтому усечение файла не происходит:

$ file `which scp`
/usr/bin/scp: ELF 64-bit LSB  shared object, x86-64 ...

32-приложение должно по-прежнему поддерживать «большие файлы», но оно должно быть скомпилировано из исходного кода с поддержкой больших файлов, чего, по-видимому, в этом случае не было.

Рекомендуемое решение, возможно, состоит в том, чтобы использовать полный стандартный 64-битный дистрибутив, где приложения компилируются как 64-битные по умолчанию.

arielf
источник
33

Rsync очень хорошо подходит для передачи больших файлов по ssh, потому что он может продолжать передачу, которая была прервана по какой-то причине. Поскольку он использует хеш-функции для обнаружения одинаковых блоков файлов, функция продолжения довольно надежна.

Удивительно, что ваши sftp/ scpверсии, похоже, не поддерживают большие файлы - даже с 32-битными двоичными файлами поддержка LFS в настоящее время должна быть довольно стандартной.

maxschlepzig
источник
4
Учитывая, что большая часть файла уже передана, rsyncэто хорошая идея сейчас. Используйте эту -Pопцию, чтобы получить индикацию хода выполнения и указать получателю сохранить неполный файл на случай, если передача будет прервана снова.
Саймон Рихтер
25

Я не уверен насчет ограничений размера файлов SCP и SFTP, но вы можете попробовать обойти проблему с split:

split -b 1G matlab.iso

Это создаст файлы размером 1 ГиБ, которые по умолчанию названы как xaa, xab, xac, .... Затем вы можете использовать scp для передачи файлов:

scp xa* xxx@xxx:

Затем в удаленной системе заново создайте исходный файл с помощью команды cat:

cat xa* > matlab.iso

Конечно, штрафы за этот обходной путь - это время, затрачиваемое на операции split и cat, а также дополнительное дисковое пространство, необходимое в локальной и удаленной системах.

раскрутить
источник
1
отличная идея. Я уже перенес файл с USB-накопителя, но это, вероятно, было бы более удобно. Не так удобно, как заставить работать scp и sftp правильно.
eimrek