abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
včera 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 1
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 26
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (23%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 788 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Pohádka o rsyncu a deseti milionech souborů.

16.10.2012 10:11 OgeeN
Pohádka o rsyncu a deseti milionech souborů.
Přečteno: 3295×
Ahoj, žila byla jedna farma webových serverů. A ta farma servírovala spolehlivě data několik dlouhých let. Jak šel čas, množství dat rostlo a bobtnalo, až jednoho dne nabyla objemu cca 200GB v cca 10 milionech drobných souborů. No a adminovi začaly šedivět vlasy ...

Tolik k pohádkovému úvodu. :)

Potřebuji poradit, jak takové množství dat efektivně přenášet a synchronizovat na záložní svazek.

Rsync spuštěný s parametry -ropgt --numeric-ids --delete-during --archive --timeout=30 --delete-excluded trvá nad takovým množstvím dat cca 8 hodin. A to je příliš douho pro naše potřeby.

Existuje nějaký způsob jak přenést soubor na druhý svazek okamžitě po změně jeho obsahu?

Případně, je možné nějak zaznamenávat změněné soubory do textového souboru a ten pak v pravidelných intervalech předhazovat rsyncu? Jde mi o to, jak se zbavit času, který rsync stráví tím, že musí zkontrolovat u deseti milionů souborů zkontrolovat, zda se změnily.

Díky za nasměrování.

Odpovědi

16.10.2012 10:18 drunkezz | skóre: 32 | blog: kadeco
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.

mozno findom a roznymi atime ctime mtime  najst to co potrebujes a to syncnut..ale to je len cisty vystrel do tmy.

ale tu by sa mozno uz oplatilo postavit tu webfarmu nad sharovanym storidzom

D.

16.10.2012 10:29 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Na přechodu na sdílené úložiště se právě pracuje. Ale i tam potřebujeme mít data na dvou samostatných svazcích a ony svazky mezi sebou synchronizovat.
16.10.2012 10:46 drunkezz | skóre: 32 | blog: kadeco
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
mozem vediet dovod preco na dvoch? D.
16.10.2012 11:20 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Na jednom svazku (říkejme mu READ) jsou data, ze kterých čtou webové servery. Na druhém svazku (EDIT) jsou data, nad kterými pracují editoři a programátoři. Po dokončení úprav a jejich verifikaci, jsou změněné soubory přeneseny na svazek READ a servírovány uživatelům. Pak

Jde tedy o to, aby někdo na svazku READ, který je viditelný v internetu, neprovedl nějakou úpravu, která by vedla třeba k chybnému zobrazení stránky.
16.10.2012 10:53 Jirka
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
pokud jde o okamžité přenesení souboru po změně, tak to už potom můžete rovnou použít raid1, nebo něco jako drbd ? a jestli lze průběžně zaznamenávat změnivší se soubory, tak to by mě teda taky zajímalo:)
16.10.2012 11:25 chochi | skóre: 29 | Praha
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Zalezi jak je struktura a co chces sledovat. Pokud jsou soubory jen v par adresarich (maximalne stovky, ci tisece) a staci sledovat vytvoreni noveho souboru, smazani a zmenu obsahu (neni tam zadne prejmenovavani, nebo vytavareni adresaru - to by situaci zkomplikovalo), tak by se dalo jednoduse pouzit inotifywait, ktery rekne jake soubory se zmenily. Priklad:
$ inotifywait -m -e close_write -e delete .
Setting up watches.
Watches established.
./ CLOSE_WRITE,CLOSE cc
./ CLOSE_WRITE,CLOSE cc
./ DELETE cc
Z toho pak to vyextrahovat a zkopirovat. Pokud hrozi vytavareni adreasaru, tak to lze, ale asi to chces nejaky skript nad inotify.
16.10.2012 11:27 Stanislav Petr | skóre: 27 | Praha
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Neni co resit - http://gluster.org
No jo... Co bych cekal od systemu, kterej se vypina tlacitkem start... http://glux.org
16.10.2012 12:15 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tohle nám asi nepomůže. Na sdíleném úložišti je už použitý filesystém OCFS2. Ke svazku na sdíleném úložišti totiž přistupuje najednou deset různých fyzických serverů. Pokud tedy GFS neumí fungovat nad OCFS2.
16.10.2012 12:34 Ivan
Rozbalit Rozbalit vše OT: Re: Pohádka o rsyncu a deseti milionech souborů.
Asi je to offtopic, ale existuji i jine nastroje na zalohovani nez rsync. Napr. nektere FS podporuji binarni inkrementalni zalohy. Popr. TSM (komercni produkt) ma demona, ktery pres inotofy prijima informace i zmenach souboru a uklada si je do zurnalu. Inkrementalni zaloha pak "pouze" prochazi tenhle zurnal. Pri tomhle objemu bych zkusil neco co pouziva inotify.

PS: Jak moc stabilni je OCFS2 pri tomhle objemu dat? Kdyz jsem to naposledy testoval tak to nebylo nic moc.
16.10.2012 12:39 OgeeN
Rozbalit Rozbalit vše Re: OT: Re: Pohádka o rsyncu a deseti milionech souborů.
Něco takového právě asi hledám. Průběžně vytvářet žurnál a tenhle žurnál třeba jednou za minutu předhodit rsyncu. Něco takového by nám asi stačilo.

Zatím to máme k diskovému poli připojené tři servery v testovacím provozu. Ještě jsme na to nepustily, žádný větší provoz, takže zatím nedokážu odpovědět.

Od vyladění nastavení se to zatím chová stabilně.
Josef Kufner avatar 16.10.2012 12:50 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Můžeš zkusit incron. Ale ten rsync bych tam stejně čas od času spustil (každou neděli?).
Hello world ! Segmentation fault (core dumped)
16.10.2012 13:15 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
To vypadá dobře. Díky za tip.

Zatím testuji toto: http://code.google.com/p/lsyncd/

a další kandidát je zde: http://code.google.com/p/rsync-inotify/
18.10.2012 20:58 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tak bohužel mi asi nepomůže nic založeného nad inotify. Potřebuji hlídat příliš mnoho adresářů. Jen spuštění lsyncu nad všemi adresáři vy trvalo několik hodin.
19.10.2012 06:21 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Uz jsem to tady psal, ale proc proste nezkusis find + cp, je to dvouradkovy skript. neco jako:
find source_dir  -type d -exec mkdir -p '{}' /dest_dir/'{}' \;
find source_dir  -type f -cmin -1440 -exec cp -v '{}' /dest_dir/'{}' \;
Samozrejmne si budes muset pohrat s cestou k source a dest adresari, aby se vse kopirovalo do spravnych adresaru, ale na 99,9% nic rychlejsiho nenajdes(pro spoustu malych souboru).

19.10.2012 11:15 camel1cz | skóre: 23
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Rychlost find a rsync bude řádově srovnatelná - teda pokud bude ten find napsaný optimálně a ne jako to co uvádíte. rsync na jehož nedostatečnou rychlost si tazatel stěžuje tráví 99,99% jalové práce na procházení souborů a testování existence/aktuálnosti souborů - vy jste to akorát rozepsal na 2 příkazy, kde oba obsahují většinu režie původního rsync - podle mého názoru to bude tak o 250% pomalejší než původní řešení.
19.10.2012 11:59 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ach jo, to co tady pisu mam z praxe a rsync je pro velke mnozstvi malych souboru zoufale pomaly. Proc to opravdu nevim, ale je to tak ze i s parametrem -w se rychlosti find+cp ani nepriblizi.

To ze mam na konci find strednik a ne plus je take vyzkouseno jako nejrychlejsi moznost. Testoval jsem to asi na 7M souborech, naprosta vetsina mela mezi 10 a 100KB a denne se zmenilo kolem 5% souboru. Netusim proc ale typnul bych si ze to bude mit neco spolecneho s diskovou cache. Kopirovani jednotlivych malych souboru, ktere od sebe oddeluje relativne dlouhy cas hledani pomoci find funguje nejspise lepe nez davkove kopirovani stovek MB dat najednou, ale to opravdu jen hadam.
19.10.2012 19:24 camel1cz | skóre: 23
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tak to se omlouvám!

Možná blbý dotaz, ale máte namoutěno s noatime?

Ze zvědavosti: máte někdo teorii, na čem tráví rsync tolik času? ten find přece také udělá stat každého souboru, což považuju za nedražší (a navíc 2x - kvůli adresářům a pak kvůli souborům). A ten protokol výměny seznamu souborů a jeho procházení přece nemůže být tak extrémně pomalý?
20.10.2012 18:48 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Netusim proc ale typnul bych si ze to bude mit neco spolecneho s diskovou cache.

Udeřil jste hlavičku na hřebíček, jednoznačně.

Je rychlejší F1 nebo T60? Mám-li dojet z Prahy do Brna (všichni znají stav D1), volím jednoznačně tank, protože ten bude v Brně rádově rychleji než monopost F1. F1 se kus za prahou rozpadne, možná i havaruje, a než ho dáte dohromady, jste v Brně dávno tankem. Výsledek - tank je jednoznačně rychlejší než formule.

Konkrétně v našem případě, find je samozřejmě z principu řádově pomalejší, navíc když ho tak neoptimálně pouštíte (10 000 000 procesů cp mluví za vše). Ale chápu, že to děláte s ohledem na stav vašeho OS (D1), který má zjevně nějaký výkonnostní problém a nedokáže vyhovět požadavkům rsync při práci s IO.

Pokud by se ovšem podařilo najít ten výkonnostní problém, tedy opravit D1, budete samozřejmě rychlejší s rsync, který během kopírování žádnou jalovou práci nedělá a nezaměstnává procesor zbytečnostmi, které ovšem na rozbitém systému umožní jakž takž kopírovat. Ten výkonnostní problém jsem také dlouho míval, ale s novým jádrem a aktualizacemi díky bohu nějak vymizel, byl to opravdu osten v p...
bash$ time $(find source_dir -type d -exec mkdir -p '{}' dest_dir/'{}' \; ; find source_dir -type f -cmin -1440 -exec cp '{}' dest_dir/'{}' \;)

real    8m11.393s
user    0m4.963s
sys     2m21.717s

bash$ time rsync -a source_dir dest_dir/

real    0m11.774s
user    0m1.600s
sys     0m11.933s
Je docela zoufalé, že na rozbitém systému se musí při kopírování většího množství dat vkládat různé cykly typu "find" a "verbose", ale je jasné že dokud systém nebude opraven, je to způsob, jak to alespoň jakž takž pomalu ale jistě překopírovat, aniž by se to cestou rozbilo.

Jinak samozřejmě optimální by bylo odstranit problém a použít rsync.
20.10.2012 18:58 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Omlouvám se za tu analogii, ale celkem bych se přimlouval za to, že když někdo argumentuje že 10000000 x find je rychlejší než 1 x rsync, že vlastně tvrdí, že tank je rychlejší než formule. V praxi to samozřejmě může být pravda, ale používalo by se spíš slov jako "efektivnější" nebo "výhodnější", protože slovo "rychlejší" v tom kontextu zní prostě hloupě, a to se týká jak tanku tak findu. Takže bych se přimlouval za zdůraznění okolností, jako "daný systém má problém s efektivním kopírováním" či "dálnice je rozbitá" a podobně, aby to "rychlejší" tak hloupě neznělo :)
20.10.2012 19:30 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Hezky, ale zcela nerealny vysledek. Za 11 vterin neprojde milion souboru ani ls. Nebylo by mozne dat sem take statistiku z rsync(--stats), kde by bylo videt kolik souboru bylo kopirovano a jak moc se uplatnil diff. Typuji ze jde o par tisic souboru, ktere jsou relativne velke, tady se samozrejme projevy vyhoda diferencialniho kopirovani.

ps. pokud mam system na kterem bez problemu spustim 10000000 procesu cp a porad je rychly, svedci to spise o perfektnim vyladeni nez o vykonostnim problemu ;-)

21.10.2012 04:48 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Výsledek je reálný pro 100000 malých souborů, pro milion násobte deseti, není tam žádný výkonnostní "skok" či zub.

Pokud máte i systém, kde bez problémů spustíte 10000000 procesů cp a pořád je rychlý, tak to je dobré, ale to je asi zcela jiný případ, než jste tu uvedl :) Ten váš problém s rsync opravdu světdčí o výkonnostním problému.
21.10.2012 20:17 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tem vykonostni skok tam prave je, nebo alespon jeste pred pul rokem byl. Jakmile se dostanete pres nejakou magickou hranici zacne byt rsync nesnesitelne pomaly. Navic nevim co porad mate s tim 10M procesu. Na serveru mam kolem 7M souboru a z nich se denne zmeni kolem 3-5%, to znamena kopirovat asi 300000 souboru. Kdyz si vezmu ze kopirovani bezi 3.5 hodiny je to neco kolem 23 kopirovanych souboru za vterinu. Pro system s diskovym polem pripojenym pres SAN zadny problem. Rsync to nestihne za 6 hodin.
21.10.2012 21:14 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
To vy jste si začal s 10M procesy :D

Ten váš příkaz find ... -exec cp dělá to, že pro každý nalezený soubor, spustí extra proces cp. Nemusí jich být 10M, ale bude prostě pro každý soubor jeden, a vytváření procesů je v linuxu prostě drahé a v tomto případě hlavně zbytečné. Chápte? Každý jeden modifikovaný soubor vezmete, vytvoříte pro něj proces cp, který ho zkopíruje, a zase zanikne. Neskutečné plýtvání. Pokud vám 2,5h stačí a zátěž stroje a účty za elektriku vás netrápí, budiž, ale musí to jít i efektivněji, pomocí rsync (ok, tam říkáte že je probl.), nebo tar, nebo lépe použít cp (ten také umí kopírovat víc než jeden soubor na jedno spuštění.
Heron avatar 22.10.2012 10:12 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
vytváření procesů je v linuxu prostě drahé

Od kdy?

27.10.2012 07:00 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Odjakživa.
pavlix avatar 27.10.2012 11:22 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Vytváření procesů je v linuxu prostě levné.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
Josef Kufner avatar 29.10.2012 00:15 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Je to levné ve srovnání s ostatními operačními systémy, ale v absolutních číslech to až tak levné není. Proč bysme jinak měli FastCGI a xargs?
Hello world ! Segmentation fault (core dumped)
22.10.2012 15:26 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
vytvoření procesu je drahé pouze v kontextu operací procesoru. V kontextu operací s diskem, kdy seek time mám někde něco málo pod 10ms jsou nějaké mikrosekundy ztracené pro vytvoření procesu nepodstatné. Podstatné bude, co dělá fyzicky s diskem find / cp a co dělá rsync. Víte jistě, jak rsync interně pracuje. Pokud rsync sáhne na všech 7M souborů i když by nemusel, tak je to čas asi 10 hodin v seek time (tak špatně to asi nebude). Pokud na těch 300 000 sáhne o jednou více než cp (třeba proto, že tam může být nějaký sync pro cache, aby měl skutečně data, co jsou na disku) tak je to cca 50 minut jen na ten seek. V podstatě na žádném rotačním disku se nedá dostat moc výš než 100-150 IOPS. To jsou základní operace, tedy i čtení inode.

Možná že by se tazateli dalo najít úzké místo pomocí atop, iotop nebo pomocí technik Extreme Linux Performance Monitoring
22.10.2012 18:20 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.

Vytvoreni 1 milionu procesu, ktere hned skonci, v ramci jednoducheho c programu mi trvalo na X5650 @ 2.67GHz cca 45vterin tj. 45 microsekund na proces. Tj. rezie jen samotneho zalozeni/ukonceni 10mil. procesu je neco jako 8min.

To, co presne dela rsync se soubory jsem popsal nize, jde to videt v strace. Dela tech operaci vice, ale taky dava daleko vice zaruk nez jednoduchy cp. Zadne sync() rsync nevola. Find zase pochopitelne na kazdy soubor musi zavolat stat() [realne vola newfstatat()].

Jinak se to tady uz objevilo vicekrat, reaguji zde - inody na disku nejsou rozesety nahodne, ale jsou vzdy zdruzovane po skupinach, ktere nejsou zrovna male. Muj ext4 rika "8192" Inodes per group. Takze ty vypocety ohledne seeku je nutne brat s rezervou, zvlast kdyz se jedna o cteni pristupy, kde prvni cteni pravdepodobne natahne do pameti vsechny inody z dane skupiny.

27.10.2012 07:06 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Nepodstatné jsou možná tak pro vás :) Ale chápu, máte rychlý procesor, takže spustit zbytečně desetimilionkrát nějaký program, proč ne, alespoň se procesor nefláká a uživatel si počká, může si přece udělat kávu a protáhnout se, takže ve výsledku je to vlastně zdraví prospěšné. Argumentovat se dá opravdu všeliak.
28.10.2012 19:06 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jen dalsi cisla: na serveru s dvema procesory X5650 (celkem 12 coru) 10milionkrat spusteni "cp --version" pres execve() volani neco jako 10.5 minuty a system na 50% vytizen na CPU. Na mem ntb s i5 to same trva 39.5 minuty (extrapolace). Takze levne to opravdu neni.
28.10.2012 23:56 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Díky za čísla. Já ale neříkal, že vytvoření procesu nestojí nic. Napsal jsem že v kontextu procesorových operací je vytvoření procesu drahé. Podle vašich čísel je tedy na i5 procesoru cca 4 min na 1 milion procesů tedy 240 micro sec na vytvoření procesu, pokud dělím dobře. Ta vaše i5 má tak 2-3GHz procesor což tedy dává cca 500 000 hodinových cyklů na vytvoření procesu. To je tedy drahé hodně (čekal jsem tak náročnost 10-50 000 cyklů), ale pořád vzhledem k cca 10ms seeku na hledání pro jeden soubor je to hodnota o 2 řády méně. Takže podstatné je, co ten jeden nebo druhý způsob dělá z disky.
Josef Kufner avatar 29.10.2012 00:06 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Těch seeků tam bude víc, kvůli linkování dynamických knihoven. Ale to se týká jen prvního spuštění, pak už by to mělo jít z cache. Pořád to ale je něco počítání a hromada přepínání kontextu (jádro/userspace) a tam už se to trošku nasčítá.
Hello world ! Segmentation fault (core dumped)
29.10.2012 14:43 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Vetsina knihoven uz je davno mmapnuta, navic jich je tak malo, ze bych to vubec neresil.
AraxoN avatar 19.10.2012 17:56 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Je to tak ako píše linuxik - teoreticky by rsync mal robiť to isté, ale prakticky je find rádovo rýchlejší. Ja som tiež používal rsync, ale ako narastalo množstvo dát, doba jedného behu rsync sa stále predlžovala, až sa stal nepoužiteľným. Vtedy som to prepísal na find (+tar +ssh, ako spomínam v inom príspevku tu v diskusii) a opäť som vysmiaty.
A fine is a tax for doing wrong. A tax is a fine for doing well.
29.10.2012 13:45 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.

Tak jsem si s tim inotify trochu pohral. Primarne mi slo o to, zda inotify lze/nelze pouzit pro miliony souboru. Vzal jsem zdrojak "inotify-tools", konkretne inotifywatch. Upravil jsem ho, aby pri volbe "-r" navesil sondy i na soubory a aby nevolal zbytecne stat() na kazdy soubor, coz predtim delal.

Pri cold cachi trvala inicializace na 1002524 souborech 55 vterin na SSD disku s ext4 a i5 procesoru. S hot cachi trvala inicializace 7.5 vteriny. Spotreba pameti pak byla na urovni ~280MiB.

Spotreba pameti by se dala navic hodne snizit vhodnym ukladanim jmen souboru - tato verze uklada cele jmeno bez vyuziti komprese stejnych prefixu apod.

Takze bych system inotify uplne nezatracoval, ale je potreba jej pouzivat "spravne". Vsechny inotify sw, ktery umi rekurzivne poslouchat, ktere jsem videl, maji z pohledu vykonu co dohanet.

29.10.2012 14:00 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Mohl byste poslat seznam změn, které jste ve zdrojácích provedl?
29.10.2012 17:01 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Hodil jsem diff -ru na pastebin: http://pastebin.com/FXvCEA56 . Neni to zrovna neco, co by se takto dalo poslat vyvojarum, ale pro inspiraci by mohlo stacit. Cela myslenka je v tom, ze neni nutne volat fstat() na filesystemech, kde je typ souboru jiz v informacich v adresari. Plus teda volani add_watch i na regularni soubory.
29.10.2012 14:26 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Nebude to zlobit na starších jádrech? nějak mí zvoní v hlavě vzpomínka, že byl změněno „něco“, co dříve limitovalo to takto použít.
Jinak je možná důležité co říká:
cat /proc/sys/fs/inotify/max_user_watches
Je nebo není?
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
29.10.2012 14:50 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
S temi starsimi jadry neumim rict. Tipoval bych, ze tam nejake zmeny od prvniho zacleneni byly. Moje vysledky jsou na 3.4.9-gentoo, takze to asi nebude uplne reprezentativni priklad jadra na serveru. Jinak zvyseni limitu v /proc/sys/fs/inotify/ je samozrejme nutnost, defaultne u me bylo maximalne 8192.
29.10.2012 15:03 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Nemůžu najít, není to tak dávno co jsem to četl, nějaký „release notes“ (třeba ½ roku zpět), ale bylo to něco ve smyslu, že byl potřeba desccriptor pro každé „něco“ a fčul už je jeden na celé „něco“.
A protože si to pamatuji takto „přesně“, tak to nemůžu najít… :-(
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
29.10.2012 16:50 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Hm, file descriptor je potreba jen jeden per inotify watch instance, pro kazdy soubor ma pak clovek "watch item". Toto vypada, ze je design choice uz od zacatku. No, jestli to najdete, tak dejte vedet :)
29.10.2012 17:09 chochi | skóre: 29 | Praha
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tohle plati pro inotfy alternativu (kqueue) na FreeBSD, kde je potreba jeden FD na kazdou sledovanou polozku (pokus si dobre pamatuju).
29.10.2012 18:08 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Že by jsem to až tak doplantal dohromady se mi moc nezdá…, nicméně taky nemůžu nic najít, takže jsem jen zbytečně vnesl nejistotu.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
masomlejn avatar 16.10.2012 13:19 masomlejn | skóre: 16
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Možná blbost ale co zkusit přidat --size-only bude to porovnavat podle velikosti, což by mohlo být rychlejší. Samozřejmě změna souboru se nemusí projevit na jeho velikosti a tim pádem můžeš prošvihnout nejaké aktualizace.
rADOn avatar 16.10.2012 13:23 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Můžeš zachytávat změny souborů pomocí inotify, ale existuje limit kolik sond můžeš mít nastavených a nejspíš se do něj nevejdeš.

Spíš hledej filesystém, afaik existuje několikero replikujících filesystémů nad FUSE. Takové fs řeší jen replikaci, fyzické ukládání nechávají na jiném fs nad který jsou přimountovány takže by s OCFS neměl být problém. V našich končinách to dělá třeba SeznamFS (ale nejdřív bych hledal něco co se aktivně vyvíjí.)
"2^24 comments ought to be enough for anyone" -- CmdrTaco
16.10.2012 17:28 Skřivy | skóre: 10
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
A jak to funguje? My jsme to rok pouzivali a v poctu serveru kolem 50 jsme z toho rodili.

Vecne se to rozpadavalo, melo to problemy se symlinky a obcas se to samo dostalo do nekonzistentniho stavu.
rADOn avatar 16.10.2012 19:05 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jestli myslis primo SeznamFS tak ten byl vymyslenej prave jako nahrada rsyncu, takze ma zvladat hromady souboru, ne hromady replik. Matne si pamatuju ze to Edois zkousel na ctyrech nebo osmi master-master replikach v kruhu nebo tak neco, urcite ne padesat. Anyway to byl jen priklad co me prvni napadl, na webu fuse je hromada podobnych projektu.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
16.10.2012 21:55 Skřivy | skóre: 10
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
My jsme to pouzivali v konfiguraci 1 master - 50 readonly slavu a to v produkcnim prostredi. Pouzivali jsme to cca na 100 souboru s frekvenci aktualizace ob den.

Uz z principu fungovani je pocet slavu celkem jedno. Pokud to nejsou stovky az tisice vysoce aktivnich klientu, tak by s tim rozumne napsana aplikace nemela mit vetsi problem.

Dalsi problem, co jsme resili byla vysoka narocnost na sit a cpu. Bez jakychkoliv zmen to trvale generovalo 50Mbit trafficu a bylo celkem bezne, ze to plne vytizilo 1 jadro procesoru (bez jakehokoliv cteni, jenom kdyz jsme to meli primouteny).
16.10.2012 14:10 Drašar | skóre: 27 | Velký Týnec
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Mozna by sel pouzit fam (File Alteration Monitor). Nikdy jsem jej ale nepouzival, takze mozna je to uplne mimo misu :)
Patička
AraxoN avatar 16.10.2012 16:37 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ja som v podobnej situácii použil find:
#!/bin/sh

DATE=`date +%Y%m%d`
TOUCH_OLD=/home/backuper/bin/touch.old
TOUCH_NEW=/home/backuper/bin/touch.new
FILELIST_FILE=/tmp/filelist-${DATE}.txt
SRC_PATH=/var/nfs/

# 1. vytvorime novy docasny touch
touch $TOUCH_NEW

# 2. vytvorime zoznam suborov od predosleho touch
find $SRC_PATH -newer $TOUCH_OLD ! -type d > $FILELIST_FILE

# 3. vytvorime archiv podla zoznamu
/bin/tar -czf - --files-from=$FILELIST_FILE --transform 's|^var/nfs/||'

# 4. posunieme novy touch na stary
mv $TOUCH_NEW $TOUCH_OLD
To vytvorí na pôvodnom serveri zoznam nových súborov a zbalí ho. Výstupný archív ide na STDOUT. To preto, že to potom volám z toho druhého servera:
secondary-server ~ # ssh backuper@primary-server ~/bin/tar-new-files.sh | tar -xz -C /var/zaloha
To vezme zmenené súbory od poslednej synchronizácie, zbalí ich, prenesie cez SSH a rozbalí ich potom na druhom serveri. Počiatočný stav je potrebné samozrejme vytvoriť pomocou plného rsyncu, alebo podobne. Taktiež to nerieši situáciu, keď sa súbory na pôvodnom serveri neskôr vymažú (sekundárny sa to nedozvie a ostanú tam).
A fine is a tax for doing wrong. A tax is a fine for doing well.
Josef Kufner avatar 16.10.2012 17:07 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
rsync dělá něco velmi podobného, jen je o dost vyspělejší a lépe optimalizovaný. Dokonce se dá spouštět skoro stejně jako tvoje řešení.
Hello world ! Segmentation fault (core dumped)
AraxoN avatar 16.10.2012 23:06 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
To je možné, ale ako píše tazateľ, s rsyncom to trvá 8 hodín. Ja som tiež predtým používal rsync, ale keď nebol schopný dokončiť úlohu za jednu noc, tak som musel nájsť iné riešenie. Find to má nájdené behom chvíľky a keď nie je veľa zmien tak sa prenesú za pár minút.
A fine is a tax for doing wrong. A tax is a fine for doing well.
16.10.2012 23:18 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tak, a co tedy dělal rsync pomaleji než toto ruční řešení? Jak dlouho trval dru run?

Můj tip je nějaká chyba v použití rsync, která působila přenášení i souborů, které se nezměnily.
21.10.2012 17:12 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Zdravim,

co kdyz dojde k vytvoreni noveho adresare? :)

Jiri Horky
AraxoN avatar 21.10.2012 23:02 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Prázdne adresáre sa neprenesú.

Ak tam ale je nový adresár a v ňom nový súbor, objaví sa vo fileliste. Podľa filelistu sa súbor normálne zabalí a na cieľovom stroji rozbalí. Pri tom sa vytvorí aj ten adresár.
A fine is a tax for doing wrong. A tax is a fine for doing well.
Josef Kufner avatar 16.10.2012 17:28 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Hele a co udělat distibuované úložiště? Prostě to rozhodit na více řadičů a více disků, kde klíčem k rozdělení by byl třeba první byte MD5 hashe cesty (nebo jakákoliv jiná rovnoměrně rozprostřená hodnota)?

Když bys to rozdělil třeba jen na čtvrtiny, tak máš místo 200GB jen 50GB disky a to už v pohodě vleze na levné SSD. Když to dáš na 16 dílů, vejdeš se do RAM (ale nebude to levné). Obrovskou výhodou by bylo paralelní zpracování, kdy by to místo osmi hodin běželo jen jednu hodinu a bylo to snadno rozšiřitelné.

Pak stačí mezi servery synchronizovat routovací (hashovací) tabulku, kde máš uloženo, jaké rozsahy klíče jsou na kterém disku. To aby jsi mohl kompenzovat nerovnoměrnosti rozložení, případně dávat současně používaná data blízko k sobě.

Sice to bude stát nějaké to železo, ale myslím, že na ušetřeném času a šedinách admina se to vrátí.
Hello world ! Segmentation fault (core dumped)
16.10.2012 18:14 chsajarsa | skóre: 16 | blog: V_hlouby_destneho_pralesa | Lovosice(Praha)
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Takhle funguje gfs v geografickem rezimu. Dela si hashe a podle toho je rozhazuje na nody, takze tohle reseni uz existuje.
~ QED ~
16.10.2012 22:08 dustin | skóre: 60 | blog: dustin
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Při používání backuppc jsme bojovali úplně s tím samým problémem. Rsync si drží informace o prošlých souborech v paměti a často sežral všechnu paměť i swap a konec. Používáme místo toho tar s parametrem --newer a ten je řádově rychlejší. Samozřejmě to nezdetekuje hrátky s časy.

Jinak offline kopie děláme přes synchronizaci raidu1, nic rychlejšího jsme zatím nenašli.

16.10.2012 23:46 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Není to pouze problém toho, jak backuppc používá rsync? Při pár milionech nezměněných souborů není spotřeba RAM prakticky měřitelná (tj. něco málo rsync samozřejmě naalokuje, ale neškáluje to s počtem souborů a zůstává to v promilích).

rsync není ideální nástroj na obyčejný přenos souborů, tj. pokud na druhé straně není nic, co by připomínalo adresářovou strukturu na zdroji. Ale při synchronizaci může být tar těžko citelně efektivnější.
17.10.2012 21:13 dustin | skóre: 60 | blog: dustin
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jo, rozdíl samozřejmě je, protože rsync komunikuje a hlavně čte na obou stranách (přičemž serverová strana implementuje rsync v perlu, ale mluvím o straně zálohované, kde běží binárka rsyncu), zatímco tar --newer žádnou druhou stranu neřeší a prostě hrne jen --newer soubory rourou po síti.
16.10.2012 23:38 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Někde je nějaká zrada. Například, že cílový systém nerepresentuje věrně vlastnosti souborů zdrojového, takže je rsync nucen kontrolovat obsah souborů, což je sice poměrně rychlé přes kontrolní součty, ale řádově pomalejší než nečíst je a nepřenášet nic.

Uvedené parametry totiž docela dobře popisují můj home, který je akorát asi poloviční. Nezmění-li se žádné soubory, trvá kopletní rsync-over-ssh deset sekund. Když se přenášejí data, tak se samozřejmě čas prodlužuje úměrně množství dat (a nepřímo úměrně rychlosti sítě, což je standardní stomegabit). Dostat se na čas delší než několik minut za normálních okolností, tedy když jsou změny ve stovkách MB až pár GB, nejde (což odpovídá teoretickému odhadu).

Zato tvých 8 hodin odpovídá tomu, že by se četlo a přenášelo praticky všechno, nejen nějaká malá, změněná část.

Je běžné, že se ti mezi rsyncy změní velká část těch souborů, třeba 80%?

Máš na zdroji (případně v cíli) souborový systém, který nějak blbě pracuje s malými soubory?

Nezpůsobuje to --delete-during?

Co já vím. Ale někde je zrada.
Josef Kufner avatar 16.10.2012 23:52 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ty malé soubory jsou svinstvo. Kdysi jsem měl na disku tile storage od stahování map z googlu (do trekbuddy), pár gigabajtů, ale backup rsyncem trval nechutně dlouho, i když se nic neměnilo.

Souborový systém by v tom prsty mohl mít. Co třeba takový atime? není zapnutý?
Hello world ! Segmentation fault (core dumped)
17.10.2012 00:06 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jo, strictatime by tohle dělat mohl.
17.10.2012 10:20 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Další možnost je I/O bound load na serveru. Pokud se rsync neustále bije o I/O se zbytkem vesmíru, tak samozřejmě jde rychlost do kytek. Z popisu problému těžko říci.
17.10.2012 14:13 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Co bych měl ještě dodat?
17.10.2012 10:27 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tak to jsem zvědavý co se z toho vyvrbí, mně něco podobného udělá rsync doma tak 1× měsíčně, ručně spouštím skript, kde je rsync (jen naznačuji, že vždy stejně a není to pravidelné) z Debianu na OpenSuse, fčul přes NFS a jednou za čas mi to místo několika sec až několika málo min běží neúměrně dlouho a to několikanásobně déle než by proběhlo pouhé kopírování té složky a oba stroje jsou nevytížené - je pravdou, že server má přiděleno jen 500MiB RAM, je to jen jedno-jádro a je to na XEN-u, ale normálně mu to stačí a stane se to jen jak píšu. V průběhu toho, můžu normálně ze serverem komunikovat a to i na to NFS (jiný share) a rychlost je jen v řádech procent nižší (tedy téměř neměřitelně) než bez toho běžícího rsycn-u.
Už jsem to vzdal, protože mi to nestojí za to (je to jen rsync domovské složky a doma), a hlavně proto, že to udělá třeba 1× za měsíc nebo dva, já v průběhu prolezu vše co mě napadne, nic nezjistím a opakovaně to už funguje „mtk-mrk“ (takové věci jako -x, -c, jsem tam zkoušel ale stejně se to zas stalo).
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
17.10.2012 07:16 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jde mi o to, jak se zbavit času, který rsync stráví tím, že musí zkontrolovat u deseti milionů souborů zkontrolovat, zda se změnily.

Kolik času z těch 8 hodin vlastně zabere ta kontrola (parametr --dry-run)? 10M souborů mi nepřipadá tak moc.
17.10.2012 09:29 Jupi | skóre: 18
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
10M suborov sa nezda byt vela, ale treba si to preratat na IOPs. Ak sa puzivaju klasicke 10k otackove disky, tak budme optimisti, ze urobia 1k IOPs pre jeden zvazok v RAID1, treba zaratat aj seekovanie hlaviciek, tak tych 8 hodin je vpohode. Jedno z rieseni by bolo pouzit SSD disky. IOPs by islo o niekolko radov hore a cas rsync pod 1 hodinu s prehladom.
Jendа avatar 17.10.2012 09:52 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ale rsync podle mě nehrabe na každý soubor, ale jde stromečkem adresářů.
17.10.2012 09:57 Jupi | skóre: 18
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Myslel som to tak, ze ziskanie potrebnych udajov o kazdom subore je potrebna jedna IOP. Nie na nacitanie obsahu suboru. To by bolo urcite viac.
To je len na zjednodusenie. V jednej IOP sa moze nacitat info aj o viac suboroch, ale napr. 1 z 1000 suborov musi byt aj preneseny, co su dalsie IOPs na disk + sietovy prenos, ...
17.10.2012 10:18 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
No, tak to na rozumném souborovém systému snad není. Doporučuji si to zkusit prakticky změřit.

IOPs na přenos teď nepočítáme, to je sekvenční čtení a samozřejmě škáluje s velikostí přenesených dat, nikoli s počtem souborů. Jde-li o synchronizaci, předpokládáme, že objem přesnených dat je relativně malý. Takže potíž je v tom, když dosahuješ časů, které opovídají přenášení všeho.
Josef Kufner avatar 17.10.2012 16:38 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Záleží na jeho konfiguraci. Nejsem si jist, co dělá defaultně, ale může i kontrolovat obsah souborů a to pak znamená počítání hashů. A pokud mu filesystémy neposkytnou vše potřebné, asi to bude jako fallback.
Hello world ! Segmentation fault (core dumped)
17.10.2012 10:14 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Tak prosím prerátat. Kolik IOPs je v průměru zapotřebí na přečtení jedné inode? Jak by mohl být find, tar nebo cokoli, jak zde různí lidé tvrdí, být rychlejší, když tyto IOPs musí provést naprosto stejně?

Praktické testy na naprosto cold systému se starým SATA II 7200RPM diskem, ext3, dávají přečtení 3000+ inodů za sekundu. I v tom nejpesimističtějším případě by dry-run s nezměněnými daty trval pod hodinu. Druhý běh by pak samozřejmě trval už jen několik sekund díky cache...

Zrada prostě musí být někde jinde.
17.10.2012 09:24 Jupi | skóre: 18
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Uz tu niekto pisal DRBD. Podla mna je to idealne. Ak to nepoznas, moze to byt v podstate mirror, ktory funguje medzi zariadeniami cez LAN. Pracuje na urovni device a nad tym moze bezat lubovolny FS. Pri kapacite 200GB je to uplne pohoda.
Heron avatar 17.10.2012 09:40 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
DRBD pracuje na úrovni blokového zařízení a nikoliv souborů. To mu příliš nepomůže, když potřebuje oboustraně synchronizovat soubory.

Musel by mít drbd v režimu active-active a nad tím FS, který s tím umí pracovat.
17.10.2012 10:05 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Bohužel DRBD mi nepomůže. Potřebuju synchronizovat data mezi dvěma svazky na jednom diskovém poli.
Jendа avatar 17.10.2012 09:53 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Přidej k rsyncu -vh --progress a podívej se, kde to nejdéle čeká.
17.10.2012 10:34 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Spustil jsem rsync s parametry uvedenými v prvním příspěvku a přidal k nim parametry -vh --progress. Po spuštění běžel výpis adresářů velmi rychle. Po několika minutách se tak zpomalil, že nyní jej v podstatě stíhám číst. Procesor se fláká, systém má ještě 6 GB volné RAM. Load je na 3,75.
17.10.2012 10:36 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jo a svazky jsem přemountoval s parametrem noatime.
17.10.2012 13:50 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Předpokládám, že to zkoušíte s --dry-run? Jinak by se zrychlení díky přemountování s noatime projevilo až po úspěšné synchronizaci atimes na druhý stroj :)
20.10.2012 18:52 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jakého času jste dosáhl s tím --dry-run, pokud to není tajné?
17.10.2012 10:50 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Utilizace zdrojového svazku je na 100%.
17.10.2012 12:30 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ahoj, rsync se pro tohle proste nehodi. Resil jsem podobny problem asi 3 roky zpatky a nakonec jsem skoncil s jednoduchym skriptem s find a cp. Mel jsme neco kolem 7M souboru do 1MB, kolem 5000 zmen denne a kopirovani trvalo kolem 1 hodiny.
17.10.2012 13:15 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Nevím sice, kde je problém, možná narážíte na nějakou chybu rsyncu, ale těžko lze tvrdit že rsync se pro toto prostě nehodí, když jde o primární účel rsyncu. K čemu by se hodit měl, když ne k tomuhle?
17.10.2012 16:01 linuxik | skóre: 32 | Milovice
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
K efektivni synchronizaci velkych souboru u kterych se nejvice uplatni schopnost prenaset poze zmenene casti. Pro kilobytove soubory bude vzdy find + cp radove rychlejsi.
Josef Kufner avatar 17.10.2012 16:42 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
rsync má volbu na přenosy celých souborů a neřešení změn.
       -W, --whole-file
              With this option rsync’s delta-transfer algorithm  is  not  used
              and  the  whole file is sent as-is instead.  The transfer may be
              faster if this option is used when  the  bandwidth  between  the
              source  and destination machines is higher than the bandwidth to
              disk  (especially  when  the  "disk"  is  actually  a  networked
              filesystem).   This is the default when both the source and des‐
              tination  are  specified  as  local  paths,  but  only   if   no
              batch-writing option is in effect.
Hello world ! Segmentation fault (core dumped)
17.10.2012 17:11 alkoholik | skóre: 35 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
A z jakeho adresare ten rsync spoustis?
Me delal psi kusy, kdyz jsem byl v adresari, ktery mel synchronizovat.
Jeste se muzes podivat pres strace -p, co v tu chvili dela..
Heron avatar 17.10.2012 09:59 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Jak velkou paměť mají ty stroje? Na jednom hodně slabém železe máme cca 7M souborů na 1.5GB RAM a je to opravdu problém. Linux si nemůže cachovat dentry a tak každý adresář musí nutně číst z disku. Přidání paměti obvykle dost pomůže. Rsync by po nějaké první synchronizaci neměl potřebovat nic jiného, než porovnání adresářového záznamu na zdroji a cíli, takže ani na záznamy v inode nebude seekovat. Pokud se vše potřebné vleze do RAM, tak rsync (porovnání) i nad 10M soubory je na pár sekund.
17.10.2012 10:11 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Servery jsou nové a mají 16GB RAM.
17.10.2012 16:16 x
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Neco jako Real time backup server , detaily i v mail archivech. Pripadne primo pouziti snapshotu na Hammer nebo ZFS
20.10.2012 20:26 pavel
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
rsync je spouštěný přes ssh?
Josef Kufner avatar 20.10.2012 20:30 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Áno, rsync--ssh--rsync. I to umí.
Hello world ! Segmentation fault (core dumped)
21.10.2012 17:01 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Zdravim,

toto tema me zajima. Problemu muze byt vice a to i na strane serveru a ne na strane klienta. Rsync totiz per soubor dela pomerne dost metadata operaci na strane serveru (vypisy jsou z verzi 3.0.9 na klientu a 3.0.4 na serveru):

Toto jsou operace pro jeden novy soubor na strane serveru:
3090  1350825670.190272 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", 0x7fff95b06940) = -1 ENOENT (No such file or directory) <0.001303>

3091  1350825691.894455 select(5, NULL, [4], [4], {30, 0}) = 1 (out [4], left {29, 999997}) <0.000012>
3091  1350825691.894515 write(4, ""..., 8) = 8 <0.000019>
3091  1350825691.894582 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000547>
3091  1350825691.895178 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", O_RDWR|O_CREAT|O_EXCL, 0600) = 1 <0.002558>
3091  1350825691.897779 fchmod(1, 0600) = 0 <0.002224>
3091  1350825691.900058 write(1, ""..., 3350) = 3350 <0.003614>
3091  1350825691.903712 close(1) = 0 <0.000015>
3091  1350825691.903759 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", {st_mode=S_IFREG|0600, st_size=3350, ...}) = 0 <0.000025>
3091  1350825691.903837 utimes("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", {{1350825691, 0}, {1350820690, 0}}) = 0 <0.000461>
3091  1350825691.904343 chmod("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", 0644) = 0 <0.004003>
3091  1350825691.908391 rename("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/.board-zoom-debugboard.c.BVJsNA", "linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c") = 0 <0.003544>
Na strane klienta pak:
32459 1350825662.709026 lstat("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", {st_mode=S_IFREG|0644, st_size=3350, ...}) = 0 <0.000008>
....
32459 1350825681.527884 open("linux-3.4.9-gentoo.10/arch/arm/mach-omap2/board-zoom-debugboard.c", O_RDONLY) = 3 <0.000007>
32459 1350825681.527911 fstat(3, {st_mode=S_IFREG|0644, st_size=3350, ...}) = 0 <0.000005>
32459 1350825681.527942 read(3, ""..., 3350) = 3350 <0.000313>
32459 1350825681.528286 close(3) = 0 <0.000005>
V pripade, ze soubor jiz existuje, je to jednodussi, ale z nejakeho duvoud dojde ke dvoum statum na strane serveru:
25558 1350830502.774044 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.002337>
.....
25558 1350830502.868738 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.000014>
Na strane klienta:
32643 1350830500.817663 lstat("linux-3.4.9-gentoo/arch/arm/mach-tegra/board-seaboard.c", {st_mode=S_IFREG|0644, st_size=7902, ...}) = 0 <0.000006>
Tj. na serveru se pro novy soubor dela paradoxne daleko vic metadata operaci. Na filesystemech, kde jsou metadata operace pomale, coz jsou typicky distribuovane FS , to pak jede velmi pomalu. Jestli jsem to pochopil spravne, tak je to prave Vas priklad? Jestli ano, jak dlouho trva projit tech 10M souboru findem pri COLD cachi (sync; echo 3 > /proc/sys/vm/drop_caches) na strane klientu a serveru?

Navic rsync ve verzi < 3.0.0. nejdrive udela incremental list a pak az prochazi soubory, od verze 3.0.0 to uz dela naraz. Jakou mate verzi, jake mate OS, verzi jadra? A jaka je latence mezi klientem a serverem?

22.10.2012 13:36 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Nepoužívám distribuovaný FS, nýbrž clusterový OCFS2. Filesystém je vytvořný nad sdíleným diskovým polem připojeným přes iscsi.

Projití 10M souborů trvá několik hodin. Resp. dnes ráno jsem pustil find a ještě nedoběhl.

Klient i server jsou na jednom stroji. Potřebuji synchronizovat data mezi dvěma svazky na stejném diskovém poli. Tyto svazky jsou na serveru připojeny do dvou různých složek.
rsync --version
rsync  version 3.0.9  protocol version 30
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes
Linux w12 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Latence mezi serverem a klientem by měla být minimální, protože se oba nacházejí na stejném serveru.
22.10.2012 14:19 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
OT:
Projití 10M souborů trvá několik hodin. Resp. dnes ráno jsem pustil find a ještě nedoběhl.
s tím bych tedy pracovat nechtěl, když to srovnám s jednojádrem LE-1640 a 5400ot disky v mirror-u na LVM s ext3.
time find / | wc -l
1124504

real    2m55.660s
user    0m0.576s
sys     0m1.908s
Opakovaně:
real    0m9.881s
user    0m1.064s
sys     0m1.724s
Tak mi to přijde jako moc velký rozdíl.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
22.10.2012 20:42 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.

Diky za info. Kdyz jsem psal distribuovany FS, mel jsem na mysli i clusterovy FS - v tomto pripade je to celkem jedno, protoze v obou pripadech musite hlidat konzistenci dat a resit distribuovane zamky. OCFS2 skoro neznam, ale jelikoz pouziva DLM, metadata operace budou o rad drazsi.

Jestlize Vam samotny find jede takto dlouho, rsync na vine neni, ale taky tady neni moc co optimalizovat. Nenapada me moc, jak to pri stavajicim FS delat nejak vyrazne rychleji. Je otazka, jestli ma OCFS2 nejakou feature, ktera by se dala vyuzit (treba GPFS umi ten seznam zmenenych souboru generovat samo). Pokud ne, je treba hledat asi uplne jiny postup. Co takhle snapshoty? Nad LVM nebo mozna primo na urovni pole?

Je to asi rok, co jsem si hral s lsyncd, tj. na bazi inotify, ale taky jsem narazil na to, ze to neni uplne delane na takove mnozstvi souboru. Mozna bych inotify mechanismus ale uplne nezatracoval, treba jen v lsyncd delaji neco spatne.

24.10.2012 09:48 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Ještě sem hodím výsledky findu:
root@web:~# time find /iscsi/home/  -type f |wc -l
10696002

real    619m58.719s
user    1m26.397s
sys     108m56.076s

root@web:~# time find /iscsi/home/ |wc -l
12047276

real    42m20.375s
user    0m27.078s
sys     6m35.977s
Pokud nechám find běžet bez jakýchkoliv parametrů, tak mu projití cca 12M souborů trvá cca 42 minut.
24.10.2012 11:11 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
A ještě jednou, tentokrát s vyčištěním keše:
root@web:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@web:~# time find /iscsi/home/ |wc -l
12052096

real    50m38.067s
user    0m27.738s
sys     7m14.467s
root@web:~# time find /iscsi/home/ |wc -l
12052327

real    0m29.497s
user    0m8.017s
sys     0m22.129s
root@web:~# time find /iscsi/home/ |wc -l
12052383

real    0m28.665s
user    0m7.816s
sys     0m21.513s
24.10.2012 11:38 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.

Zrovna jsem se na to chovani findu vcera dival. Kdyz se mu rekne -type f, zacne find stat()ovat vsechny soubory, na ktere saha. Je to trochu skoda, protoze typ souboru se da od nejake verze 2.6.4 kernelu (a pravdepodobne i v zavislosti na filesystemu) se drzi primo v dentry, tj. pro zjisteni typu souboru neni potreba delat volalni stat(). Kdyz se mu "-type f" nerekne, tak stat() na soubory nedela.

To ale prilis neresi problem s rsyncem, ktery stat() proste volat musi. Tj. OCFS2 je na stat() proste pomale, takze bud jiny FS, nebo uplne jiny pristup.

24.10.2012 11:45 OgeeN
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Bohužel jediný další kandidát, kterého jsem testoval byl GFS2. Bohužel už si teď nevzpomenu, proč jsem ho na konec opustil. Ale byly v tom nějaké zásadní problémy. :)

Existuje ještě nějaká alternativa k těmto dvou clusterovým filesystémům? Já jsem žádnou nenašel. Ostatní filesystémy které jsem zkoumal (coda, lustre, GlusterFS a další) dělají něco jiného než potřebuji anebo se jedná o pověstný kanón na vrabce.

Abych shrnul moje požadavky, tak potřebuji aby deset a více serverů přistupovalo na jednou pomocí iscsi k datům na sdíleném úložišti. Data musí být připojena jako rw. Filesystém proto musí řešit konkurenční zápis do souborů.
24.10.2012 13:54 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
NFS alebo SMB? :)
27.10.2012 10:13 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
SMB snad radeji ani ne :) NFS by na chvili pomoct mohlo, ale je potreba si ujasnit, jestli zaruky o konzistenci cachi, ktere NFS dava, staci pro toto pouziti ci nikoliv. Pak by se dal rsync poustet na serveru, kde uz bude vhodny lokalni FS, na kterem to projiti bude daleko rychlejsi. Ocekaval bych zrychleni kolem 5-10x (viz cisla z diskuse), coz by problem na chvili odsunulo.
25.10.2012 21:13 Ivan
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
afs, cfs, gpfs, advfs

popr. nejaky sitovy filesystem(napr. NetApp+NFS)

nemyslim si, ze pri objemu milionu souboru a deseti nodech v clusteru by bylo nejake reseni kanon na vrabce.
24.10.2012 11:42 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
To je asi tak trošku i na mě i když stále OT, když jsem tedy dával toto, takže mě to dá na velmi slabém HW toto:
> time find / -type f | wc -l
913191

real    2m32.735s
user    0m0.596s
sys     0m1.640s
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
24.10.2012 23:53 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Pravděpodobně na to má hlavní vliv síťová komunikace a filesystemy. zkusil jsem podobné testy u sebe a výsledek je:

lokální disk 2 TB/5400ot filesystem XFS
time find /mnt/zaloha_1 -type f | wc -l
181213

real    0m9.366s
user    0m0.126s
sys     0m0.760s
lokální disk 2TB/5400ot filesystem NTFS (společná data pro pracovní win instalaci)
time find /windows/zaloha_2 -type f | wc -l
368354

real    1m52.077s
user    0m0.748s
sys     0m3.349s
síťový disk 2,7TB na domácím serveru/NAS, připojení NFS4 fyzická realizace soft RAID5 4x1,5TB, procesor serveru úsporné dvoujádro Zacate s 4GB paměti.
time find /mnt/basic -type f | wc -l
762845

real    5m57.818s
user    0m1.448s
sys     0m11.628s
Je zajímavé, že v průběhu find žádná komponenta nebyla na limitu, přesto hledání nebylo rychlejší. (zátěž sítě cca 1,5MB/s - 15%, CPU serveru cca 40% jednoho jádra, zátěž disků na serveru cca 10%, CPU klienta cca 5%)
25.10.2012 00:14 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Hmm...ze by pri tom spojeni cez NFS mala na vykon v tomto pripade taky velky vplyv latencia, ktora je pri komunkacii cez x vrstiev a siet o niekolko radov vyssia ako pri lokalnom FS? Mozno by bol este zaujimavy experiment namiesto NFS4 skusit iSCSI, ze ci to nejako citelne klesne. :)
27.10.2012 11:57 MiK
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
ve zkratce: OCFS2, cluster filesystem, ZAMKY -> to ti "zpomali" veskere diskove operace, viditelne pri velkem mnozstvi malych souboru.

precti si o principu zamykani v dokumentaci k OCFS2

Tudiz, jak tu nekdo zminil, to, ze to dlouuuho trva bych odhadoval opravdu na problem (funkcnost :) ) zvoleneho filesystemu...

zkus si, jen pro porovnani a jestli mas moznost, presunout cely obsah jen na klasicky ext a provest ten rsync mezi.
21.10.2012 19:52 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Taky přidám zkušenost - rsync nad cca 1 M souborů a 250 GB, zdroj XFS nad 8×SAS10K disky v RAID50 / cíl EXT4, 4×1TB SATA sw RAID10.

Potřeboval jsem synchronizovat i xattr - protože Samba DOS atributy, které na XFS řešené klasickým způsobem (exec bity) dělaly různé záhadné problémy - zřejmě kombinace s default ACLs, které se chovají k exec bitům jinak než na EXT4, ale to už je jiný problém.

I když se změnilo jen pár stovek malých souborů, rsync trval třeba 8 hodin. Bez synchronizace xattr pak méně než 45 minut. Přitom dump xattr všech souborů na zdrojovém fs trvá jednotky minut... nechápu. Už aby tu bylo něco jako ZFS snapshoty a send/receive.
23.10.2012 00:22 d
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
xattr byvaji ulozene v dalsim bloku, pokud pro ne neni nejake misto rezervovano v samotne inode, takze jejich synchronizace vyzaduje dalsi seeky.

dump xattr muze tezit z toho, ze je do jiste miry sekvencni, tzn. pokud se cteni xattr neproklada ctenim dalsich dat souboru.
23.12.2012 20:29 JiriHorky
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
Zdravim,

podarilo se to nejak vyresit, ma pohadka stastny konec? :)

Jiri Horky
23.12.2012 23:56 l4m4
Rozbalit Rozbalit vše Re: Pohádka o rsyncu a deseti milionech souborů.
To by mě taky docela zajímalo. Ačkoli podobné problémy s rsyncem nepozoruji, zjevně při ‚šťastných‘ okolnostech nastat mohou, takže by bylo užitečné vědět, kde je vlastně zakopaný pes.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.