kruska blogja

Mini.WebVM: Your own Linux box from Dockerfile, virtualized in the browser via WebAssembly

Egy rádióamatőr pikoballon eltűnt, ami már 124 napja a levegőben volt, és már 7x megkerülte a Földet. Akkor szakadt meg vele a kapcsolat, amikor a vadászgépek kilőtték az "azonosítatlan repülő tárgyat".

Gondoltam összeszedek pár izgalmasabb dolgot az LTO szalagokról / driveokról, hátha valaki mostanában szemez ilyen backup megoldással.

Nagyobb lélegzetű VM módosításkor (OS / alkalmazás update, bonyolultabb install) az ember természetesen készít egy VM snapshotot, amiből kényelmes és gyors visszaállni szükség esetén. Néha viszont igény lehet arra is, hogy ezeket a snapshotokat elmentsük / elarchiváljuk hosszabb ideig, tovább, mint ameddig a Hyper-V snapshotok általában megmaradnak.

A klasszikus módszer szerint átkergethetjük az adatfolyamot egy (vagy több) pv-n, és akár párhuzamosan nézhetjük a progressbarokat.

Viszont lehet olyan eset, amikor nem szeretnénk pipe-okat használni (pl. bufferelési vagy blokkméret beállítások miatt), ilyenkor egyszerűen küldhetünk a tar processznek egy SIGUSR1 szignált, akár rendszeresen, mondjuk percenként, crontab-ban időzítve:

* * * * * root pkill -SIGUSR1 tar

A tar-t pedig megkérjük arra, hogy legyen kedves ezeket a SIGUSR1-eket menet közben elkapni, és rá mindig olyan módon reagálni, hogy kiírja a pillanatnyi statisztikáit. 

lxc03:/mnt/ctdev02/sapdata # tar cf /dev/nst0 DISKD0051 --totals=USR1
Total bytes written: 14206033920 (14GiB, 354MiB/s)
Total bytes written: 39681720320 (37GiB, 376MiB/s)
Total bytes written: 65241937920 (61GiB, 394MiB/s)
Total bytes written: 87778324480 (82GiB, 384MiB/s)
Total bytes written: 115248916480 (108GiB, 396MiB/s)

Ha nem adjuk meg a --totals=USR1 kapcsolót, és mégis megkapja a SIGUSR1-et, akkor megáll 138-as returnkóddal, egyébként csak kiírja az adott pillanatban, és a végén rc0-val áll meg (vagy amivel amúgy állt volna meg).

Eddig mindig tar-ral írtam szalagra, az alapbeállításokkal. Ezzel nem is volt semmi baj, de szembejött néhány doksi, hogy lehetne ezt optimálisabban is, például a blokkméret növelésével.

TL;DR: Paraméterezéssel két-háromszorosára lehetett gyorsítani a tar/dd LTO írási/olvasási sebességét az alapértelmezetthez képest

Egy LTO-5 eszközt használva ezt kapom:

Adott egy host /64 IPv6 alhálózattal, amiben szeretnék IPv6-only LXC konténereket indítani, ugyanabból az alhálózatból kiosztva a címeket. Megörökíteném a későbbiekre a számomra legegyszerűbbnek tűnő megoldást. Egy Hetzner VPS-en kísérletezgetés közben szedegettem össze a lentieket, ott egyszerűen reprodukálható a folyamat.

Egy hónapja lecseréltem a 12-es Macbookomat egy M1-es Pro-ra, és eltökéltem, hogy nem fogok Rosettát telepíteni, fusson minden natívan.

Ami eddig pipa, és üzemszerűen használom:

Mai felfedezés: egy folyamat többpontos mérése.

dd if=/dev/xvdj | pv -s 5G -cN dd | gzip | pv -cN gzip > /var/www/virtual/xvdj_var-log.img.gz

       dd: 1.67GB 0:00:39 [48.1MB/s] [===============>                                        ] 33% ETA 0:01:17
     gzip:  105MB 0:00:39 [ 883kB/s] [                                    <=>                 ]