Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: Ja Host 06. 11. 2017, 21:41:11
-
Zdravím, existuje způsob jak vytvořit kopii adresáře a neustále ho držet aktuální? Díky
-
Ano.
-
Co asi znamená to "P" v JardaP??
Zkuste upřesnit, jak to myslíte s tou kopií. Ideální a okamžitou kopií je princip RAIDU, tedy data dvakrát zároveň propsaná. Ale to asi nemáte na mysli. Popíšete, prosím, Vaši situaci?
-
Mám adresář a ten potřebuji mít na dvou místech stále stejný a nesmí to být nějaký symlink. Musí to být plnohodnotné adresáře a soubory.
-
Mám adresář a ten potřebuji mít na dvou místech stále stejný a nesmí to být nějaký symlink. Musí to být plnohodnotné adresáře a soubory.
Zapisovat se bude jen do jednoho, druhý bude nějaká o maličko zpožděná kopie? Stále nerozumím tomu případu, možná kdybyste ho popsal celý od začátku?
-
Mám prostě adresář a potřebuji po spuštění systému vytvořit přesnou kopii toho adresáře. Zapisovat se bude do obou. Zpoždění není problém.
-
Mám prostě adresář a potřebuji po spuštění systému vytvořit přesnou kopii toho adresáře. Zapisovat se bude do obou. Zpoždění není problém.
Pak je nejvhodnějším řešením rsync - ten lze použít i když jsou obě strany lokální.
-
To jsem zkoušel ale ono to jen zkopíruje ten adresář ale pozdější změny se nikde neprojví :(
-
sice stale nejasnej dotaz, ale napr. tohle proste dela to, ze neustale provadi synchronizaci, kopiruje vzdy jen to zmenene, maze to ve zdrojovem adresari smazane, ponechava atributy vsech souboru/adresaru:
while true; do rsync --archive --delete --one-file-system /odkud /kam; done
-
while true; do rsync --archive --delete --one-file-system /odkud /kam; done
Toto je ale jen jednosměrné...
Stejně mi vrtá hlavou usecase pro takto šílený nápad, aby nešel řešit nějakou inteligentnější metodou.
-
Obousměrně synchronizuje např. unison, diskutovaný zde pořád dokola. Ovšem musíš si ošetřit kolize, např. volbou prioritního strany, která má při řešení kolize přednost.
Zvládá rychle i velké stromy, protože si udržuje lokální DB stavu.
-
Ja nevim, co tady porad resite. Az dosud se tazatel ani neuraci sdelit, na jakem to chce OS. Ale pokud to tedy ma byt na Linuxu, tak asi man inotifywait z inotify-tools.
-
...
Já hlavně soudím, podle toho, jak pan tazatel neumí ani popsat svoji situaci, ani říct, jestli to má být jednosměrné, obousměrné, po startu systému, průběžně, bez zpoždění, se zpožděním, ..., že vymýšlí nějakou opičárnu... Buďto se stydí popsat use case, nebo ho popsat ani neumí (pak by měl věnovat víc času analýze), nebo řeší nějaký úkol do školy (bez use casu).
-
Ja nevim, co tady porad resite. Az dosud se tazatel ani neuraci sdelit, na jakem to chce OS. Ale pokud to tedy ma byt na Linuxu, tak asi man inotifywait z inotify-tools.
Jardo, neserte mě, víte, jak nerad s Vámi souhlasím!! Gr.
-
Replicated volume v GlusterFS.
-
....nebo řeší nějaký úkol do školy (bez use casu).
To je desna predstava. Vzdyt treba za 20 let by mohl delat IT ve statni sprave a dokonce o tom treba rozhodovat....
BTW, dotaz jiz byl vycerpavajicim zpusobem zodpovezen mym prvnim prispevkem, tak nevim, co se porad snazite.
-
BTW, dotaz jiz byl vycerpavajicim zpusobem zodpovezen mym prvnim prispevkem, tak nevim, co se porad snazite.
Ano.
-
Tou "situací" zřejmě myslíte důvod, proč to potřebuje. Mě zas zajímá, k čemu to potřebujete vědět. Aby jste mu pak mohli vymluvit, že to vlastně nepotřebuje ?
-
Tou "situací" zřejmě myslíte důvod, proč to potřebuje. Mě zas zajímá, k čemu to potřebujete vědět. Aby jste mu pak mohli vymluvit, že to vlastně nepotřebuje ?
Nepotřebuji to vědět, ale pan tazatel nedokázal dobře popsat svůj dotaz a spousta lidí tu tipuje, co měl vlastně na mysli. Když se podíváte na vlákno, tak hned moje první odpověď bylo řešení. Situace se začala zamotávat, až po upřesňování.
A ano, pokud někdo začne vymýšlet auto o pěti kolech, aby mělo větší nosnost, místo toho, aby koupil náklaďák, tak je možné, že odpověď bude, že to nepotřebuje, respektive, že se situace řeší jinak.
-
To jsem zkoušel ale ono to jen zkopíruje ten adresář ale pozdější změny se nikde neprojví :(
Rsync sesynchronizuje soubory v okamžiku, kdy je spuštěn. Takže jej samozřejmě musíte spouštět opakovaně. Psal jste o spuštění systému, tak si přidáte skript po spuštění systému, který bude ten rsync spouštět. Pokud chcete synchronizovat častěji, můžete použít třeba systemd-timer nebo cron.
-
Tak jestli tim rsyncem bude syncovat adresare s velkymi poctem souboru, tak se z toho system posere a bude travit cas tim, ze bude mlatit disky na obou stranach - tedy pokud se jedna o dve strany a ne dva adresare na jenom disku. Lepsi by bylo vyzkoumat, jestli pres inotify utility nelze rsyncu nabonzovat konkretni soubor ci seznam zmenenych souboru.
-
Lepsi by bylo vyzkoumat, jestli pres inotify utility nelze rsyncu nabonzovat konkretni soubor ci seznam zmenenych souboru.
Lepší by bylo, kdyby napsal, o co mu jde, protože se tím zjistí, že ve skutečnosti potřebuje třeba "mount -o bind", http://bindfs.org/ nebo ACLka.
-
@Jenda: Ano, bylo. Vsak take neodpovidam tazateli, ktery patrne uporne premysli, co vlastne chce, ale Jirsakovi, zatimco jini tu odpovidaji jinym, ale ne tazateli nebo rozviji teorie, o cem by tak asi mohl byt dotaz a na ty pak zase odpovidaji jini. Je to takova plodna diskuse, jejimz ucelem je vymyslet dotaz, po jehoz precteni tazatel vykrikne: "Ano, presne na to jsem se chtel zeptat."
-
Je to takova plodna diskuse, jejimz ucelem je vymyslet dotaz, po jehoz precteni tazatel vykrikne: "Ano, presne na to jsem se chtel zeptat."
Já myslím, že tazatel už dávno odevzdal domácí úkol, a dál nás nečte :).
-
Já myslím, že tazatel už dávno odevzdal domácí úkol, a dál nás nečte :).
Hm, ten bych si rad precetl a zajimala by mne znamka.
-
Lepsi by bylo vyzkoumat, jestli pres inotify utility nelze rsyncu nabonzovat konkretni soubor ci seznam zmenenych souboru.
To samozřejmě lze. Jenže když se pustíte do takhle sofistikovaného řešení, zjistíte, že tam vlastně může docházet k souběhu, a že to vlastně obecně, bez znalosti konkrétní aplikace, moc uspokojivě řešit nelze.
Ale vzhledem k tomu, že tazatel úspěšně tají, co vlastně řeší za problém, nečekal bych, že se bude jednat o velký objem dat nebo počet souborů. Spíš půjde o nějaký uživatelský profil nebo něco takového.
-
To samozřejmě lze. Jenže když se pustíte do takhle sofistikovaného řešení, zjistíte, že tam vlastně může docházet k souběhu,
Napriklad kde? Pokud mate na mysli, ze se vam rozbehne X rsyncu, coz cely prenos zpomali, jak se budou pretahovat o disk, tak to se da resit tak, ze se jich proste vic nepusti, dokud jeden bezi a pozadavky na sync se budou psat do souboru a ten se preda naslednemu rsyncu.
-
Hm, ten bych si rad precetl a zajimala by mne znamka.
Ta asi bude úměrná jakosti takového zadání :).
-
To samozřejmě lze. Jenže když se pustíte do takhle sofistikovaného řešení, zjistíte, že tam vlastně může docházet k souběhu,
Napriklad kde?
Hlavně v tom, že od okamžiku, kdy inotify zaznamená změnu, do okamžiku, než to zpracuje rsync, uběhne nějaká doba, po kterou se ten soubor může dál měnit, být smazán, znovu vzniknout. Může se zdát, že to ničemu nevadí, že to nakonec bude ve správném stavu, ale to právě záleží na okolnostech. Třeba asi nebude chtít synchronizovat soubor, do kterého se ještě zapisuje, takže budete čekat na jeho uzavření. Jenže než ho po uzavření stihnete zkopírovat, začne se do něj znovu zapisovat. A na druhé straně pak budete mít nějakou podivnou rozpracovanou verzi souboru, který v té podobě ani ve zdrojovém adresáři nikdy nemusel existovat. Navíc nevím, jak se bude rsync tvářit na soubor, který se mu mění pod rukama.
-
Pouzij Microsoft OneDrive anebo Disk Google pro udrzovani sdilenych adresaru stejneho obsahu na vice mistech.
-
Hlavně v tom, že od okamžiku, kdy inotify zaznamená změnu, do okamžiku, než to zpracuje rsync, uběhne nějaká doba, po kterou se ten soubor může dál měnit, být smazán, znovu vzniknout. Může se zdát, že to ničemu nevadí, že to nakonec bude ve správném stavu, ale to právě záleží na okolnostech. Třeba asi nebude chtít synchronizovat soubor, do kterého se ještě zapisuje, takže budete čekat na jeho uzavření. Jenže než ho po uzavření stihnete zkopírovat, začne se do něj znovu zapisovat. A na druhé straně pak budete mít nějakou podivnou rozpracovanou verzi souboru, který v té podobě ani ve zdrojovém adresáři nikdy nemusel existovat. Navíc nevím, jak se bude rsync tvářit na soubor, který se mu mění pod rukama.
Toz to se resi prave tim, co jsem napsal. Jestlize uz mi bezi rsyncovany skript, tak se misto spusteni dalsi kopie zapise soubor do seznamu, ktery se preda nasledujicimu behu. Vas prispevek me akorat privadi k tomu, ze se v tom seznamu budou muset overovat duplicity, aby se nersyncovalo do aleluja porad dokola uplne zbytecne.
Bohuzel me nenapada, jak to dostatecne inteligentne udelat, aby se nesyncovaly ty otevrene soubory a zaroven zajistit, aby se aspon obcas syncovaly. Snad leda pridani timeoutu u souboru, u kterych v seznamu byla nalezena duplicita, pricemz by take bylo dobre si poznamenavat cas, kdy se tam ten soubor dostal poprve a pokud tam trci jiz po urcitou dobu, tak ho syncovat i otevreny/prubezne modifikovany, i kdyby trakare padaly. Takze bychom asi skoncili u kombinace cronjobu a inotify spousteneho skriptu. Byl by asi dost opruz ten skript nebo spis skripty napsat.
Ostatne s otevrenymi a casto prubezne modifikovanymi soubory bude zapolit i nejaka ta sync utilita od zmineneho OneDrive anebo Disk Google.
Ostatne sync souboru, ktere tam trci uz vic, jak urcity cas, by sel asi oblafnout pres parametr --modify-window.