Rengeteg kis file masolasa, hogyan?

 ( zsotya | 2009. június 27., szombat - 11:56 )

Sziasztok!

Ket server kozott kellene viszonylag tetemes mennyisegu filet mozgatnom, (kb 80Gb-nyi nehany KB-os filerol van szo) probalkoztam fele ekkora mennyiseget elvinni ugy, hogy tar csomagot keszitettem, majd atmasoltam s kicsomagoltam, de a tar keszitese, majd masolas utani kicsomagolasa 4 oraba kerult.
Azt is esztevettem, hogy a tar (hiaba adtam neki a legmagasabb prioritast) csak 15%ot hasznalt el a procibol, habar a memoria teljesen ki volt hasznalva.

Valaki esetleg tud gyorsabb modszert, vagy ez ilyen.. s kikell seggelni mig megcsinalja?

Koszi elore is!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

rsync?

A fájlrendszer random I/O a lassú. Én is a tar-t javasoltam volna csak pipe-ban, de az sokat nem változtat. Milyen fs van a két oldalon? Nagyobb cache megoldhatná, de ezek általában akkor is seggelősek.

Üdv,
BaZso

+1

tar cv | socket 

ill a masik oldalon:

socket | tar xv 

Sose próbáltam, de talán működik. Mivel a gond a sok kis file megnyitása-lezárása, ezért az egész fs-t kéne vinni, pl. dd-vel:

dd if=/dev/egyikdisk of=/dev/masikdisk

Persze ez csak akkkor jó, ha nem akarsz fájlrendszert módosítani, és a második disk nem kisebb mint az első. LVM rulez. Ha két gép között kell áttolni, akkor google("netcat examples");

Sajnos csak filek mozgatasara lenne szukseg, ext2 van mind ket oldalon, most nyalazgatom az rsync leirasat, meglatjuk mikre jutok vele.

Koszonom a segitsegeteket!

> Sajnos csak filek mozgatasara lenne szukseg,

jó, de egyszer vagy sokszor kell a fájlokat másolni? Ha egyszer, akkor kivárod és kész. Ha sokszor, akkor milyen adatokról van szó? Sűrűn vagy ritkán változó; sokat vagy keveset változó? A jó megoldás nyilván az, ami a lehető legtöbb információt használja ki az adatok természetéről.

Vagy a dump - ext2/3 filesystem backup

Ugye ugy tarolsz, hogy csak a legutobbi masolas ota valtozott file-okat viszed at? Vagy minden ciklusban mind a 80G megvaltozik?

bár nem teljesen az amit kérdel, de hátha segít mégis
egy win-es gép hasznos fájlait kellett lementenem hálózaton át, majd újratelepítés után visszatölteni. Egy ubuntu 8.10 live cd-ről vittem végbe (9.04-nek problémája volt a particio becsatolásával). Az idő nagy részében vitte a 100 mbites lan sebességét, de volt hogy belassult, gigás kapcsolattal gondolom hamarabb végzett volna.

így mentettem
ftp 192.168.1.101 21
binary
put |"tar -cvlO *" full_backup.tar

és így jött vissza:
ftp 192.168.1.101 21
binary
get full_backup.tar "| tar xvpf -"

Ohh jó hogy előkerült ez a téma, mert most látom hogy a 73 gigás tar még mindig itt csücsült a gépemen :D

Ahogy mások is írták, ne készíts külön tar állományokat, hanem a becsomagoló tar kimenetét hálózaton átküldve rögtön kösd a kicsomagoló tar bemenetébe.

A forrás- (becsomagoló) oldalon még próbálkozhatsz azzal (ez már az n+1-edik alkalom, hogy ezt leírom a hup-on; lassan szégyellem magam érte), hogy nem sima rekurzív tart csinálsz, a fa gyökerén elindítva a tar-t, hanem előtte GNU find-dal készítesz egy file listát, a -printf kimeneti kapcsolóval a sor elejére kiírod az inode számot is, inode szám szerint (numerikusan) rendezed, levágod a számokat, majd az így rendezett file-listát adod meg a tar-nak --no-recursion ill. --files-from kapcsolóval. Segíthet még az is, ha előtte egy jó alacsony értékre beállítod a vfs_cache_pressure sysctl-t. A kettő hatására együttesen a tar futásakor a directory blokkoknak már mind memóriában kellene lenniük, illetve a megnyitott file-oknak a diszken közel fizikai elhelyezkedés szerinti sorrendben kellene következniük. Vagyis minimalizálná a fejrángatást.

tar | nc <> nc | tar
___
info

Van 118000- fájlom, 1KB-3.3GB mérettartományban, összességében 440+GB. két külső vinyó között kellene mozgatnom, mindkettő ntfs.

for i in `ls`; do mv $i /foo/bar; done

nem ad hibát, de az iotop masszívan nullát mutat. aztán megugrik, majd elkezdi ontani, hogy a fájlok stat értéke nem jó. (mv: stat "2.pdf" sikertelen: Nincs ilyen fájl vagy könyvtár). átment kb 30 fájl.

eltekintve attól, hogy rsyncet használna épelméjű ember, miért kapok ilyen hibát?

SZERK: rsyncnek túl hosszú az argumentumlista. minden fájl bele van okádva a fájlrendszer root-ba. mi a leghatékonyabb megoldás rá? ls látja az összes fájlt.

Ez a for i in `ls` szerintem több oknál fogva rossz ötlet. Az egyik az, hogy ha szóköz van a file nevében, az széthullik a szóköz mentén, s olyan file-ra történik hivatkozás, ami nem létezik. A másik dolog, hogy a shell helyettesíti az egész listát, s nem tudom, van-e limit erre, de mindenképpen sok memória. Akkor inkább:

ls -f1 |\
while read; do
[ x"${REPLY:0:1}" = x'.' ] && continue
mv "$REPLY" /foo/bar
done


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

öhö. leginkább a rsynces megoldás érdekelne, dd nem játszik. azért köszönöm!

Az rsync miért is nem jó? Lehet neki paraméterként könyvtárat mondani, akkor azt rekurzívan átmásolja...

nekem jó az rsync, sőt, valszeg az a legértelmesebb, csak az argumentumlistára azt mondja, túl nagy. directoryk nincsenek, mind a 118000 fájl egyetlen könyvtárban van.

Ahh... najó: rsync -r . /ahova/jolesik/

beszarok, működik. eszerint rekurzív működés esetén nem generál magának fájllistát?

A for i in `ls`; esetén az ls-t először kibontotta a shell, és az eredményét pakolta bele a for-nak argumentumokként.

A fentebb említett rsync sor esetén nincs semmilyen wildcard amit a shell kibonthatna az rsync indítása előtt

Egyébként, ha mv-t akarsz, akkor az rsyncnek kellhet még egy --remove-source-files is...

Nehem, hanem az éteri zajokból szűri ki milyen fájlokat kell másolnia....

De komolyan: dehogynem, hiszen másképp honnét tudná a szerencsétlen, hogy mi merre hány méter. A kutya ott van elásva, hogy az "rsync *" parancsot a shell kibontja, a csillagot behelyettesíti és lesz belőle rsync és-a-sok-sok-file-neve-mind-felsorolva-egymás-után. Ez utóbbi listának van egy - elég nagy - limitje, amit ezek szerint átléptél. A . viszont egy karakter, az aktuális könyvtárat jelöli, és -r kapcsolóval mindent ami benne van, azzal meg eljátszik majd az rsync ahogy akar. És lőn öröm és boldogság.

köszönöm ezt is és az előzőt is! a * vs . nem esett le sokadjára sem, mostmár bezzeg nyilvánvaló :(

Áh, utólag minden sokkal egyszerűbb :D

Erre céloztam, bár lehet hogy kissé szűkszavúan: http://hup.hu/node/72761?comments_per_page=9999#comment-1405983

Ilyenkor figyelni kell, hogy a whitespace-ekkel (vagy csak szóköz? fáradt vagyok kipróbálni) kezdődő sorokat a read "elrontja", ezért nem árt az IFS-t átállítani \n-re majd vissza. Bár ez elég ritka eset, de amikor mégis, akkor ember legyen aki megtalálja.

Es, ha '\n' van a fajlnevben? :P (Igen, lehet... Ext4-en biztosan mukodik, de lehet, hogy nem minden mas FS is tamogatja)
---
Internet Memetikai Tanszék

Igen, az különösen problémás. Ezért is szoktam le az ls-ről, helyette a find-et szoktam használni. Persze ez a gond ott is előjönne, hacsak nem fájlonként, exec-el van feldolgozva a filenév.

... én meg rég leszoktam ilyen helyzetekben a shell scriptekről.

Pont ugyanannyi karakter perlben, csak mondjuk nincs ez a végtelen mennyiségű szopás az idézőjelezgetésekkel, escape-elésekkel, meg a többi ilyen hülyeséggel. Szerintem.

.?

cd regi
pax -rw . uj
cd /
rm -rf regi

Lehet, hogy már írták, de a for in `ls`; a szóközöket tartalmazó file-neveket tudtommal két külön file-ként szeretné bejárni.

Meglehet, hogy írták. ;) Miért éppen két külön file-ként? Az ugye attól függ, hány szóköz van a névben, és hol. Lehet az 7 is.


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Igen, igazad van. Rosszul fogalmaztam.

Fentieket összefoglalva:
a következő a problémám: át kéne pár dobozt szállítani az egyik raktárunkból a másikba. 1 kamionunk van, végsebessége 80km/h. Kit vegyek fel sofőrnek,hogy gyorsabban menjen a kamion?

Magyarul: a mostani processzorok sokkal gyorsabban dolgoznak az adatokon, mint ahogy a vinyók írni vagy olvasni tudnák őket.

szóval hogy lehet gyorsítani ezt?
—vannak fájlrendszerek, amik alkalmasabbak ilyesmire, mint ahogy már fentebb rávilágítottak (cache)
—ha többszöri másolásról van szó (backup), tényleg érdemes csak azt másolni, ami változott (valami verziókövető, vagy RAID megoldás)
—for / ls / find stb… megoldásokat felejtsd el. ezek arra vannak, ha _nem az összeset_ akarod másolni, hanem egy részhalmazát. akkor is a find-ot javaslom a -print0 kapcsolóval (mint ahogy erre szintén rávilágítottak fentebb)
—amúgy meg tényleg vagy nc-vel átpumpálod, vagy felmountolod az másik gép vinyóját (UNIX wuhúúú¹) és simán átmásolod, ahogy bármilyen másik élethelyzetben tennéd.

[1] de tényleg. ahhoz képest, hogy ez egy unix fórum, az esetek 90%-ában olyan kacifántos megoldásokat látok, hogy sírni tudnék.

--------------------------------------
Unix isn't dead. It just smells funny.

két és fél éves az eredeti topic, amire most válaszoltál... :)

Ohh bakter! Késő van, én meg beteg vagyok. Nembaj. Itt marad az utókornak, hátha valaki okul belőle.

--------------------------------------
Unix isn't dead. It just smells funny.

Alighanem így születnek a kacifántos megoldások :D

Lehet benne valami.

Mivel ez elég gyakran megtörténik, nem csak velem (felkúszik egy régi topic és valaki lelkesen elkezd hozzászólni) ezért javasolnék egy olyat, hogy ugyanúgy, ahogy az új hozzászólásoknak más a háttérszínük, az egy évnél régebbieknek is legyen picit más. @trey #feature-request #hup (tudom hogy ez nem működik)

--------------------------------------
Unix isn't dead. It just smells funny.

Sohasem értettem, miért érzik néhányan problémának azt, hogy egy régi topic-ban folytatódik az ötletelés. Nekem meg kellene tagadnom a 3 éves múltamat?


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Engem is bosszant. Marmint ha ujraeled egy topic. Epp az elobb irtam bele en is ebbe. Egyreszt azt hiszed, hogy segitettel valakinek, de az mar reg nem olvassa ezt a szalat. Aztan a masik mod szokott az lenni, hogy valaki egy ilyen topicban kerdez "mert mar ugyis van egy", amivel valojaban egy tok uj szalat nyit, zavaroan sok, oda nem kello commenttel.

es mi lenne, ha az a topic amihez tobb mint 1 eve nem szolt hozza senki, az read only-va valna inkabb? Na, igen, lehet hogy ez egy durvabb feature request. ;)

ezért javasolnék egy olyat, hogy ugyanúgy, ahogy az új hozzászólásoknak más a háttérszínük

nálam nem, és még sosem láttam ilyet. Ez mitől függ? Valami eldugott opció?

A téma adott. Időközben új megoldásokkal gyarapodhat a téma. Miért baj ez?
Ha nem éledne fel, írjunk ugyanilyen témára másik topikot? Minek?
Elég zavaró így is a szétforgácsolódás.
Van egy téma, évek után is aktuális lehet_másnak_.

mod: fura, neked szántam, de most már marad:)

Huppert használsz? Az megöli ezt a featuret.

Huphoz van 2 kiegeszito is. Az egyiket Ajnasz irta (Hupper extension), a masikat mar nemtom ki (en nem az ovet hasznalom).
Utobbi tud ilyet, de volt valami bugja (osszeakadt a Hupperrel), ezert leszedtem.
Mindkettoben van trollszuro, van "kovetkezo/elozo uj komment" link, meg par hasonlo.

--
Yesterday I set my wifi's name to "Hack this if you can".
When I checked it today, it was called "Challenge accepted".

Ha már felhoztátok, hátha jó lesz ez is valakinek :)

tar -cf - ./ez_a_konyvtar_benne_sok_file | ssh user@masikgep "tar -xf - -C /ide_tegyed/"

Hátha jó lesz "Why is cpio better than tar?":
http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html

Kösz, jó tudni, bookmarked. De
1. nincs benne hardlink
2. filename limit nem érint
3. timestamp nem érdekel
4. mindent akarok másolni (archiválok)
5. egy szál pont elég

biztos lehetne még jobban komplikálni is, de ha már ssh:
scp -r ./ez_a_konyvtar_benne_sok_file user@masikgep:/ide_tegyed/

:) The manual said the program requires Windows 95 or better, so I installed Linux

Ez sok kis file eseten nagyon nem lesz hatekony.

--
Yesterday I set my wifi's name to "Hack this if you can".
When I checked it today, it was called "Challenge accepted".

lehet, de a hatékonyság fura dolog, pl. gagyi kapcsolaton az a hatékony, ami megbízható, újrakezdhető, mint az előbbi példának az rsync-es változata:

rsync -a ./ez_a_konyvtar_benne_sok_file user@masikgep:/ide_tegyed

amúgy csak xclusiv "Ha már felhoztátok, hátha jó lesz ez is valakinek :)" gondolatát folytattam...

:) The manual said the program requires Windows 95 or better, so I installed Linux

hja, de a gagyi kapcsolatot le kell cserélni stabilra, már folytatva a gondolatomat :)

Most rohadtul indiszkrét leszek: Te hol élsz?
Nem mindenki született jó helyre, nem mindenki lakik néhány kivételezett belvárosban, nem mindenki dúskálhat digi, upc, stb. szuperakciós szupergyors szuperolcsó kínálataiban, és váltogathatja az isp-ket, mint más a gatyát.
Láttam már reklámot gyorsabb mobilnetről, mint az én adsl-em, és gyorsabb kábelnetről, mint sok helyen a lan, és "...sajnálom, hogy nincs isten, ki gondoljon kínomra, és azok szemét ujjával kinyomja...". /József Attila/
http://hup.hu/promo/20110131/upc_business_fiber_power_business_plus_csomagok_kis_es_kozepvallalkozasoknak#comment-1214449

:) The manual said the program requires Windows 95 or better, so I installed Linux

Smiley volt a mondat végén, nem véletlenül.

figyelemetlen voltam, elnézést

akkor most igyekszem finom és nőies lenni; tehát a lényeg:
sokan vagyunk, akiknek ennek az istennek az idejében nem lesz olyan internet előfizetésük, amit a reklámokban látnak, azaz esélyük sincs, hogy ki tudják használni a tar|ssh előnyeit; egyébként legyen bármilyen szuper net, lan, usb: sok giga másolása bármi miatt lerohadhat, és akkor mivel folytatod? rsync, ha nem akarod nulláról újrakezdeni

:) The manual said the program requires Windows 95 or better, so I installed Linux

Tippre amugy ebben az esetben is jobb az a megoldas, hogy find-olsz, inode szerint rendezed, ezt a filelistat beleteszed helyben vmi file-ba, ez alapjan feldarabolod a masolandot, es igy kuldod at tar|ssh "tar"-ral..
Elonye: ha szakad, akkor nem kell teljesen elolrol kezdeni, eleg az adott darabot. SCP-vel minden egyes file-nal kulon-kulon kapcsolodik, ami sok kis file eseten nagyon lassu. Esetleg ha az rsync-el is meg lehet etetni filelistat (--files-from=FILE), es garantalhato, hogy a sorrend marad, akkor az meg lehet egy jo megoldas.

--
Yesterday I set my wifi's name to "Hack this if you can".
When I checked it today, it was called "Challenge accepted".

xclusiv-nak már belemásztam a lelkivilágába, nem akarlak téged is megsérteni, nem kérem tőled, hogy tedd fel ide ezt a script-et, de egy ilyen script-ről szóló topic-ra befizetnék

:) The manual said the program requires Windows 95 or better, so I installed Linux

az én lelkivilágomba? ugyanmár, szó nincs róla.

scp -r ./ez_a_konyvtar_benne_sok_file user@masikgep:/ide_tegyed/

igen, ennél sokkal gyorsabb, amit írtam. 130k darab file szumma 11g méret körül érezhetően gyorsabb, bár a mérési eredmények nem tudom hol vannak. Hidd el, nem az életemet akartam bonyolítani :)

+1

en meg egy tomoritest beleraknek (-z), meg a -f felesleges, anelkul is pont stdout-ra nyomja:

tar -cz ./ez_a_konyvtar_benne_sok_file | ssh user@masikgep "tar -x -C /ide_tegyed/"

ahh, nem vettem eszre, hogy 2009-es a topic... pedig akkor is irtam bele :)

szarni bele, gyűlik az okosság az a lényeg. Egyszer valaki kezet fog érte csókolni :)

ez csak egy forum. Az okossagot rendszerezetten kell gyujteni, mint pl a http://wiki.hup.hu Annyi info van a vilagon, hogy abban mar nehez megtalalni az igazit. ;) Kell egy kis renszer is, ez meg itt nem az.

tömörítés nálam nem játszik, küldő gép olyan régi hogy előre köszönök neki, köztünk meg gigás link van. Illetve alapban tömörített anyagot küldök át. De egyébként hasznos, a -f rész pláne

subs

ide esetleg meg egy "-o compression=no -c arcfour" is elkellhet az sshnak.....

+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/