Nagy fileok mozgatása helyi hálón

NcFTP jó, gondoltam is rá, csak tegnap éjjel fél 3kor valahogy nem volt kedvem megtanulni, hogy hogyan kell a usernevet/passwordot megadni abban. :wink:
Sambát most engedelmetekkel passzolnám, mert nincs kedvem felrakni/beállítani,+van más tennivalóm is.

[quote:4243d89974="XMI"]NcFTP jó, gondoltam is rá, csak tegnap éjjel fél 3kor valahogy nem volt kedvem megtanulni, hogy hogyan kell a usernevet/passwordot megadni abban. :wink:

help open :wink:

[quote:5acbf5550e="drojid"]Mi a fene fogja meg 2gigánál? Az NTFS driver? Hol tudom vajon ezt a limitet beállítani?

Egynémelyik FTP szerverben van benne a 2 vagy 4 gigás limit (2 a 31-en vagy 2 a 32-en). Probalj meg mas ftp szervert (pl. ProFTPd) hasznalni... A midnight commander egyes verzioi se tudnak nagy fileokat kezelni... Az NTFS-ben biztos nincs korlat... Ott asszem egy particio max. 2 tera, a max. file is eleg nagy...

E-Medve

A FAT fajlrendszereken meg ha jol emlekszek, akkor 4 giga a limit. Az avi fajloknal pedig 2 G.

scp? Próbaképpen csináltam dd-vel egy 2.2GB-os file-t, scp-vel, ReiserFS-ről és Debian Sarge-ról ext3-ra és Woody-ra simán ment.

Nem lehet, h bár az NTFS-ben magában nincs fileméret korlát, de a Linuxos, még nem tökéletes driverben van?

[quote:a50b15f2d1="drojid"]a másik meg, hogy nem tudom, mivel tudnám splitni :) Barkács módszerrel először valószínűleg dd-vel próbálnám. Van kényelmesebb módszer? :)

man split
hagyne másoljam már ide be :wink:

Siman nem probaltad atcsovelni?

cat nagyfile | ssh masikszerver 'dd of=/ide/jon/a/file'

(esteleg gzip-pel kozben, ha jol nyomhato a file).

[quote:411023bea7="drojid"]Most a samba nagy sebességgel elkezdi másolni, aztán 2G-nál megáll.
NFS lassan is másolja, és most állt le (file size limit exceeded üzenettel).

Mi a fene fogja meg 2gigánál?

(2.6.7 kernel van a notebbokon, 2.6.3 a szerveren)

próbáld meg így hátha
mount -t smbfs //szerver/megosztas /helyikönyvtár/ -o lfs

meg persze ha kell user,jelszo akkor
-o username=blabla1,password=blabla2,lfs

Udv!

Ha nem jutsz semmire, esetleg probald forditva, a notebookrol a szerverre. Elkepzelheto, hogy ugy jo.

Toma_

[quote:53a901be8e="netchan"]Siman nem probaltad atcsovelni?

cat nagyfile | ssh masikszerver 'dd of=/ide/jon/a/file'

(esteleg gzip-pel kozben, ha jol nyomhato a file).

Az ssh alapban is tömörít, nemde? Akkor meg gyakorlatilag fölösleges a gzip...

[quote:3241bc98e8="drojid"]Az ftp szerver, amivel nem ment, proftpd volt, nem másolta se mc, se konqueror, FAT fsen 2G a max fileméret, NTFSen 8T, az scpvel az a baj, hogy iszonyú lassú (max1.3M/sec, az ftp 12M/sec), a -o lfst majd este kipróbálom.

Végül vindózt kellett bootolnom hozzá, onnan smbvel simán áttette, tehát küldő (notebook) oldalon volt a baj.

Az scp pedig tutira átviszi, úgyhogy érdemes vele próbálkozni, nem tudom, milyen géped van, de ennyire nem lassíthat a titkosítás... Ez kb egy 100 MHz-s pentium szintje, hogy csak 1.3 M/sec menjen át rajta... Mondjuk nem WinSCP-t használsz remélem, mert az tényleg lassú... :)
És az OpenSSH-val kapcsolatosan is megvan az a tapasztalat, hogy az SSH1-es protokollal lassabban működnek a dolgok, mint SSH2-n. Amúgy is egy sechole az SSH1, le kell tiltani mindenhol, jobban jársz.

[quote:5b0d5ae295="cheeky"]Ez kb egy 100 MHz-s pentium szintje, hogy csak 1.3 M/sec menjen át rajta... Mondjuk nem WinSCP-t használsz remélem, mert az tényleg lassú... :)

mindkét oldalon linux, openssh
egyik gép 566os, másik 200as. 100Mos háló. nfssel megy gyorsan, sshval 600kbyteps (!)
persze lehet, h vmi más van elszúrva, de nfssel m1 rendesen :wink:

[quote:291d422505="drojid"]Ne viccelj, 600kB az gyors?

a felkiáltójel a lassúságra vonatkozott ;-)
[quote:291d422505="drojid"]Az nfs nekem olyan 5-6MBps-sel ment, legalábbis a 2G-ig (aztán megállt)

split az nem megoldás? (feldarabolod pl 1Gs darabokra)

Udv!

En ugy hallottam, hogy a sambaban is van korlat, hogy minden verzioban, azt nem tudom, de talan a 3-ban mar opcios.

Toma_

[quote:f9624fe574="vmiklos"][quote:f9624fe574="drojid"]Ne viccelj, 600kB az gyors?

a felkiáltójel a lassúságra vonatkozott ;-)
[quote:f9624fe574="drojid"]Az nfs nekem olyan 5-6MBps-sel ment, legalábbis a 2G-ig (aztán megállt)

split az nem megoldás? (feldarabolod pl 1Gs darabokra)

Skacok, ne vicceljetek, két 1 Ghz körüli linux-os gép között 100-as switch-elt hálón 7 MB/s simán átjön, tömörítés ide vagy oda...
Most toltam át 2.2 GB-ot egy file-ban, éles adatfile, nem /dev/zero, és gond nélkül végigment az egész... 7.5 MB/s, 4 perc 57 mp, 2224 MB...

Szóval vmi egyéb gondotok lehet. Javaslom a mii-tool és az ethtool használatát, és a 100BaseTx-FD force-olását... Az autonegotiation a te ellenséged, ne használd, ha nem muszáj! ;)

Még valami: az NFS az UDP, az scp meg az ftp pedig TCP, tipikusan az UDP pont kevésbé érzékeny a fent leírt autoneg szivatásra...

[quote:7997b9de15="drojid"]
cheeky, ez az, nem viccelni akarok én, hanem másolni, de nem tudok :lol:

Hehe, akkor azért nézd meg ezt az autoneg vs. 100 Mb Full Duplex dolgot, mert nagyokat lehet szívni rajta... Ráadásul nálunk a menedzselt hálón bizonyos időnként "lenyomják" a portokat (port reset), amivel semmi gond, mert 1 mp múlva felkel az egész, és megy tovább minden hálózati kapcsolat, csak az a baj, hogy a gépek egy része erre érzékeny, és visszaáll autonegotiated 100 Mbps / Half Duplex-re, amitől aztán 300 kb/s lesz az átvitel hirtelen... : :cry:

[quote:4898e065fb="drojid"]Nem hiszem, hogy half/full duplex gond vagy ilyesmi lenne, hiszen, mint írtam, ftpn és sambán nagyon gyors, valóban 100mbit közeli.
Szorítottam helyet a filenak most ext3on, oda sikerült áthúzni, tehát nem az ntfs driver a ludas.
Ééééérdekes...

Igazad van, ezt elfelejtettem... Akkor vissza az alapproblémához: 2 GB...
Milyen kernelverziód van, milyen linux-on?

Na akkor kezdek hülyeségeket kérdezni... :twisted:

Parancssori ftp-vel próbáltad már?
Vagy smbmount után parancssorból cp-vel?

Ez az mc verzió feltűntetése arra enged következtetni, hogy abból próbálkoztál, és lehet, hogy az a ludas... :x

[quote:ca317afafc="drojid"][quote:ca317afafc="sz"]Próbaképpen csináltam dd-vel egy 2.2GB-os file-t, scp-vel, ReiserFS-ről és Debian Sarge-ról ext3-ra és Woody-ra simán ment.

Rosszul gondolom, hogy ott azért is átcsúszhatott, mert a ddvel csinált fileod jól tömöríthető volt, és közel sem kellett 2.2G-t átnyomnia?

Rosszul. Kipróbáltam dd if=/dev/urandom-mal is, működött minden további nélkül [betömörítve a file-t gzip -v9-cel, nagyobb file-t kapok, mint az eredeti volt]. 100Mbit/s hálón 5:05 volt, amíg átjött, mindeközben a fogadó oldali 1GHz Athlon [a két gép közül ez a lassabb, vmi régi féle 30GB-s vinyóval] kicsivel volt 100% terhelés alatt.
Esetleg kipróbálhatod a dolgot netcattal is, én megtettem, ugyanaz a file 4:02 alatt ért át, a lassabb gépen jóval 100% alatti terheléssel.
2.4.25 ill .26 van a két gépen.

Nyomon vagyok! :wink:
Szóval mondom először is, hogy nálam mi a konfig:
Slackware 10 minden gépen, az egyiken 2.6.7 kernel, a másikon 2.6.8-rc2
Az ftp szerver proftpd 1.2.9, az sshd OpenSSH_3.8.1p1, KDE 3.2.3
A parancssori ftp kliens tényleg sz@r, ha 2G-nál nagyobb file-t akarok putolni, akkor azt mondja, hogy not a binary file. :roll: BUGOS! Egyébként gettel is sz@r, megáll short write hibüzenettel. Úgylátszik ők leragadtak a signed int-nél. :)
Deviszont: scp egyik gépről a másikra megy. (4.7GB-os /dev/urandomból generált file-al tesztelve.) A konqueror ftp úgyszintén (egyenlőre 2.2GB-al tesztelve), továbbá nc is. A fileokat oda-vissza mozgattam cmp-ztem is, és egyeznek.
Közben olvasgattam a vsftd (ki akarom próbálni majd azt is, más okból) faq-ját és mit látok:

Q) Help! Does vsftpd support large files (>2Gb?).
A) Yes, it does.

Q) Help! Well, large file support doesn't seem to be working, then!
A1) Large file support first appeared in v1.1.0.
A2) Solaris large file support wasn't fixed until v1.2.2.
A3) FreeBSD large file support wasn't fixed until v1.2.2.
A4) The early Linux 2.6 kernels had a bug in this area - use v2.6.6 or newer.
A5) Are you sure your FTP _client_ correctly supports large files?

A szerveren valami 2.6.3-as kernelről beszéltél, na szerintem az lesz a ludas!

Kisérlet képpen megpróbáltam még az mc-t is, na az aztán egy rovartanya! :P
A lokális file méretét jól kijelzi (4700MB) a panelen. De ha felül akarom írni, akkor a target file size már rossz (körbefordul, és a maradék látszik ~620MB). Ez is érdekes... Aztán az ftp panelen a méretet 2048MB-nak jelzi. Ami viszont döbbenetes, hogy jól áthozta! (másolás után az ftp kapcsolat megszakad, bár ez egy "természetes" :D velejárója az mc ftp-nek)

Szóval a tapaszalatok idáig összesítve:
Kernel 2.6.7 jó
Kernel 2.6.8-rc2 jó
ReiserFS 3.6.11 jó
Proftpd jó
Konqueror ftp ioslave jó
scp jó
netcat jó
sima parancssoros ftp kliens rossz
mc félig meddig jó, de azért ne bízzunk meg benne

[quote:f8291e78be="XMI"]sima parancssoros ftp kliens rossz

és az ncftpvel mi a helyzet? :?

Udv!

[quote:f971180e66="XMI"]Szóval a tapaszalatok idáig összesítve:
Kernel 2.6.7 jó
Kernel 2.6.8-rc2 jó
ReiserFS 3.6.11 jó
Proftpd jó
Konqueror ftp ioslave jó
scp jó
netcat jó
sima parancssoros ftp kliens rossz
mc félig meddig jó, de azért ne bízzunk meg benne

No es a Samba?

Toma_

[quote:abe87c5738="cheeky"]
És az OpenSSH-val kapcsolatosan is megvan az a tapasztalat, hogy az SSH1-es protokollal lassabban működnek a dolgok, mint SSH2-n.

AZELLEN NEM VÉÉÉD! A sebesség nem azon múlik, hogy ssh1 vagy ssh2 hanem azon, hogy milyen titkosítási algoritmust használ. Az ssh2-ben nagyobb a választék, ez tény; de alapból azt hiszem az is 3des-re van állítva, ami a létező leglassabb algoritmus. Blowfish van az ssh1 és 2-ben is, az gyorsabb. Vagy mégjobb a cast128-cbc vagy az arcfour; ezek csak a 2-esben vannak benne. Arcfourral két 600MHz-es gép között 10,9MByte/s-el lehet scpzni azaz sarkig ki lehet hajtani a 100-as ethernetet. (Csak parancssori klienssel, a Konqueror például csak 3MB/s körül megy, mert valamiért zabálja a cpu-t)

De "Fugyulim Felszólit"! :) A blowfish és az arcfour elég gyenge titkosítások, tehát csak helyi hálóra használjuk őket! A /etc/ssh/ssh_config-ban külön hostonként tudjuk állítáni a paramétereket, így a lokális gépekre lehet használni a gyors, de gyenge algoritmust, az interneten keresztüli kapcsolatokra viszont célszerű a legerősebbet (aes256-cbc) beállítani, a netkapcsolat általában úgysem olyan gyors, hogy a titkosítás korlátozna bármit is. Egyébként még a tömörítést célszerű letiltani a helyi gépekre, de engedélyezni a távoli hostokra.

részleteket lásd: man ssh_config

[quote:ac61fb06fd="XMI"]
AZELLEN NEM VÉÉÉD! A sebesség nem azon múlik, hogy ssh1 vagy ssh2 hanem azon, hogy milyen titkosítási algoritmust használ.

Igazad van, megkövetlek, csak megszoktam, hogy két dolgot állítok át egyből egy sshd_config-ban, az első a Protocol = 2, a második a Cipher = blowfish... :) A céges háló azért alapjában véve egész megbíz6ó... Bocsánat, mea culpa, hasonlók...

[quote:93dbad7086="cheeky"]
Igazad van, megkövetlek, csak megszoktam, hogy két dolgot állítok át egyből egy sshd_config-ban, az első a Protocol = 2, a második a Cipher = blowfish... :) A céges háló azért alapjában véve egész megbíz6ó... Bocsánat, mea culpa, hasonlók...

Semmi harag! :) Csak a következőkre vigyázz, hogy a "Cipher" beállítás az ssh_configban van és az az v1-es protokollra vonatkozik, (amit te most éppen teljesen letiltasz). Az sshd_configban a man oldal szerint csak "Ciphers" van. Mindkét helyen (ssh_config- és sshd_configban) a "Ciphers" az, ami a 2-es verzió szerinti titkosításokat állítja. Feltételezem, tudod mi a különbség az ssh_config és sshd_config között, csak gondolom elírtad. Amúgy nem kukacoskodás ez részemről, csak legyen meg jól, mert esetleg olyasvalaki is olvassa, akinek ez új.

[quote:85c9855883="XMI"]
Semmi harag! :) Csak a következőkre vigyázz, hogy a "Cipher" beállítás az ssh_configban van és az az v1-es protokollra vonatkozik, (amit te most éppen teljesen letiltasz). Az sshd_configban a man oldal szerint csak "Ciphers" van. Mindkét helyen (ssh_config- és sshd_configban) a "Ciphers" az, ami a 2-es verzió szerinti titkosításokat állítja. Feltételezem, tudod mi a különbség az ssh_config és sshd_config között, csak gondolom elírtad. Amúgy nem kukacoskodás ez részemről, csak legyen meg jól, mert esetleg olyasvalaki is olvassa, akinek ez új.

No problemo, nem néztem a pontos szintaxist, mert gondoltam man-t olvasni mindenki tud, és fejből úgy látszik, nem lököm pontosan az ipart... :cry:

Lehet, hogy valami olyasmi, hogy a file pozíció típus túl kicsi.
Fordítsd le és futtasd a következő programot:
[code:1:838f440502]
#include <stdio.h>
#include <sys/types.h>

int main(void)
{
fprintf(stdout, "sizeof int: %d\n", sizeof(int));
fprintf(stdout, "sizeof long: %d\n", sizeof(long));
fprintf(stdout, "sizeof long long: %d\n", sizeof(long long));
fprintf(stdout, "sizeof fpos_t: %d\n", sizeof(fpos_t));
fprintf(stdout, "sizeof off_t: %d\n", sizeof(off_t));
exit(0);
}
[/code:1:838f440502]
kiváncsi vagyok, mert nálam is igen gyanúsak az eredmények, különösen az off_t. Ezt használja az lseek(), a stat() meg mindenféle fáljkezelő függvény. A standard c filekezelő függvények pl.: fseek() az fpos_t-t használják.
[code:1:838f440502]
sizeof int: 4
sizeof long: 4
sizeof long long: 8
sizeof fpos_t: 12
sizeof off_t: 4
[/code:1:838f440502]