Binární patchování velkých souborů

7.9.2022 16:11 | Přečteno: 1508× | Jen tak na okraj | poslední úprava: 12.9.2022 10:18

Potřeboval jsem najít optimální řešení k aktualizovaci velkých binárních souborů. Možná bude mít někdo z vás tip ještě na jiné řešení, ale já vyzkoušel následující tři (vyjmenováno vzestupně od nejhoršího k optimálnímu): xdelta3, rdiff, rsync.

K testovací účelům jsem si vyrobil přes mksquashfs dva velké binární soubory, ze dvou různých snapshotů adresáře s komplet nainstalovaným Debianem. Starší byl vytvořen 30. března 2020, před aktualizací a druhý 3. dubna 2020, když už bylo vše odladěno.

Zde si k vaší smůle neodpustím malou reminescenci. Neboť právě tehdy začala obyvatelstva ČR začala lámat všeobecná hysterie, která mimo jiné, vyhnala studenty ze škol. Nikdo na takovou situaci nebyl připraven, jenom já zaplesal štěstím protože jsem měl najednou dost času na to, abych implementoval do laboratorního disklessu dlouhodobě plánované úpravy, které měly za cíl umožnit studentům práci na strojích v počítačových laboratořích z domova.

Jak ti pozornější z vás už vědí, má zvýšená pracovní aktivita vyžaduje úměrně tomu zvýšenou míru duševní hygieny, takže jsem během výše vymezeného období jednoho měsíce napsal za účelem vypláchnutí hlavy tyto blogposty:

• Pozor na odsazení zakomentovaných řádků (26.3.2020)
• Záhadné samospouštění počítačů (27.3.2020)
• Ostře sledovaná úmrtí (6.4.2020)
• Taky vás serou Číňani? (15.4.2020)
• Jak se léčíte? (25.4.2020)
• Číňané v USA (27.4.2020)

Z profesního hlediska to byla krásná doba, protože mi všeobecná paralýza z neobvyklé situace, spojená s absencí vyučujících i studentů v laboratořích, umožnila pracovat bez toho, že by na mne někdo tlačil, nebo chtěl abych dělal něco jiného. Takže jsem mohl o pět měsíců později, když ve vzduchu visela otázka zda se po 21. září 2020 bude učit prezenčně nebo distančně, s klidnou duší poznamenat, že laboratoře jsou už od jara připraveny na obě varianty.

Ale přejděme k hlavnímu tématu.

Ze staršího subvolume s cca 22GB dat vylezl přes mksquashfs soubor old.image o velikosti 11GB. Z novějšího (cca 20GB) vypadnul soubor new.image 9,2GB. To bylo na můj vkus trochu moc dat na to, aby se takové soubory opakovaně tahaly ze stroje na stroj sem a tam po síti. Proto mne zajímalo:

1. Jak bude velký rozdílový soubor.
2. Kolik času zabere jeho vytvoření.
3. A jak rychle poběží patchování na novější verzi souboru.

xdelta3

Je utilita, kterou jsem zkoušel naposled. Vlastně jenom ze zajímavosti. A výsledky měla tak příšerné, že na ni milerád zapomenu. Takže jen pro úplnost. Pro vytvoření rozdílového souboru image.delta jsem použil následující příkaz:

~# xdelta -e -s old.image new.image image.delta

Trvalo to příšerných 43 minut, a výsledkem byl rozdílový soubor image.delta o velikosti 6GB. To mi stačilo a jen pro úplnost jsem ještě vyzkoušel vytvoření patchovaného souboru xdelta.image:

~# xdelta -d -s old.image image.delta xdelta.image

To už naštěstí proběhlo poměrně rychle (55 sec.) a kontrolní součet souboru xdelta.image odpovídal kontrolnímu součtu souboru new.image. Ale pro značnou velikost rozdílového souboru už jsem nic dalšího (např. slučování rozdílových souborů) nezkoušel.

rdiff

Tuhle utilitu jsem testoval jako první, protože jsem ji stejně musel nejdřív doinstalovat. Někomu se to může zdát jako drobnost, ale pro mne je důležité aby nástroj, který se má použít pro aktualizovaci souboru byl standardní součástí instalace. Což bohužel nebyl tento případ. Ale nešť.

Důležitá je totiž také velikost, byť ve srovnání s objemem zpracovávaných souborů zanedbatelná. A rdiff má pouhých 15kB a jen minimum závislostí.

Vytvoření rozdílového souboru v tomto případě proběhlo ve dvou krocích. Nejprve bylo potřeba vygenerovat pro výchozí starší soubor old.image signaturu, datový soubor signature.file, nezbytný pro vytvoření delta souboru, se změnami.

~# rdiff signature old.image signature.file

Tahle operace zabrala nějakých 22 sekund. A pak bylo možné přistoupit k vytvoření souboru rdiff.delta se změnami.

~# rdiff delta signature.file new.image rdiff.delta

Docela to trvalo (protože jsem ještě netušil co mě čeká), ale po 14 minutách z této operace vypadnul soubor rdiff.delta o velikosti 579MB. A to nebylo špatné. Takže bylo možné přistoupit k opatchování souboru old.image.

~# rdiff patch old.image rdiff.delta rdiff.image

Rychlost, s jakou proběhlo patchování mne překvapila. Nový soubor rdiff.image byl vytvořen během 8 sekund a kontrolní součet byl v pořádku. Delší čas, potřebný pro vytvoření rozdílového souboru by se dal zkousnout, ale víceméně náhodou jsem narazil na jednu nepříjemnou vlastnost, která mne od použití této utility odradila, i když by v reálu nemusela možná vadit. Zmíním se o ní v následující části.

rsync

Přiznám se, že jsem netušil, že bych tento nástroj využít i takovým způsobem. A tak jsem byl mile překvapen. Nejenom tím jak je to jednoduché, ale i tím, jak dlouho jednotlivé operace trvaly.

Funguje to tak, že se nejprve vygeneruje rozdílový soubor, v mém případě pojmenovaný rsync.delta:

~# rsync --only-write-batch=rsync.delta new.image old.image

Zaskočilo mne, jak rychle tahle operace proběhla, protože za minutu a půl bylo hotovo a velikost rozdílového souboru rsync.delta byla jen o 47MB větší, než součet velikostí souborů nezbytných pro rdiff – 689MB. Proto jsem byl zvědav jak dopadne aktualizace staršího souboru.

Ovšem v tomto bodě jsem se dopustil chyby, která mne následně přivedla k potenciálně problematickému chování utility '''rdiff'''.

Utilita '''rsync''' totiž aplikuje změny na původní, starší soubor. A já, místo abych ho zkopíroval a vytvořil soubor nový, aplikoval změny v rozdílovém souboru přímo na něj. Takto:

~# rsync --read-batch=rsync.delta old.image

Zhruba po půl minutě bylo hotovo a kontrolní součet byl stejný jako u souboru new.image. To bylo velmi pěkné, ale přišel jsem tím o testovací soubor, protože byl zaktualizován. A tak jsem se jal vyrábět, ze stejného snapshotu soubor nový. Stejným způsobem jako prvně, ovšem až na jeden detail – zapoměl jsem odstranit aktualizovaný soubor s názvem old.image.

Ukázalo se, že utilita mksquashfs cílový soubor nepřepisuje, nýbrž aktualizuje. Takže obsah image ze 3. dubna byl nahrazen starší verzí z 30. března. Výsledkem byl tudíž jiný soubor, než původně. Nicméně, když už jsem tuhle chybu udělal, zkusil jsem vyzkoušet, jak si poradí rsync a rdiff když se pokusím na takový soubor aplikovat již vygenerované rozdílové soubory.

Nejprve jsem vyzkoušel rdiff, který nic nepřepisuje a vytváří nový soubor. Ten ho bez keců schroupnul, ale výsledek měl pochopitelně jiný kontrolní součet, než soubor new.image. To nebylo pěkné.

Když jsem tutéž operaci vyzkoušel s utilitou rsync, tentokrát na kopii omylem aktualizovaného souboru old.image, nebyly aplikovány žádné změny. Kontrolní součet zůstal stejný.

Pro další pokus jsem si vygeneroval stejný výchozí soubor jako prve, abych se ujistil, jestli mksquashfs vyrobí stejný soubor. A skutečně, kontrolní součet odpovídal tomu, jaký měla původní verze new.image. A s aktualizací tohoto souboru na novější už neměl rsync žádný problém.

Závěrem

Pravděpodobně využiju ten rsync, i když je o něco větší. To, jakým způsobem funguje mi vyhovuje, protože není nutné řešit starší verze souborů a já už vím jak zajistit, aby se vždy stáhnul ten správný rozdílový soubor. Zbývá jenom vymyslet odkud a přes jaký protokol, aby s tím bylo nejmíň cavyků.

Pokud jde o situaci ve škole, situace je trochu jiná, než byla před dvěma lety. Z mého pohledu ovšem výrazně horší, protože semestr začíná na můj vkus neúměrně brzy (19. září 2022). Je dost těžké skloubit dovolenou, kterou si musíte vybrat, s nejrůznějšími akcemi, které se plánují do období, kdy výuka neprobíhá. A najít dostatečně velké časové okno, kdy se ještě nepracuje v laboratořích, ale jsou zároveň k zastižení ti co ten laboratorní systém využívají, aby se včas vychytaly případné problémy. Dřív, než začne výuka a v laborkách opět začnou vysedávat studenti.

A tak jsem rád, že se mi podařilo realizovat alespoň dlouho plánované sjednocení uživatelských účtů. Bohužel přesun, vzhledem k množství naakumulovaných uživatelských dat, trval déle než jsem původně plánoval. Takže jsem přehodil prioritu následujících úkolů a původně plánovanou velkou aktualizaci odsunul až na zimu.

Číňany jsem přestal řešit přes fail2ban. Tedy přesněji řečeno přes jeho filtry. Jejich drzost už neznala mezí, takže je banuji rovnou hlava nehlava, dobrý, špatný, po celých subnetech. Žádný zajímavý obsah pro ně stejně nemám. A nevěřili byste jak díky tomu spadlo průběžné zatížení serveru.

A zcela závěrem pár slov k tomu umírání.

Z našich prarodičů zatím nikdo neumřel. Jenom otec měl v srpnu namále. Nechal si disciplinovaně píchnout čtvrtou dávku a jeho oslabený imunitní systém sejmula nějaká infekce tak, že skončil na dva týdny ve špitále. Nicméně se z toho zvetil, i když to vypadalo už velmi zle. Ne že by zrovna umřel. To by na tom asi bylo to nejmilosrdnější. Ale nedělám si iluze. 86, 86, 8̶3̶ (†10.9.2022), 82, 81, 80,… maximální věková hranice dožití jak ze strany mojí, tak ze strany ženy byla (u žen) 92 let. Pro muže bývala konečná do 80 let. Z nich se nejvíce let dožil otcův bratranec, který zemřel ve věku 88 let, v pondělí ráno 3.2.2020, na infarkt v ordinaci praktického lékaře. Měsíc před tím, než vypukla všeobecná kovidová hysterie.

       

Komentáře

[Max]

Známý také málem zemřel. Měl dost štěstí v neštěstí. Přes padesát, celý život žádný problém, týden ho bolela noha (skoro jako natažený sval, ale horší a zhoršovalo se to), tak se rozhodl, že zajde k lékaři. Zkolaboval na schodech před budovou. Jeho první štěstí bylo, že byl ještě při vědomí, když pro něj přijela sanitka. Stačil jim popsat, že ho bolela noha a teď nemůže dýchat. doktor si uvědomil, že jde o embolku a jeli rovnou na specializované oddělení, kde okamžitě šel na přístroje.
Když tam dorazil, srdce down. Jeho druhé štěstí bylo, že ho masírovali nadstandardní čas. Myslím, že říkal, že po hodině to vzdávají. Přišel jim ještě asi mladý, tak to zkoušeli dál a nahodili ho asi za 70min.
Do konce života bude brát prášky na ředění krve. Do té doby neměl žádné problémy se srážlivostí apod. Zda na to měl vliv covid, očkování apod., to není průkazné.

Každopádně k technické části. Ten obraz, který se snažíš syncovat, to je Linux, nebo Windows? Já jen, že pokud Linux, tak proč nevyužít balíčkovací systémy? Myslím, že od takových věcí je třeba Ubuntu Core, který funguje na bázi větších balíků a je právě určen k podobným nasazením, ne?
Zdar Max

[Want]

To je úplně jedno, co je obsahem binárního balíku. Máš prostě balík A, který potřebuješ nahradit balíkem B, a máš u nich při tom velkou shodu.

[Want]

Cílem je, aby byl proces proměny A na B co nejrychlejší, s minimální pravděpodobností selhání. Jak si možná vzpomeneš, náš disklessový linux je v podstatě sendvič složený z několika vrstev, které se mění jen občas. No a mne loni napadlo, jak toho využít k tomu, abych byl disklessový Linux spouštěný přes wi-fi zcela autonomní tj. aby se obešel bez konektivity.

P.S.: Chtěl jsem ti to napsat už v tom předchozím komentu, ale dorazil mezi tím náš chlupatý budík, pro svou pravidelnou ranní ranní dávku pomazlení.

[jiwopene]

Co třeba btrfs s jeho snapshoty a sync/receive? Nebude to nejefektivnější, ale změna proběhne prakticky okamžitě.

[Aleš Kapica]

Kde jsi přišel na to, že s těmito nástroji nepracuji? Nevím teda jaké máš s nimi zkušenosti ty, ale já mnohaleté.

Pro zajímavost uvedu příklad z dob, kdy jsem v rámci disklessové infrastrutury spravoval také uživatelské účty. Teď už je neřeším, protože jsou na úložišti, které spravuje někdo jiný.

Tehdejší infrastrukturu tvořil několikanodový cluster a zálohy se sypaly na lokální disky. Co účet, to subvolume. Jinak bys jen stěží mohl používat kvóty. Bylo to desetitisíce snapshotů. A zažil jsem jednou pěkně horkou chvilku, kdy jsem čekal několik hodin než se mi to namountuje. Všechno klaplo, ale byl jsem orosený až na zadku. No a když jsem pak slučoval zálohy z těch lokálních disků na jedno místo, bylo potřeba to všechno sklepat tak, aby se to vešlo na disk. Já vím. Dnes v době 10TB HDD to už nikdo moc neřeší, ale hovořím o době před pěti lety.

V podstatě mi jde o to, minimalizovat objem přenášených dat, tak aby po síti běhalo jen to co je nezbytně nutné. Problém je, že u disklessu vlastně nikdo pořádně neví kolik dat se přenese, když stroje najednou zapne X studentů. Já si tuhle otázku položil, když jsem zkoušel řešení postavené nad Ganeshou, což byl rok 2016. Ovšem jak velkou roli to hraje jsem zjistil u disklessu provozovaného přes wi-fi, který používá lokální kešování. Jenže to má bohužel několik slabin. Ale dnes jsem podnikl praktický pokus, který mi dal uspokojivou odpověď, jak se jim vyhnout. Teď je ale na řadě konsolidace infrastruktury.

[Daheim]

Pro srazlivost krve je rizikovym faktorem vek i covid, ktery zvysuje srazlivostni faktory. Manzelcin vzdaleny pribuzny (59 let, hubeny, sportovec, optimista) covid dostal, mel lehky prubeh, dychalo se mu uz celkem dobre, byl doma, a embolie plic a bylo to. Doktor rikal, ze by stacilo, aby bral injekce na redeni krve stejne tak, jako berou seniory pri domacim pobytu treba se zlomeninou. Opravdu by mne zajimalo, kolik lidi kvuli tomuto podceneni srazlivosti zemrelo.

[Aleš Kapica]

Je všeobecně známo, že do nějaké analýzy nikdo nepůjde, protože by to šlo proti zájmům všech co z toho profitovali. Navíc by to vyžadovalo přístup k údajům, ke kterým tě nikdo jen tak nepustí. A také lidi, jejichž čas by musel někdo zaplatit.

[Max]

Injekce na ředění krve se v případě zlomeniny apod. věcí dávají dnes skoro každému.
Zdar Max

[Gréta]

supr záplata :O ;D