Transferencia de archivos grandes (8 GB) a través de ssh

27

Lo probé con SCP, pero dice "Tamaño de archivo negativo".

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

También intenté usar SFTP, funcionó bien hasta que se transfirieron 2 GB del archivo, luego se detuvo:

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

¿Alguna idea de lo que podría estar mal? ¿SCP y SFTP no admiten archivos de más de 2 GB? Si es así, ¿cómo puedo transferir archivos más grandes a través de SSH?

El sistema de archivos de destino es ext4. La distribución de Linux es CentOS 6.5. El sistema de archivos actualmente tiene archivos grandes (accesibles) (hasta 100 GB).

scp sftp large-files eimrek
fuente
55
Parece una sobrecarga de tamaño variable. Pero AFAIK scp / sftp no tiene límite de tamaño. ¿Cuál es el sistema de archivos de destino? ¿Soporta LARGEFILES?
Milind Dumbare
1
¿Qué pasa con las aplicaciones sftp y scp? Puede encontrar esto usando el comando de archivo contra sus binarios.
mdpc
1
@ pastor - sí.
mdpc
2
Las aplicaciones de 32 bits pueden acceder a archivos grandes si se compilan con ellas -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. Pero si está ejecutando un sistema 6.5 de 64 bits, probablemente sería más fácil hacer que los administradores instalen openssh-5.3p1-94.el6_6.1.x86_64y openssh-server-5.3p1-94.el6_6.1.x86_64desde los repositorios estándar.
Mark Plotnick
1
jajaja en el software que usa enteros firmados para el tamaño del archivo
Lightness Races with Monica

Respuestas:

9

El problema original (basado en la lectura de todos los comentarios a la pregunta OP) fue que el scpejecutable en el sistema de 64 bits era una aplicación de 32 bits. Una aplicación de 32 bits que no está compilada con "soporte para archivos grandes" termina con punteros de búsqueda que están limitados a 2^32 =~ 4GB.

Puede saber si scpes de 32 bits utilizando el filecomando:

file `which scp`

En la mayoría de los sistemas modernos será de 64 bits, por lo que no se producirá el truncamiento de archivos:

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

Una aplicación de 32 todavía debería ser capaz de soportar "archivos grandes", pero tiene que ser compilada desde la fuente con soporte para archivos grandes, lo que aparentemente este caso no era.

La solución recomendada es quizás usar una distribución estándar completa de 64 bits donde las aplicaciones se compilan como 64 bits de forma predeterminada.

arielf
fuente
33

Rsync es muy adecuado para transferir archivos grandes a través de ssh porque puede continuar transferencias que fueron interrumpidas por alguna razón. Como utiliza funciones hash para detectar bloques de archivos iguales, la función de continuación es bastante robusta.

Es sorprendente que sus versiones sftp/ scpno parezcan admitir archivos grandes, incluso con los archivos binarios de 32 bits, el soporte LFS debería ser bastante estándar hoy en día.

maxschlepzig
fuente
44
Dado que una gran parte del archivo ya está transferido, rsynces una buena idea ahora. Use la -Popción para obtener una indicación de progreso e indicar al receptor que mantenga un archivo incompleto en caso de que la transferencia se interrumpa nuevamente.
Simon Richter
25

No estoy seguro de los límites de tamaño de archivo de SCP y SFTP, pero podría intentar solucionar el problema con la división:

split -b 1G matlab.iso

Esto creará 1 archivos GiB que, por defecto, se nombran como xaa, xab, xac, .... Luego puede usar scp para transferir los archivos:

scp xa* xxx@xxx:

Luego, en el sistema remoto, vuelva a crear el archivo original con cat:

cat xa* > matlab.iso

Por supuesto, las penalizaciones por esta solución alternativa son el tiempo que se tarda en las operaciones de división y cat, así como el espacio extra en disco necesario en los sistemas locales y remotos.

girar
fuente
1
buena idea. Ya transferí el archivo con una unidad usb, pero esto probablemente habría sido más conveniente. Sin embargo, no es tan conveniente como hacer que scp y sftp funcionen correctamente.
eimrek