Rengeteg kis file masolasa, hogyan?

UNIX haladó

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!

  • 12054 megtekintés

( bazso | 2009. 06. 27., szo – 13:16 )

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

( Fisher v | 2009. 06. 27., szo – 13:24 )

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,

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.

( traktor | 2009. 06. 27., szo – 14:30 )

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

( azbest | 2009. 06. 27., szo – 17:38 )

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

( uid_2716 | 2009. 06. 27., szo – 20:55 )

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.

( uid_18247 | 2012. 01. 17., k – 22:44 )

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

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.

( fabian-bros | 2012. 01. 18., sze – 00:03 )

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.

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.

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.

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:)

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".

( xclusiv v | 2012. 01. 18., sze – 12:41 )

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/"

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

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_cso…

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

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".