Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Mám už několik produkčních hostů, všichni jsou typu qemu plná virtualizace s HW podporou, s image ve formátu qcow2 a jsou na cLVM svazcích. Hledal jsem, jak je efektivně zálohovat.
Úvodem bych poznamenal, že zacházení s LVM svazky je trochu míň pohodlné než by bylo zacházení s image ve formě souborů. Jenže když mám image jako soubor, je přístup virtuálního hosta na disk o desítky procent pomalejší než ke stejnému disku přímo od hmotného hostitele. To jsem zjistil už před pár lety na XEN virtuálech a ověřil jsem, že to teď platí i pro KVM virtuály. Asi to bude tím, že když chce host něco udělat s n-tým diskovým blokem, vytvoří system call, ten dostane jádro hostitele a teď musí proběhnout seek v souborových službách hostitele. Oproti tomu LVM jde přímo na bloky.
Nejasně jsem tušil, že správná záloha image znamená udělat snapshot image a ten nějak zazálohovat a poté smazat tak, aby se image běžícího hosta o ničem nedozvěděl. Moji hosté byli vytvořeni pomocí virt-install, takže k tvorbě a zpracování snapshotů máme na výběr qemu snapshoty třeba podle návodu tady,
nebo virtlib snapshoty podle Kashyapa. Zkoušel jsem to oboje a podle určitých drobných rozdílností v chování bych hádal, že virtlib má svoje vlastní metody, jak zacházet se snapshoty, i když v podstatě musí používat stejné KVM konstrukce jako qemu. Pro uživatele je to vždycky takové, že doposud živý image se najednou zmrazí a je z něj snapshot, zatímco další změny páchané živým hostem jdou někam jinam, třeba do nového LVM svazku čerstvě vytvořeného. Není to copy-on-write, jen prosté zapisování do nového místa. Po zpracování snapshotu potřebuju zapsané bloky zkopírovat zpátky do původního image, k tomu slouží
qemu-img commit <ten nový prostor>
a následně se ten nový dočasný prostor může zlikvidovat. Jak se analogická operace udělá ve virsh jsem nějak nepochopil (což asi nebude vina virtlibu).
Když mám vytvořený snapshot, rád bych se podíval, co v něm je. Na to ho musím napřed vyexportovat do jakoby blokového zařízení, a k tomu slouží
qemu-nbd -c /dev/nbd0 <ten snapshot> .
Pomocí fdisk se teď můžu podívat na strukturu virtuálního disku, a dopadne to např. takhle:
# fdisk -u -l /dev/nbd0 Disk /dev/nbd0: 21.5 GB, 21474836480 bytes 255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ec934 Device Boot Start End Blocks Id System /dev/nbd0p1 * 2048 40136703 20067328 83 Linux /dev/nbd0p2 40136704 41940991 902144 82 Linux swap / Solaris #Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech. Jestliže je na oblasti nbd0p1 souborový systém, třeba půjde namontovat read-only:
Když se nechceme trápit s offsety, je tady podle jednoho návodu taková finta,
která se mi líbí nejvíc ze všech vyguglených fint na tohle téma:
modprobe -r loop && modprobe loop max_part=63
mount -r /dev/nbd0p1 /mnt
Česky řečeno, když si odloadujeme defaultně natažený modul pro loop zařízení a zase ho natáhneme s nenulovou hodnotou parametru max_part, tak nám losetup namapuje nejen zadané zařízení jako /dev/loop# , ale také všechny jeho oblasti jako bloková zařízení /dev/loop#p## .
Až nás hrátky s obsahem snapshotu omrzí, je dobré nezapomenout všechno uklidit. Napřed všechny umount, potom všechny losetup -d a nakonec všechny qemu-nbd -d .
Spolehlivost snapshoťáckých postupů jsem se snažil testovat tím, že jsem ve zkušebním hostovi pořád dělal manipulace se soubory a při tom jsem vytvářel, prohlížel a zase rušil snapshoty. Dvakrát mi při tom došlo k nevratnému narušení image, kdy mi ten host bez výstrahy spadnul. Mohlo to být chybou manipulace, ale podezření na chybu mechanismu snapshotů stejně mám. Nikomu ho nevnucuju, zkuste si to sami.
Mount snapshotu zaživa není tak úplně nezbytná věc, ale bez něj je život o něco těžší. Takže se mi zdá důležité, že read-only mount popsaný výše se dost často nedá udělat. Není divu, virtualizační nástroj nic neví o filesystémech hosta a tak jsou file systémy ve snapshotu obecně v nekonzistentním stavu. fsck by to asi srovnal, ale to si na živém snapshotu nemůžeme dovolit. Snapshot můžeme zajisté někam zkopírovat a už v neživém stavu na něj udělat qemu-nbd -c a potom s ním pracovat už read-write. Když ale nepracujeme se soubory ale s LVM svazky, je to trochu nepraktické. A při tom právě při práci s LVM svazky, protože tam máme LVM 2, můžeme v poklidu použít LVM snapshoty. Má to samé výhody a nenapadla mě žádná nevýhoda. Takže to máme
lvcreate --size 20g --snapshot --name debil.snap /dev/VIRTUALY/debil
a po odzálohování zase
lvremove VIRTUALY/debil.snap
a to je všecko. Při testování jsem nezaregistroval žádný problém. Se živým LVM 2 snapshotem se dá klidně zacházet read-write a nic se tím nezkazí. Můžeme klidně i fsck, když na to máme náladu. Nebo to není potřeba, protože i samotný read-write mount si u některých filesystémů dokáže udělat recovery a to stačí. Tohle chování jsem pozoroval u ext3. Mount -r při intenzívním diskovém provozu na hostu většinou nešel, read-write mount mi šel vždycky. Takže na zálohování budu používat LVM snapshoty a qemu snapshoty tady budou na řešení problémů, kdy si potřebujeme schovat i obsah operační paměti.
Tiskni
Sdílej:
Diskuse byla administrátory uzamčena
Dobrá finta u fdisku je volbička -u , údaje o oblastech jsou potom spolehlivě v 512 B sektorech.platí u starších fdisků jako je ten v RHEL6, u novějších (IIRC rok a půl starých a novějších) už -u naopak zapíná kompatibilitu s DOSem. Ad pády - nainstalit debug balíčky, zapnout coredumpy, vytáhnout backtrace a do bugzilly s tím! Jinak podle libvirtích vývojářů bylo na první implementaci živých snapshotů znát, že byly spíchnuty horkou jehlou pro potřebu oVirta - třeba proto, že neuměly pracovat s trvalými doménami. :) Jinak v nadcházející verzi oVirtu by už živé snapshoty neměly být ochuzeny o RAM - viz.