Názory k článku Synchronizujeme se zsync aneb rsync po běžném HTTP
-
CET (neregistrovaný)
Ja pouzivam http://sourceforge.net/projects/sereds CWrsync. Je to vlastne vykousanej rsync z cygwinu. Mas tam balik client nebo server, da se nainstalovat jako sluzba. Bud pouze s rsync protokolem nebo myslim i s ssh serverem. Ted si nejsem jistej, jestli ten ssh server ma v sobe, pokud ne, tak http://sourceforge.net/projects/sshwindows SSH Windows.
-
I DeltaCopy umi UTF, ale musi se na to jit fintou, protoze standartni dll z cygwinu UTF neumi. hledej na webu
http://www.aboutmyip.com/AboutMyXApp/DisplayFAQ.do?fid=13
http://www.okisoft.co.jp/esc/utf8-cygwin/ -
Když už jsme u tohoto typu programů, tak doporučuju podívat se ještě na rdiff-backup a Unison. Oba mají trošku jiné použití než rsync/zsync, ale mně se tyto programy docela osvědčily, tak se snad budou hodit i někomu dalšímu.
rdiff-backup– v Pythonu napsaný (tedy dobře multiplatformní) nástroj pro zálohování. Data přenáší stejně úsporně jakorsync(používá knihovnulibrsync), také dokáže pracovat s lokálními i vzdálenými adresáři (nebo jejich kombinací). Provádí zálohu přesné kopie zdrojového adresáře do adresáře cílového. Pokud ale v cílovém adresáři již nějaká starší verze existuje, tak ji jen tak nepřeplácne, ale uloží si do podadresářerdiff-backup-data/diffy změn. Přímo uložená je tedy přesná kopie aktuálního stavu, pomocí diffů je ale možné zrekonstruovat z ní i verzi starší. Takto je to možné provádět pořád dokola, k dispozici jsou pak všechny starší verze. (Jedná se vlastně o extrémně primitivní nástroj pro správu verzí.) Co se mi na nástroji hrozně líbí je to, že aktuální kopie je vždy uložená přímo. Pokud tedy smažete ten speciální podadresářrdiff-backup-data/, tak máte úplně normální kopii adresáře, jako kdybyste data prostě zkopírovali pomocícp/scpapod. Nejste tedy závislí na programurdiff-backup, data obnovíte i bez něj prostý kopírováním, nejsou v žádném speciálním formátu.rdiff-backuppotřebujete jen pro (pohodlnou) obnovu starších verzí. Zadarmo také máte kontrolní součty všech souborů v záloze (rdiff-backupsi SHA-1 součty dat ukládá v tom pomocném adresářirdiff-backup-data/), pro ověření konzistence zálohy tedy stačí spustitrdiff-backup -v /cesta/k/záloce/a hned víte, jestli vám záložní médium tiše nedegraduje.Unison– Skvělý multiplatformní nástroj pro synchronizaci dvou adresářů (např. na notebooku a pracovní stanici; umí pracovat se vzdáleným adresářem např. přes SSH). Data opět přenáší efektivně, podobně jako rsync. Je určený opravdu k synchronizaci dvou adresářů, které se mění oba současně a nezávisle na sobě. Při synchronizaci si data na obou stranách očuchá, porovná se svým pomocným záznamem o posledním známém stavu a uživateli navrhne co dělat (např. nové soubory z notebooku nahrát na desktop, soubory smazané na desktopu smazat i na notebooku, změny v souborech na notebooku propagovat na desktop a opačně). Typicky se pracuje interaktivně (k dispozici je textový režim a GTK GUI), takže uživatel může návrh propagace změn zkontrolovat a případně směr synchronizace změnit (nebo synchronizaci některých dat úplně přeskočit). Pokud Unison neví co dělat (např. na obou stranách se objevil nový stejně pojmenovaný soubor, ale s jiným obsahem), tak je zásah uživatele nutný (pokud nebylo dopředu explicitně řečeno, že jedna kopie je velící a použijí se data z ní). Nástroj si zakládá na bezpečnosti synchronizace, takže se např. cokoliv maže vždy až na úplný konec a po důkladném ověření, že se data opravdu přenesla správně. -
Xjmeno363 (neregistrovaný)
Nějak jsem nepochopil to vytvoření crc
zsyncmake -u http://mujweb.cz/soubory/obraz.iso -b 8192 obraz.isoproč je tam jako parametr 2× obraz.iso?
-
CET (neregistrovaný)
„…nevyžaduje speciální podporu na druhé straně.“
„K dispozici je samozřejmě i kontrolní soubor, který sice leží v jiném adresáři, ale to vůbec nevadí…Oba soubory jsou dostupné skrze HTTP,“
Takze na web server popdora MUSI byt – musi tam nekdo vytvorit ten zsync soubor. A pokud uz by tam nekdo mel vytvaret zsync soubor, tak je rovnou jednodussi nechat spusteni rsync.
„Velkou výhodou zsync je právě ta vlastnost, že celý systém nevyžaduje žádnou speciální podporu na straně serveru. Toho využívá například Ubuntu, které už nějakou dobu soubory .zsync na svých zrcadlech nabízí.“
Pokud se nepletu, tak vetsina distribuci ma podporu rsync uz hodne dlouho. A rsync nevyzaduje vubec zadnou podporu, proste se nahrajou data a tim to konci. Zsync potrebuje „podporu“ uzivatele – po nahrani dat musi uzivatel vytvorit kontrolni soucty. Pokud uz mam pristup k nejakemu serveru, kde muzu generovat zsync soubory, tak radeji nahodim rovnou rsync (at uz jako root nebo user).
Ale jinak je to zajimava myslenka. Ikdyz uz je tady bittorrent, jidgo a rsync.
-
LesTR (neregistrovaný)
Ano, autor to nazval trochu salamouncky : )
Logicky se jedna o implementaci http kodu odpovedi 206 Partial Content – viz http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.7 -
me (neregistrovaný)
Myslim si, ze zsync muze byt rychlejsi nez jigdo. Pokud teda nemate uz na disku hromadu balicku, muzete dojit k cili rychleji pred jigdo; zkuste si to… ;-). Urcite je zsync jednodusi na pouzivani, pokud mate stare CD/DVD a chcete stahnout novou verzi, stoji zsync za pokus. Vlastne lze jigdo a zsync i zkombinovat, nejprve si pomoci jigdo pripravite CD/DVD z dostupnch dat ktere uz mate (stare CD/DVD. balicky v cache, atd) a v momente kdy zacne jigdo stahovat chybejici balicky z webu, tak zapojite do hry zsync a CD/DVD dokoncite; je to jen trosku pracne… ;-)
Proti rsync (i jigdo) je zsync pro koncoveho uzivatele vyrazne jednodussi na pouziti. V porovnani s rsync nezatezuje server (vypocty probihaji na strane klienta).
Na otazku zda Ubuntu dava prednost zsync pred jigdo je ma odpoved, ze mate moznost volby a je jen na Vas co pouzijete… Osobne si myslim, ze jigdo moc uzivatelu nepouzivalo, zsync ma vetsi sance na rozsireni, je jednoduchy.
Dalsi zajimavou alternativou pro download velkych souvboru (DVD/CD) je „metalink“, ktery propaguje OpenSUSE a je podporovan treba aria2 klientem. Metalink umi vhodne spojit vyhody http z rychlych serveru a bittorrent klienta. Pokud by se matelink rozsiril o podporu zsync protokolu, bylo by to take zajimave…
-
me (neregistrovaný)
Nestane se vubec nic zvlastniho, zsync zmenu pozna a stahne jen par bajtu aby soubor opravil. Vyzkousejte!
Zsync totiz nepasuje bloky hloupe (jednoduse) proti sobe (jak to dela treba bittorent, ktery porovnava bloky na stejnem offsetu), ale pouziva „rolling checksum“, nebo jak se ten algoritmus jmenuje. V ridicim souboru (soubor s priponou zsync), je kazdy blok fixni velikosti (treba 4096b) popsan dvema kontrolnimi soucty. Jeden jednoduchy otisk (rychly na vypocet) se pouziva k vyhledavani znamych bloku dat, silnejsi kontrolni soucet se pouzije k overeni, ze nalezeny blok dat je skutecne ten ktery potrebujme. To byl pokus o jednoduche vysvetleni, presnejsi a podrobnejsi nejdete treba zde:
-
xurfa (neregistrovaný)
i když se mi to zas tak moc nelíbí, protože je IMHO nebezpečí, že při update souboru se zapomene updatovat i .zsync soubor a bude to všechno v pr…
možná by nebylo od věci např. na straně serveru naimplementovat generování zsync pomocí php (nebo jiného skriptovacího jazyka dle gusta…), ten soubor nevypadá tak strašně složitě, nemáte někdo odkaz na jeho specifikaci?
-
me (neregistrovaný)
prostudujte si zdrojovy kod zsyncmake… ;-)
Pripadne hledejte zde:
http://zsync.moria.org.uk/indexAle delat to v PHP, nevim, asi to neni dobry napad, zvlast, pokud existuje zsyncmake…
-
me (neregistrovaný)
Pokud zsync soubor neodpovida souboru ktery popisuje, zsync to pozna a vyhlasi error. Kazdy blok ktery se stahne s http serveru je porovnan s ocekavanym blokem (otisk bloku je ulozen v ridicim „zsync“ souboru), takze pokud zsync stahne blok dat a vyjde mu jiny kontrolni soucet nez ocekaval, ohlasi error a konci. Toto se obcas stane, pokud si stahujete CD, ktere se prubezne aktualizuje, trebe „Ubuntu daily build“. Muze se stat, ze zacnete stahovat CD, ktere se na serveru zmeni drive nez dokoncite stahovani; zsync tuto situaci detekuje v okamziku, kdy mu poprve vyjde kontroni soucet odlisne. Vetsinou staci spustit proces znovu, pokud kontrolni soubor odpovida souboru ktery popisuje, pouziji se jiz stazena data k vytvoreni aktualni verze.
-
me (neregistrovaný)
Kazdy vikend si spuste tento prikaz:
zsync http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso.zsync
A uvidite, jak probiha vyvoj Ubuntu 10.04 a muzete testovat… ;-) Prvni download bude trvat dele (pokud mate rychly internet, pak muze byt rychlejsi WGET nez ZSYNC), dalsi vikendy budete stahovat jiz jen zmeny. A az na konci dubna oficialne vyjde Ubuntu 9.10, provedete update z beta CD na final CD nejak takto:
zsync -i lucid-alternate-i386.iso http://releases.ubuntu.com/10.04/ubuntu-10.04-alternate-i386.iso.zsync
-
me (neregistrovaný)
Update proti vcerejsku vypada nejak takto:
$ zsync http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso.zsync
#################### 100.0% 460.4 kBps DONEreading seed file lucid-alternate-i386.iso: ******************************************Read lucid-alternate-i386.iso. Target 98.4% complete. *****************************************************************************
downloading from http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso:
#################### 100.0% 585.2 kBps DONEverifying download…checksum matches OK
used 662204416 local, fetched 10851471$ ls -ltr lucid-alternate-i386.iso*
-rw------- 1 user user 672378880 2010–03–13 20:40 lucid-alternate-i386.iso.zs-old
-rw------- 1 user user 673048576 2010–03–14 13:33 lucid-alternate-i386.iso -
me (neregistrovaný)
Distribuce SLAX (www.slax.org) zsync soubory nepodporuje. Ale prave na SLAX lze hezky ukazat, jak zsync muze zrychlit download velkeho souboru pokud jiz mate podobny. SLAX vydava vzdy dva soubory, jednak ISO pro vypaleni na CD, pak TAR pro rozbaleni na USB disk; soubory se lisi jen velmi malo, ale kazdy ma cca 200MB. Prestoze autor SLAX zsync soubory nevytvari, nasel jsem pouzitelne soubory na jinem webu; ukazka, ze zsync nemusi nutne delat autor…
1) slax-6.1.1.iso → slax-6.1.2.iso (cca 80% uspora):
$ zsync -i slax-6.1.1.iso http://psl.ic.cz/zsync/slax-6.1.2.iso.zsync
2) slax-6.1.2.iso → slax-6.1.2.tar (velmi rychle, stahuje se jen 189kB dat):
$ zsync -i slax-6.1.2.iso http://psl.ic.cz/zsync/slax-6.1.2.tar.zsync
3) slax-6.1.1.iso → slax-6.1.2.tar (cca 80% uspora; pokud jsme provedli krok 2, pak uspora 100%):
$ # rm slax-6.1.2.tar # nepracujeme prilis efektivne… :-)
$ zsync -i slax-6.1.1.iso http://psl.ic.cz/zsync/slax-6.1.2.tar.zsync -
uz vime, ze poradny a chytry HTTP server by mel umet dodat nam pouze vyzadanou cast souboru, pokud soubor nechceme cely (pocatecni offset je soucasti requestu a pri dosazeni offsetu konce pozadovanehou useku souboru proste closneme spojeni)
a ze HTTP i nejakym zpusobem zvlada posilat kontrolni soucty souboru (i kdyz ve svete dynamickych webovych stranek na posilani takovych hlavicek vetsina PHP newbies zvysoka kasle).
teoreticky by nemel byt problem upravit server tak, aby tyto dve vlastnosti zkombinoval a posilal nam hash vyzadane casti souboru (hashe muze cachovat na zaklade timestampu modifikace souboru).
kdyz by toto http protokol specifikoval, mohl by zsync jednoduse nahradit nas oblibeny prikaz
wget -c URL -
me (neregistrovaný)
zsync ale nepracuje tak, ze by pozadoval od serveru hash nejake casti souboru. Takto pracuje rsync, cimz vznika na strane serveru vypocetni zatez (coz je duvoud, proc je tak tezke najit verejne servery s podporou rsync). zsync potrebuje ridici soubor, kde je kazdy blok souboru (typicka veliost bloku je 4kB) otisknut v podobe kontrolniho souctu (zjednoduseno). Tato informace (nenazyval by jsem to hash) se spocita jen jednou a jiz se nemeni. zsync si stahne tento popis souboru a pokusi se v dostupnych lokalnich datech (stare CD, atd) najit shodne bloky (ktere mohou byt klidne na jinych pozicich). Pokud se mu to podari, pouzije je. Pokud ne, chybejici useky souboru stahne z http serveru, pouziva se hlavicka range, velikost stahovanych bloku nemuseji byt nutne nasobkem 4kB (pokud se v lokalnich datech najdou dva 4kB bloky oddelene 543 chybejicimi daty, stahuje se jen chybejicich 453B…)
Zajimave je, ze pokud mate velmi rychle pripojeni a vykonny http server, dokaze WGET ziskat velky soubor rychleji, nez ZSYNC. Zrejme to souvisi s rizenim toku dat a buferovanim, mozna take ze „range“ neni implementovana na strane serveru optimalne, protoze vetsina klientu nepouziva „range“ tak intenzivne, jako zsync. WGET casto dokaze stahnout vice dat rychleji, nez ZSYNC mene dat. Pokud se soubory hodne lisi, WGET stahne data rychleji.
Pokud se podovate na hlavicku genrovanou zsync, tak to muze byt hodne divoke, treba tady:
Host: cdimage.ubuntu.com
Referer: http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.iso.zsync
Range: bytes=12910592–12955647,12976128–13139967,13152256–13877247,13922304–14270463,14307328–14311423,14348288–14352383,14430208–14434303,14585856–20189183,20205568–22876159,23699456–24178687,24219648–24338431,24363008–24367103,24387584–28774399,28790784–28794879,28803072–28852223,28868608–28872703,28884992–29073407,29093888–29102079,29122560–29290495,29319168–29323263
ČLÁNKY DO MAILU