Przesyłanie dużych plików (8 GB) przez ssh

27

Próbowałem z SCP, ale napis „Negatywny rozmiar pliku”.

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

Próbowałem także przy użyciu SFTP, działało dobrze do momentu przesłania 2 GB pliku, a następnie przestało działać:

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

Masz pojęcie, co może być nie tak? Czy SCP i SFTP nie obsługują plików większych niż 2 GB? Jeśli tak, to jak mogę przesyłać większe pliki przez SSH?

Docelowym systemem plików jest ext4. Dystrybucja Linuksa to CentOS 6.5. System plików ma obecnie (dostępne) duże pliki (do 100 GB).

scp sftp large-files eimrek
źródło
5
Wygląda jak zmienne przekroczenie wielkości. Ale AFAIK scp / sftp nie ma limitu rozmiaru. Co to jest docelowy system plików? Czy obsługuje LARGEFILES?
Milind Dumbare
1
Co z aplikacjami sftp i scp? Możesz to sprawdzić za pomocą polecenia file przeciwko ich plikom binarnym.
mdpc
1
@ shepherd - tak.
mdpc,
2
Aplikacje 32-bitowe mogą uzyskiwać dostęp do dużych plików, jeśli są one kompilowane -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. Ale jeśli korzystasz z 64-bitowego systemu 6.5, prawdopodobnie łatwiej byłoby mieć administratorów zainstalowanych openssh-5.3p1-94.el6_6.1.x86_64i openssh-server-5.3p1-94.el6_6.1.x86_64ze standardowych repozytoriów.
Mark Plotnick
1
lol w oprogramowaniu używającym liczb całkowitych ze znakiem dla rozmiaru pliku
Lekkość wyścigów z Moniką

Odpowiedzi:

9

Pierwotny problem (oparty na przeczytaniu wszystkich komentarzy do pytania OP) polegał na tym, że scpplik wykonywalny w systemie 64-bitowym był aplikacją 32-bitową. 32-bitowa aplikacja, która nie została skompilowana z „obsługą dużych plików”, kończy się na ograniczeniu wskaźników wyszukiwania 2^32 =~ 4GB.

Możesz sprawdzić, czy scpjest 32-bitowy, używając filepolecenia:

file `which scp`

W większości nowoczesnych systemów będzie to wersja 64-bitowa, więc nie nastąpi obcięcie pliku:

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

32-aplikacja powinna nadal być w stanie obsługiwać „duże pliki”, ale musi być skompilowana ze źródła z obsługą dużych plików, co najwyraźniej nie było w tym przypadku.

Zalecanym rozwiązaniem może być użycie pełnej standardowej dystrybucji 64-bitowej, w której aplikacje są domyślnie kompilowane jako 64-bitowe.

arielf
źródło
33

Rsync bardzo dobrze nadaje się do przesyłania dużych plików przez ssh, ponieważ jest w stanie kontynuować przesyłanie, które zostały przerwane z jakiegoś powodu. Ponieważ wykorzystuje funkcje skrótu do wykrywania równych bloków plików, funkcja kontynuacji jest dość solidna.

Zaskakujące jest to, że twoje wersje sftp/ scpnie wydają się obsługiwać dużych plików - nawet w przypadku 32-bitowych plików binarnych obsługa LFS powinna być obecnie dość standardowa.

maxschlepzig
źródło
4
Biorąc pod uwagę, że duża część pliku jest już przesłana, rsyncjest to dobry pomysł. Skorzystaj z tej -Popcji, aby zarówno uzyskać wskazanie postępu, jak i poinstruować odbiorcę, aby zachował niekompletny plik na wypadek, gdyby przesyłanie zostało ponownie przerwane.
Simon Richter
25

Nie jestem pewien limitów rozmiaru plików SCP i SFTP, ale możesz spróbować obejść problem z podziałem:

split -b 1G matlab.iso

Spowoduje to utworzenie 1 plików GiB, które domyślnie są nazywane jako xaa, xab, xac, .... Następnie możesz użyć scp do przesłania plików:

scp xa* xxx@xxx:

Następnie w systemie zdalnym odtwórz oryginalny plik za pomocą cat:

cat xa* > matlab.iso

Oczywiście karami za to obejście są czas pracy operacji dzielenia i operacji cat, a także dodatkowe miejsce na dysku potrzebne w systemach lokalnych i zdalnych.

zakręcić
źródło
1
dobry pomysł. Plik został już przesłany za pomocą dysku USB, ale prawdopodobnie byłoby to wygodniejsze. Nie jest to jednak tak wygodne, jak poprawne działanie scp i sftp.
eimrek