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í
×
včera 22:00 | Komunita

Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil (podcast) detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 64 tisíc vývojářů. Jejich nejmilovanější platformou je linuxový desktop. Ten je také druhou nejpoužívanější platformou vývojářů.

Ladislav Hagara | Komentářů: 1
24.3. 11:55 | Komunita

Vývojový tým OpenSSL ve spolupráci s iniciativou Core Infrastructure konsorcia Linux Foundation spustil proces přelicencování této kryptografické knihovny ze současné licence na licenci Apache Licence v 2.0 (ASLv2). Nová licence usnadní začleňování OpenSSL do dalších svobodných a open source projektů. Všichni dosavadní vývojáři OpenSSL (Authors) obdrží v následujících dnech email s prosbou o souhlas se změnou licence.

Ladislav Hagara | Komentářů: 21
24.3. 01:11 | Komunita

Před třemi týdny Mozilla.cz představila projekt Photon, jehož cílem je návrh a implementace nového vzhledu Firefoxu. Včera zveřejnila první náhled vzhledu Photon. Práce na projektu Photon jsou rozděleny do pěti týmů, které celkem čítají 19 lidí. Zaměřují se na zlepšení prvního spuštění Firefoxu a zaujetí nových uživatelů, celkovou úpravu vzhledu, zlepšení animací, zrychlení odezvy uživatelského rozhraní a také upravení nabídek. Vývoj lze sledovat v Bugzille.

Ladislav Hagara | Komentářů: 44
23.3. 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 6
23.3. 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
23.3. 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
23.3. 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 30
23.3. 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
23.3. 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
23.3. 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 937 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    12.2.2016 00:00 CandySan | skóre: 9 | blog: bonzacek
    Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Přečteno: 338×

    Zdar odbornici!

    Nevyznam se v potrebnych detailech v tom, co vsechno se deje na disku, jak casto se tam co meni a kde, kdyz nemam na mysli jen samotna data.

    Mam nasledujici scenar:
    KVM virtualky pouzivaji jako disky lvm logicke svazky (raw). Tyto zalohuju na jiny pocitac tak, ze nejprve necham lokalne vytvorit komprimovane kopie. Potom je pomoci rsync k sobe stahuje zalohovac (dirvish - ten je take iniciatorem lokalni pripravy dat) s tim, ze stahuje k sobe jen rozdilna data a po siti netece cely obraz disku.

    Zjistil jsem, ze kdyz pouziju lzo komprimaci, tak je to nejen rychle, kdyz ma lzo rychlost v popisu prace, ale zaroven neni prilis velky rozdil ve vysledne velikosti oproti gzipu a hlavne jsou komprimovane vysledky datove velmi podobne predchozim komprimovanym souborum z predeslych zaloh.

    Speedup se na ruznych serverech s ruznymi daty virtualnich disku pohybuje klidne az kolem 300 (jinde 9, jinde 46, jinde 110...) zatimco s gzipem to bylo vzdy jen 1,0x.

    Takze kdyz kouknu namatkou na nejaky server, tak vidim, ze celkova pripravena data jsou o velikosti 63GB a skutecne prenesenych dat po siti bylo jen 569MB.
    Dirvish uklada data tak, ze soubory bez zmeny jen linkuje a tim vyznamne setri misto (deduplikace), ale soubory s jakoukoliv zmenou do nove zalohy nakopiruje cele (sestavi je z predchozich ulozenych dat, proto se po siti prenese jen tech 569MB ale na disku potom pribude celych 63GB, ktere tam ted uz lezi 2x - jednou z predchozi zalohy a podruhe z aktualni zalohy).

    Az sem je to jasne a neni co resit. Funguje to tak uz leta.

    Jenze spekuluju nad tim, jak ukladat jen rozdily tech zaloh? Mam vsak obavu, ze uloha nema reseni, ale nez to zcela zavrhnu, tak zkousim, zda vas nekoho nenapadne reseni v tomto bode.

    Napadlo me neco, co se ukazalo jako slepa ulicka. Zkusil jsem vysledny soubor jednoduse rozdelit na spoustu malych casti. Klidne treba na 1000 kousku rozsekany puvodni disk a mylne jsem doufal, ze z te tisicovky malych kousku bude cela rada tech, ktere nemaji zadnou zmenu. cekal jsem tedy, ze kdyz probehne nekolik takovychto zaloh, tak se ukaze, ze spousta tech malych fajlu budou stejne (na zalohovaci tedy jen linky) a ze tim nakonec usetrim spoustu mista, Jenze ne! Kazdy jeden file byl vzdy zmeneny! Vzdy v nem byla zmena i kdyz jsem udelal zalohy hned po sobe v rozmezi jekolika minut behu systemu! Nenasel se ani jediny kousek, ktery by nemel zmenu! Rikal jsem si, ze zkusim udelat totez bez komprimace, ale taky bez vysledku! Zmena v kazdem kousicku!

    Ja vlastne ani nevim odkud se tuhle zmeny berou? Je divne, ze by v kazdem kousku disku (resp. takhle rovnomerne rozlozene) doslo k nejakemu zapisu, ne?
    I informace o datu pristupu se (snad?) uklada na zacatek disku, ne?
    Pokud by data pri rozdelovani byla nejak posunuta, tak by to muselo (snad?) byt posunute v celem ukladanem fajlu nejak a tak by ani rsync nebyl tak moc uspesny, ne..?

    Mam tedy k vyse uvedenmu 2 otazky:
    1. odkud se berou ty zmeny v celem objemu dat?
    2. kdyz by se rozlustil bod 1, tak ucelem toho vseho je docilit nejak toho rozdiloveho zalohovani. Nejlepe tedy rozdelenim na kousky, ktere se nemeni a ty ktere se meni... ale i zcela jiny pohled na rozdilovou zalohu obrazu disku by mne velmi obohatil. K vyse uvedenemu dodavam, ze se jedna o ruzne FS uvnitr tech zalohovanych disku a deje se to u vsech. Format LVM disku je raw.

    Dekuju za pripadnou pozornost.


    Řešení dotazu:


    Odpovědi

    Jendа avatar 12.2.2016 04:18 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    btrfs snapshoty a rsync --inplace by mohly pomoct - čekal bych, že se díky principu CoW budou ukládat jen změněné bloky. Pokud by nějak nefungovaly snapshoty, tak cp --reflink a pak rsyncovat do toho. Pokud navíc použiješ compress volbu btrfs a -z volbu rsyncu, tak nemusíš kompresi řešit vůbec.
    Speedup se na ruznych serverech s ruznymi daty virtualnich disku pohybuje klidne az kolem 300 (jinde 9, jinde 46, jinde 110...) zatimco s gzipem to bylo vzdy jen 1,0x.
    gzip --rsyncable
    Pokud by data pri rozdelovani byla nejak posunuta, tak by to muselo (snad?) byt posunute v celem ukladanem fajlu nejak a tak by ani rsync nebyl tak moc uspesny, ne..?
    rsync posunutí řešit umí.

    Ale tady nevím, to budou spíš nějaká metadata FS.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    12.2.2016 10:46 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Diky, volbu --rsyncable jsem si nikdy v manualu nevsimnul a koukam, ze tam fakt je! Tak to vysvetluje lecos :-)

    Btrfs budu stran teto veci zkoumat casem, ale zatim jsem chtel tezit z toho, ze v lvm svazku to jede nejrychleji.
    Řešení 1× (CandySan (tazatel))
    Jendа avatar 12.2.2016 11:04 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Já nemyslel, že budeš virtuály provozovat z btrfs, ale že budeš rsyncovat do brtfs. Tj. v místě, kam zálohuješ, budeš mít btrfs, a vždycky uděláš snapshot a rsyncneš --inplace.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    12.2.2016 11:15 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Jo aha! To uz zni zjimave! Tak tohle stoji za zkoumani! Diky moc!
    12.2.2016 13:02 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Hele, to je genialni!! Jak tak nad tim spekuluju a studuju veci kolem toho, tak tohle resi spoustu mych pozadavku! Nechapu, ze me nenapadlo vubec timto smerem uvazovat..? Btrfs jsem si vzdy spojoval s tim zalohovanym mistem a automaticky jsem to zavrhoval kvuli rychlosti, ale ani jednou me nenapadlo o tom uvazovat v miste zalohy!

    Presne tohle jsem potreboval!! Diky moc!! :-)
    12.2.2016 18:20 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    Tak bohuzel jsem nepochodil dobre :-(

    Vytvoril jsem testovaci btrfs oddil o velikosti 15GB. Vytvoril jsem v nem subvolume a nakopiroval jsem do nej 10GB velky image. Vytvoril jsem snapshot, spustil jsem virtualku, aby se do fajlu udelaly nejake drobne zmeny a zase jsem ji vypnul.

     

    Potom jsem rsyncem s parametrem --inplace kopiroval tento file do toho jiz existujiciho fajlu v btrfs. Po chvili doslo misto a kopirovat uz dal neslo.

     

    Zkusil jsem to cele znovu s malym souborem, ktery zaplnil btrfs mnozstvim dat 3,2GB. Opet jsem vytvoril snapshot, potom jsem udelal drobne zmeny ve zdroji a opet rsync --inplace. Po nejake chvili zaclo obsazeni rust a dosahlo urovne 6,4GB.

     

    Nakonec jsem jeste zkusil cp --reflink. Opet se po vytvoreni dle ocekavani zabrane misto nezvetsilo. Po kopirovani (rsync --inplace) drobne zmeneneho fajlu se opet zabrane misto zvetsilo na 6,4GB.

     

    Zda se, ze i btrfs se chova tak, ze kdyz ve fajlu doslo ke zmene, tak ho potom zkopiruje/sestavi cely a ten zmeneny file tam potom zabira celou svoji velikost tolikkrat, kolikkrat je tam zmeny :-(

     

    Delam jeste nekde chybu? Nebo se to vazne ma chovat takto?

    Jendа avatar 12.2.2016 18:39 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Teď jsem to zkusil a mně to funguje. Všechny balíčky distribuční z Debianu Unstable.
    /mnt/nofrag # head -c $(( 500 * 1000 * 1000 )) /dev/urandom > rnd
    /mnt/nofrag # sha1sum rnd 
    03c01e21d2e8207969017c1ff43f94c2987b1fc1  rnd
    /mnt/nofrag # cp rnd btrfs/
    /mnt/nofrag # btrfs subvolume snapshot btrfs/ btrfs/snap1
    Create a snapshot of 'btrfs/' in 'btrfs/snap1'
    /mnt/nofrag # df -H btrfs
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/loop0      2,2G  519M  1,5G  27% /mnt/nofrag/btrfs
    /mnt/nofrag # dd if=/dev/urandom bs=128k seek=500 of=rnd conv=notrunc count=1
    1+0 records in
    1+0 records out
    131072 bytes (131 kB, 128 KiB) copied, 0,0251772 s, 5,2 MB/s
    /mnt/nofrag # dd if=/dev/urandom bs=128k seek=1000 of=rnd conv=notrunc count=1
    1+0 records in
    1+0 records out
    131072 bytes (131 kB, 128 KiB) copied, 0,0231493 s, 5,7 MB/s
    /mnt/nofrag # dd if=/dev/urandom bs=128k seek=1287 of=rnd conv=notrunc count=1
    1+0 records in
    1+0 records out
    131072 bytes (131 kB, 128 KiB) copied, 0,0262798 s, 5,0 MB/s
    /mnt/nofrag # dd if=/dev/urandom bs=128k seek=2287 of=rnd conv=notrunc count=1
    1+0 records in
    1+0 records out
    131072 bytes (131 kB, 128 KiB) copied, 0,0237689 s, 5,5 MB/s
    /mnt/nofrag # l rnd 
    -rw-r--r-- 1 root root 500M úno 12 18:37 rnd
    /mnt/nofrag # sha1sum rnd 
    0e78704dcd8c53fc8e3ab081a4819b2b59a22471  rnd
    /mnt/nofrag # rsync --inplace --partial --stats --progress rnd btrfs/rnd 
    rnd
        500,000,000 100%  226.19MB/s    0:00:02 (xfr#1, to-chk=0/1)
    
    Number of files: 1 (reg: 1)
    Number of created files: 0
    Number of deleted files: 0
    Number of regular files transferred: 1
    Total file size: 500,000,000 bytes
    Total transferred file size: 500,000,000 bytes
    Literal data: 500,000,000 bytes
    Matched data: 0 bytes
    File list size: 0
    File list generation time: 0.001 seconds
    File list transfer time: 0.000 seconds
    Total bytes sent: 500,122,142
    Total bytes received: 35
    
    sent 500,122,142 bytes  received 35 bytes  200,048,870.80 bytes/sec
    total size is 500,000,000  speedup is 1.00
    /mnt/nofrag # df -H btrfs
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/loop0      2,2G  519M  1,5G  27% /mnt/nofrag/btrfs
    /mnt/nofrag # sha1sum rnd 
    0e78704dcd8c53fc8e3ab081a4819b2b59a22471  rnd
    /mnt/nofrag # sha1sum btrfs/rnd 
    0e78704dcd8c53fc8e3ab081a4819b2b59a22471  btrfs/rnd
    /mnt/nofrag # sha1sum btrfs/snap1/
    sha1sum: btrfs/snap1/: Is a directory
    /mnt/nofrag # sha1sum btrfs/snap1/rnd 
    03c01e21d2e8207969017c1ff43f94c2987b1fc1  btrfs/snap1/rnd
    
    Použil jsi --partial?
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    12.2.2016 19:22 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    Ano! Mas pravdu!

     

    Kdyz jsem zkusil stejny test, tak to opravdu obsazeni nezvetsilo! Zmenil jsem tedy jen kousek souboru a chovalo se to spravne dle tveho popisu.

    Chyba je tedy jinde...

     

    Zkusil jsem pridat k --inplace pro jistotu i --partial, ale vysledek byl zase spatny - zase se zdvojnasobilo obsazeni.

     

    Zkusil jsem to tedy znovu a abych vyloucil problem s nastavenim rsync, tak jsem zkusil nahradit rsync za dd. Takze jsem spustil virtualku, nabehnul system, hned jsem ho zase vypnul a pomoci dd jsem zkopiroval obsah disku do souboru v btrfs.

    Vysledek byl zase spatny!! Takze problem je jeste nekde jinde a nebude ani v rsync. Jeste bych mel zkusit si ten file vykopirovat jinam, udelat do nej jen drobnou zmenu a zkusit dd, zda to prepsani celeho obsahu nema zpusobit zdvojeni taky, ale tentokrat z jineho duvodu - se se to opravdu prepisuje i kdyz z casti stejnymi daty (abych se nezatoulal do slepe ulicky).

    Jeste bych mel zkusit stejne nastaveni rsync a soubor nekde mimo taky jen drobne zmenit. Pokud by to vse vyslo, tak by to znamenalo, ze tech zmen se v tom virtualnim disku odehraje az prilis mnoho..? Uvidim jeste...

    12.2.2016 19:35 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    Tak jsem to zkusil jeste takto:

    Vytvoril jsem file mimo ten btrfs disk.
    Zkopiroval jsem ho do subvolume.
    Udelal jsem snapshot.
    Pozmenil jsem ten soubor mimo btrfs.
    Zkusil jsem jej pomoci rsync --inplace --partial zkopirovat do subvolume.
    Obsazene misto se zdvojnasobilo.

    Takze predbezny zaver je, ze kdyz ten file zmodifikuju primo na miste, tak se to chova tak jak rikas ty. Tedy ze se ukladaji skutecne jen ty drobne zmeny.

    Neumim zatim docilit toho, abych do zalohy promitnul z venku jen ty zmeny, protoze pak se ulozi cely file znovu.

    Kazdopadne stopa je spravna a diky moc za nasmerovani.

    Jendа avatar 12.2.2016 20:00 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    Zkusil jsem jej pomoci rsync --inplace --partial zkopirovat do subvolume.
    To je fakt zvláštní, když použiješ přesně ty příkazy tak, jak jsem to udělal já, tak ti to taky nefunguje?

    Mám rsync 3.1.1 a kernel 4.3.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    12.2.2016 20:08 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    To mi prave funguje! Potvrzoval jsem, ze mas pravdu a ze se to i u me chova ocekavanym zpusobem.

    Zkusil jsem i dalsi testy s modifikacemi fajlu primo na miste - v btrfs, kdyz od nej existuje snmapshot a potvrzuju, ze mas pravdu, ze se ukladaji jen ty bobecky, ktere se zmenily.

     

    Ted jsem dokonce zkusil rozbehnout virtualku nad btrfs zatimco jiz existoval snapshot a chtel jsem vedet, zda tech zmen je tolik, ze se nakonec ten file ulozi cely, nebo zda se taky ulozi jen bobecky. Vysledek je, ze takhle to funguje perfektne a ukladaji se opravdu jen bobecky! Obsazeni disku se nezvetsuje a tedy nedochazi k dvojnasobnemu obsazeni jako kdyby tam byl ten soubor 2x.

     

    Nakonec se ale ukazalo, ze to co nedokazu je ten pripad, kdy ten samy file menim naprosto stejnym zpusobem a jen ho chcio dostat do zalohy (treba i jen v ramci jednoho pocitace lokalne). Tehdy nedokazu toho hezkeho chovani dosilit a vzdy se mi zmeneny soubor uklada tak, ze naroste jeho velikost jako kdyby tam byl opravdu fyzicky 2x...

     

    Takze ted je uz jasne, ze btrfs se chova spravne, ale neni jasne jak toho docilit i pro kopirovane nebo synchronizovane soubory.

    Jendа avatar 12.2.2016 20:12 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume
    To mi prave funguje! Potvrzoval jsem, ze mas pravdu a ze se to i u me chova ocekavanym zpusobem.
    No právě ne. Já ho měnil v /mnt/nofrag (ext4) a pak jsem změněnou verzi rsyncnul do /mnt/nofrag/btrfs a obsazené místo se nezvětšilo. Tedy přesně to, co chceš.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    12.2.2016 20:20 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    Pardon. Tak tohle mi prave nefungovalo. Kdyz jsem to zmenil venku mimo btrfs a zkousel jsem to prenest do subvolume od nehoz existuje snapshot, tak doslo vzdy k tomu zdvojeni.

    Dulezite ted je, ze tobe to chodi tak jak potrebuju, takze muzu zkoumat jeste na jinych pocitacich postupne...

    Ja ted mam jadro 4.2 a rsync taky 3.1.1

    12.2.2016 20:32 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    Jeste jsem to cele zkusil znovu, protoze ja mel vytvoreni jeste uvnitr subvolume a teprve z nej jsem delal snapshot, tak jsem si rikal, ze zkusim tom udelat tak jak to mas ty - snapshot bez subvolume...

    Zkusil jsem to a vysledek je stejny (pro me spatny).

    Jeste chci upozornit na to, ze to trva asi pul minuty nez se poromitne to zvetseni.

    Takze presne tvuj priklad vypadal u me pred kopirovanim takto:
    /dev/mapper/vg-btest         15G  495M   13G   4% /mnt/tst

    a asi po pul minute od skonceni kopirovani to poskocilo takto

    /dev/mapper/vg-btest         15G  940M   13G   8% /mnt/tst

    Zatimco kdyz jsem to menil primo v tom btrfs svazku, tak k tomu nedoslo ani po minute - chovalo se to spravne.

    Řešení 1× (CandySan (tazatel))
    13.2.2016 13:41 CandySan | skóre: 9 | blog: bonzacek
    Rozbalit Rozbalit vše Re: Rozdilova zaloha obrazu virtualniho disku; KVM; LVM volume

    BINGOOOO!!!

    Prisel jsem na to! rsync musime pouzit s parametrem --inplace a --no-whole-file


    Zkousel jsemten tvuj soubor rnd, ktery mi zbyl ze vcerejska. Zkopiroval jsem ho, pak jsem udelal snapshot, pak jsem do nej nasazel nova data na ruzna mista (tak jak jsme to zkouseli vcera).

    Situace vypada latakto:

    /dev/mapper/vg-btest         15G  495M 13G   4% /mnt/tst

    Potom jsem prenesl zmeny (rsync --inplace --no-whole-file --progress --stats /rnd /mnt/tst/pokus/) a pockal jsem az se obsazeni zmeni (asi to souvisi s commit, protoze to je defaultne 30s) a vysledek je nasledujici:

    /dev/mapper/vg-btest         15G  496M 13G   4% /mnt/tst

     

    Takze chyba byla u me!

    Jendo, moc dekuju!! Kdyz jsem ten dotaz zacal psat, tak jsem skoro ani nedoufal, ze zaziju takovehle vanoce :-) Diky moc!!

    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.