Fórum Root.cz
Hlavní témata => Software => Téma založeno: Benda 11. 12. 2013, 20:20:06
-
Chci se zeptat ?
převáděl někdo z Vás pomocí rsync cca 6TB dat
ja to právě zkouším a jsem zmaten.
na serveru jsem si pomoci nfs přimapoval nové uložište a spustil nad tím rsync
problem je, že na cílovém disku je použito více místa než na zdrojovém
a rsync pořád běží
-
https://lists.samba.org/archive/rsync/2009-April/023023.html
-
Proč používáš nfs, když to chceš synchronizovat pomoci rsync? Není lepsi pracovat primo rsync -avz server:/zdroj /cil ?
Jinak pokud se ti zda, ze na cilovem disku to zabira vetsi velikost, muze to byt klidne tim, ze na zdrojovym jsou hardlinky.
-
Rsync není něco, v čem bych se stoprocentně vyznal, ale je třeba taky vědět, o kolik větší a jakým způsobem jsou naformátovány jednotlivé souborové systémy, tedy především jakou mají velikost sektoru. V situaci, kdy bude na disku větší množství malých souborů, jejich velikost bude zarovnaná k velikosti sektoru a pokud tato bude odlišná, mohou se údaje o velikosti souborů lišit.
Osobně, pokud kontroluji chyby v nějaké záloze, tak jedna z věcí, kterou využívám, je find ./ > výpis_originálu.txt a obdobně pro kopii. Porovnám si je pomocí diff. Ještě jsem nekontroloval správnost zápisu souborů, ale když by to bylo třeba, daly by se soubory upravit tak, ať vypisují (například) md5 kontrolní součet pro každý soubor a porovnat výsledek.
-
rsync nepřenáší nezměněná data – pokud přenášíte 6 TB na čistý disk, bude se muset přenést 6 TB, stejně, jako kdybyste data normálně kopíroval (ve skutečnosti se kvůli režii přenese ještě víc, pokud nemáte soubory s opakujícími se bloky dat). rsync má v takovémhle případě „jen“ tu výhodu, že mu nevadí výpadek – prostě jej spustíte znova se stejnými parametry, a rsync dokopíruje to, co ještě chybí.
rsync je potřeba pouštět tak, aby se nad nejužším místem přenosu (třeba internet) používal právě rsync protokol. Pokud tedy budete přenášet data přes internet nebo přes lokální síť, je potřeba, aby to síťové spojení bylo řešené přes rsync, ne třeba přes NFS. Pokud si přes internet připojíte disk přes NFS a pak „lokálně“ spustíte rsync, musí se přes síť přenést celý soubor, lokálně se pak zjistí, že je stejný a zahodí se.
Co se týče rozdílné velikosti, mohou to být různě velké bloky, hardlinky, řídké soubory…
-
Proč používáš nfs, když to chceš synchronizovat pomoci rsync? Není lepsi pracovat primo rsync -avz server:/zdroj /cil ?
Jinak pokud se ti zda, ze na cilovem disku to zabira vetsi velikost, muze to byt klidne tim, ze na zdrojovym jsou hardlinky.
Napadlo te treba ze mnohem pravdepodobnejsi je ze na jenom filesystemu ma vytvorene 4K bloky a na druhem 512B bloky? pokud ma spousty malych souboru muze to delat neplechu....
-
Chci se zeptat ?
převáděl někdo z Vás pomocí rsync cca 6TB dat
ja to právě zkouším a jsem zmaten.
na serveru jsem si pomoci nfs přimapoval nové uložište a spustil nad tím rsync
problem je, že na cílovém disku je použito více místa než na zdrojovém
a rsync pořád běží
Prevadim i 12TB kdyz zalohuju... a problem v tom nevidim... jen by to chtelo 10Gbits sitovky pokud to budes delat casteji
-
Prevadim i 12TB kdyz zalohuju... a problem v tom nevidim... jen by to chtelo 10Gbits sitovky pokud to budes delat casteji
Při takhle velkých datech už je mnohem lepší použít nějaký FS, který má dobře řešené snapshoty. Pak se opravdu přenáší pouze změněné věci a nemusí se kontrolovat všechna data, aby se vědělo, co se změnilo.
-
Napadlo te treba ze mnohem pravdepodobnejsi je ze na jenom filesystemu ma vytvorene 4K bloky a na druhem 512B bloky? pokud ma spousty malych souboru muze to delat neplechu....
FS s bloky 512 B jeste nekde existuje? Treba na Ext3 nenastavite mene, nez tusim 1O24 B a default pro velke disky byva spise vetsi, tedy typicky maximum, ktere je 4096 B.
-
Tak jsem to ověřil
na obou FS používám ext4
block size 4096
-
Tak pozor změna velikost se srovanala :) a rsync stále běží
-
Ten odkaz co jsem posílal všichni ignorují? Je to tam vysvětleno.
-
Ten odkaz co jsem posílal všichni ignorují? Je to tam vysvětleno.
Ocividne :) Mimochodem to ale nevysvetluje, proc by to narostlo vyazne vice, max. o velikost jednoho souboru, ne?
-
Ten odkaz co jsem posílal všichni ignorují? Je to tam vysvětleno.
Ocividne :) Mimochodem to ale nevysvetluje, proc by to narostlo vyazne vice, max. o velikost jednoho souboru, ne?
Zahada bermunského trojúhelníku je tady =D
-
výpis využitého místa
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/skupina-data 7.2T 6.6T 291G 96% /samba
192.168.77.29:/mnt 8.1T 6.8T 934G 89% /donkey
takže opravdu záhada :-D
-
To na toho osla mate namontovano pres sshfs? Neni mozne, ze to pres sshfs spatne reportuje vyuziti FS? Neni mozne, ze sshfs neco jinak zaokrouhluje nebo neco a vy dostanete spatny udaj? Zkousel jste to po prihlaseni pres ssh? Jestli se dobre pamatuji, tak kdysi sshfs snad ani neumelo vylistovat velikost souboru v adresari a vracelo to nulu nebo co.
Vite, jestli v tech datech mate harlinky, jak nekdo zminil? Rsync vam z nich nadela oddelene soubory, pokud mu parametrem nereknete, ze ma ty hardlinky hledat, ale pak to bezi strasne pomalu.
-
Pro spoustu souborů (milióny) není 6,6 a 6,8TB místa na disku žádný zásadní rozdíl. Jak již zde bylo řečeno, jako první bych udělal výpis všech souborů s jejich velikostmi a porovnal.
-
Tak já to zkusím ještě jednou. TMP vám zvětší velikost. Někdo oponoval, že jen jeden soubor. Ale co když to jede ve více threadech, což bych považoval za samozřejmost?
-
Když už je to nakopírované, na opakované zkopírování (synchronizaci) je rsync ideální. Na kompletní novou kopii je rychlejší cp nebo tar se streamem po síti (bez ssh, napřímo přes netcat).
Jinak rsync pro hodně souborů žere spoustu paměti.
-
A pokud není paměť, swap. A jsme tam kde jsem říkal?
-
Co se týká rozdílu velikostí, přidávám se k odhadu ostatních výše. Rozdíl může být díky jiným parametrům souborovému systému.
Zobrazovaná hodnota při použití "du -hs" bere v potaz fyzické rozložení dat na něm a je to vždy víc, než prostý součet velikostí souborů. Takže např. pokud chci základně srovnat celkové velikosti zkopírovaných adresářů mezi dvěma počítači, téměř nikdy to nesedí. GNU varianta utility du, používaná v Linuxu, má ale i přepínač "--aparent-size", s kterým sčítá jen čisté velikosti.
Jinak používám rsync poměrně dost na přesuny velkého množství dat i mezi různými platformami a nedá se paušálně říct, že je vždy rychlostně lepší použít nativní rsync přenos (rsync -> rsyncd). Většinou vychází líp použití nad lokálně připojeným NFS, i když to samozřejmě není pravidlem. Další věc, která pomáhá, je obrácení procesu, kdy si připojím zdrojový server a "tahám" data na lokální disk. V tomto případě pomůže i volba "--preallocate", pokud cílový souborový systém používá extenty (ext4, xfs).
Jinak rsync nepřenáší víc souborů naráz, což beru pro tohle použití (přesun dat mezi servery s rychlým úložištěm v LAN) jako jeho největší nevýhodu, protože na současných konfiguracích (rychlost sítě a disků) by se z toho dalo dostat daleko víc. Proto se občas vyplatí si zdrojová data rozdělit do víc adresářů a pak pustit několik rsynců paralelně.
Michal
-
Co se týče rozdílu velikostí, může to mít asi tak milion důvodů. Vzhledem k tomu, že jediné, co víme, je název programu, který byl použit pro kopírování, těžko některé z důvodů vyloučit. Mohou to být různé souborové systémy, různé konfigurace souborového systému, data mohou být jinak uložená (hardlinky, řídké soubory), mohou tam být soubory s jiným obsahem (na cílovém disku už něco bylo a rsync nebyl nastavený, aby to smazal, nějaké soubory se po zkopírování změnily nebo smazaly na zdrojovém disku)...
Pokud tazatele zajímá důvod, proč jsou velikosti rozdílné, bude asi muset prozradit další informace. Bylo by vhodné taky zjistit, jestli se velikostí liší "vše", nebo jestli se postupným porovnáním jednotlivých podadresářů nedí ukázat na jedno místo, které způsobuje ten rozdíl.
-
Další věc, která pomáhá, je obrácení procesu, kdy si připojím zdrojový server a "tahám" data na lokální disk. V tomto případě pomůže i volba "--preallocate", pokud cílový souborový systém používá extenty (ext4, xfs).
Na --preallocate pozor, může se to bít s delayed allocation a výkon nakonec může být nižší!
-
Další věc, která pomáhá, je obrácení procesu, kdy si připojím zdrojový server a "tahám" data na lokální disk. V tomto případě pomůže i volba "--preallocate", pokud cílový souborový systém používá extenty (ext4, xfs).
Na --preallocate pozor, může se to bít s delayed allocation a výkon nakonec může být nižší!
To za určitých okolností samozřejmě může nastat a je potřeba vždy ozkoušet přínos na konkrétní konfiguraci a typu přenášených dat. Nemyslel jsem to tak, že to automaticky zrychlilo ve všech případech proces synchronizace, ale dle mých zkušeností převážně s XFS a video daty (sekvence obrázků a mnohagigabytové soubory) to stojí za vyzkoušení, zejména při použití paralelního spouštění více rsync procesů, jak jsem psal. Jinak to samozřejmě vždy záleží na implementaci systém. volání fallocate() u konkrétního soub. systému.
Michal