Byl vydán Debian 13.5, tj. pátá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.14, tj. čtrnáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
CiviCRM (Wikipedie) bylo vydáno v nové verzi 6.14.0. Podrobnosti o nových funkcích a opravách najdete na release stránce. CiviCRM je robustní open-source CRM systém navržený speciálně pro neziskové organizace, spolky a občanské iniciativy. Projekt je napsán v jazyce PHP a licencován pod GNU Affero General Public License (AGPLv3). Český překlad má nyní 45 % přeložených řetězců a přibližuje se milníku 50 %. Potřebujeme vaši pomoc, abychom se dostali dál. Pokud máte chuť přispět překladem nebo korekturou, přidejte se na platformu Transifex.
Další lokální zranitelností Linuxu je ssh-keysign-pwn. Uživatel si může přečíst obsah souborů, ke kterým má právo ke čtení pouze root, například soubory s SSH klíči nebo /etc/shadow. V upstreamu již opraveno [oss-security mailing list].
Singularity (YouTube) je nejnovější otevřený film od Blender Studia. Jedná se o jejich první 4K HDR film.
Vyšla hra Život Není Krásný: Poslední Exekuce (Steam, ProtonDB). Kreslená point & click adventura ze staré školy plná černého humoru a nekorektního násilí. Vžijte se do role zpustlého exekutora Vladimíra Brehowského a projděte s ním jeho poslední pracovní den. Hra volně navazuje na sérii Život Není Krásný.
Společnost Red Hat představila Fedora Hummingbird, tj. linuxovou distribuci s nativním kontejnerovým designem určenou pro vývojáře využívající AI agenty.
Hru The Legend of Zelda: Twilight Princess od společnosti Nintendo si lze nově díky projektu Dusklight (původně Dusk) a reverznímu inženýrství zahrát i na počítačích a mobilních zařízeních. Vyžadována je kopie původní hry (textury, modely, hudba, zvukové efekty, …). Ukázka na YouTube. Projekt byl zahájen v srpnu 2020.
Byla vydána nová major verze 29.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Detailní přehled novinek na GitHubu.
Po zranitelnostech Copy Fail a Dirty Frag přichází zranitelnost Fragnesia. Další lokální eskalace práv na Linuxu. Zatím v upstreamu neopravena. Přiřazeno ji bylo CVE-2026-46300.
Sovereign Tech Agency (Wikipedie) prostřednictvím svého fondu Sovereign Tech Fund podpoří KDE částkou 1 285 200 eur.
dd ktorý poznáme z minula.hdparm na prácu s parametrami pevného disku, a jednoduchý testík jeho rýchlosti.fio z rovnomenného balíka (flexible I/O tester).hdparm ktorý vie otestovať výkon diskovej cache a aj čítania priamo z disku. Nutno podotknúť že tento test je moc krátky a testuje sa len začiatok disku. Preto by sa mal vykonať viac krát za sebou, a systém by mal byť v kľude.hdparm s parametrom na otestovanie rýchlosti disku (malé t).
root@web:~# echo 1 > /proc/sys/vm/drop_caches root@web:~# hdparm -t /dev/sd[ab] /dev/sda: Timing buffered disk reads: 348 MB in 3.01 seconds = 115.57 MB/sec /dev/sdb: Timing buffered disk reads: 558 MB in 3.02 seconds = 184.88 MB/secAko vidíme, tak čítanie zo SSD je oproti pôvodnému HDD v našom prípade ani nie 2 krát rýchlejšie.
SWAP na začiatku disku.root@web:~# echo 1 > /proc/sys/vm/drop_caches root@web:~# dd if=/dev/sda of=/dev/null bs=8M status=progress iflag=sync 500107862016 bytes (500 GB, 466 GiB) copied, 5509 s, 90.8 MB/s 59617+1 records in 59617+1 records out 500107862016 bytes (500 GB, 466 GiB) copied, 5509.07 s, 90.8 MB/s root@web:~# dd if=/dev/sdb of=/dev/null bs=8M status=progress iflag=sync 239855468544 bytes (240 GB, 223 GiB) copied, 928 s, 258 MB/s 28617+1 records in 28617+1 records out 240057409536 bytes (240 GB, 224 GiB) copied, 928.725 s, 258 MB/sTu už vidíme že daný SSD je cca 3 krát rýchlejší pri čítaní. Na jednu stranu nám klesla priemerná rýchlosť HDD len 90MByte/s (720Mbit/s), na druhú stranu nám narástla priemerná rýchlosť SSD na 258 MByte/s (2064 Mbit/s). Holt, čítanie na začiatku HDD je rýchlejšie ako na jeho konci. A podobne je čítanie nevyužitého miesta na SSD rýchlejšie ako toho využitého. Prečo ten rozdiel rýchlosti medzi využitým a nevyužitým miestom na SSD? Nuž, ten predinštalovaný OS z testu som tam nechal. Zišiel sa.
Bežný prístup na blokové zariadenia, akými je aj HDD, je náhodný prístup. Teda prístup, kde sa pred čítaním sektorov veľmi často aj skáče na rôzne pozície. Teda napríklad počúvame hudbu alebo pozeráme film z pevného disku, a zároveň sťahujeme novú verziu voľne dostupnej distribúcie.
Na tento typ testu je najlepšie spustiť špecializovaný nástroj, v našom prípade to budefio s parametrami emulujúcimi bežné využitie domáceho počítača (prehrávanie hudby z disku, čítanie novín, a zálohovanie fotiek z mobilu na disk):Ako prvé si ten SSD ale pripojíme:
root@web:~# mkdir -p /mnt/SSD/boot/efi root@web:~# mount /dev/sdb2 /mnt/SSDTak, a môžeme si spustiť test pre obidva disky, začneme testom rotačného disku:
root@web:~# echo 1 > /proc/sys/vm/drop_caches
root@web:~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=32 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.1
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=1572KiB/s,w=456KiB/s][r=393,w=114 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=8527: Fri Jan 3 18:19:46 2020
read: IOPS=100, BW=401KiB/s (411kB/s)(3070MiB/7834248msec)
bw ( KiB/s): min= 7, max= 1992, per=100.00%, avg=425.71, stdev=163.73, samples=14764
iops : min= 1, max= 498, avg=106.38, stdev=40.94, samples=14764
write: IOPS=33, BW=134KiB/s (137kB/s)(1026MiB/7834248msec)
bw ( KiB/s): min= 7, max= 784, per=100.00%, avg=154.92, stdev=64.23, samples=13556
iops : min= 1, max= 196, avg=38.68, stdev=16.06, samples=13556
cpu : usr=0.38%, sys=1.34%, ctx=1035664, majf=1, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwt: total=785920,262656,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: bw=401KiB/s (411kB/s), 401KiB/s-401KiB/s (411kB/s-411kB/s), io=3070MiB (3219MB), run=7834248-7834248msec
WRITE: bw=134KiB/s (137kB/s), 134KiB/s-134KiB/s (137kB/s-137kB/s), io=1026MiB (1076MB), run=7834248-7834248msec
Disk stats (read/write):
sda: ios=786108/266569, merge=1128/2504, ticks=233649116/19401499, in_queue=251271288, util=42.43%
Tu si pozrieme dva typy výkonu. Jeden typ je IOPS (Input/Output Per Second, teda počet požiadaviek za sekundu) kde v sekcii test: vidíme informácie o čítaní read: a zápise write: vidíme riadky začinajúce iops. V nich vidíme priemerné hodnoty pre čítanie avg=106.38 a pre zápis avg=38.68. Tie hodnoty sú trochu vyššie ako zvykne byť pre 5k4 RPM disk.
root@web:~# echo 1 > /proc/sys/vm/drop_caches
root@web:~# cd /mnt/SSD/tmp/
root@web:/mnt/SSD/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=32 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=62.4MiB/s,w=20.3MiB/s][r=15.0k,w=5204 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=3369: Fri Jan 3 19:34:56 2020
read: IOPS=17.6k, BW=68.7MiB/s (72.0MB/s)(3070MiB/44693msec)
bw ( KiB/s): min=11896, max=81616, per=100.00%, avg=70463.44, stdev=10083.56, samples=89
iops : min= 2974, max=20404, avg=17615.85, stdev=2520.89, samples=89
write: IOPS=5876, BW=22.0MiB/s (24.1MB/s)(1026MiB/44693msec)
bw ( KiB/s): min= 4032, max=27800, per=100.00%, avg=23549.47, stdev=3445.20, samples=89
iops : min= 1008, max= 6950, avg=5887.35, stdev=861.30, samples=89
cpu : usr=11.20%, sys=34.34%, ctx=444965, majf=0, minf=6
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwt: total=785920,262656,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: bw=68.7MiB/s (72.0MB/s), 68.7MiB/s-68.7MiB/s (72.0MB/s-72.0MB/s), io=3070MiB (3219MB), run=44693-44693msec
WRITE: bw=22.0MiB/s (24.1MB/s), 22.0MiB/s-22.0MiB/s (24.1MB/s-24.1MB/s), io=1026MiB (1076MB), run=44693-44693msec
Disk stats (read/write):
sdb: ios=785275/262469, merge=0/9, ticks=688518/702953, in_queue=344504, util=99.37%
Tu si znovu pozrieme spomínané dva typy výkonu. IOPS pre čítanie je v tomto prípade avg=17615.85 a pre zápis avg=5887.35. To je oveľa lepšie ako rotačný NB disk.
Kto už robil s KVM/libvirt, ten vie že hlavné úložisko je v priečinku /var/lib/libvirt v ktorom sú podpriečinky images (pre disky), nvram (pre UEFI nastavenia), dnsmasq (sieť) a ďalšie. Ten priečinok si jednoducho prehodíme. Veľmi jednoducho, a dočasne. Neskôr to ajtak preinštalujem aj s kryptovaním cez obidva disky.
libvirt na libvirt-old aby sme si ho uchovali, potom zlinkujeme libvirt aby ukazoval do identickej lokácie na SSD, následne si na ten SSD skopírujeme všetky veci, a potom si pre istotu reštartneme službu virtualizácie:
root@web:~# mv /var/lib/libvirt /var/lib/libvirt-old root@web:~# ln -sv /mnt/SSD//var/lib/libvirt /var/lib/libvirt '/var/lib/libvirt' -> '/mnt/SSD//var/lib/libvirt' root@web:~# ls -ld /var/lib/libvirt /var/lib/libvirt-old /mnt/SSD//var/lib/libvirt drwxr-xr-x 6 root root 4096 Dec 30 21:30 /mnt/SSD//var/lib/libvirt lrwxrwxrwx 1 root root 25 Jan 5 12:39 /var/lib/libvirt -> /mnt/SSD//var/lib/libvirt drwxr-xr-x 7 root root 4096 Jan 3 18:59 /var/lib/libvirt-old root@web:~# cp -pRv /var/lib/libvirt-old/* /mnt/SSD//var/lib/libvirt/ ... '/var/lib/libvirt-old/qemu/domain-26-Ubuntu-2004-UEFI/master-key.aes' -> '/mnt/SSD//var/lib/libvirt/qemu/domain-26-Ubuntu-2004-UEFI/master-key.aes' '/var/lib/libvirt-old/qemu/domain-26-Ubuntu-2004-UEFI/monitor.sock' -> '/mnt/SSD//var/lib/libvirt/qemu/domain-26-Ubuntu-2004-UEFI/monitor.sock' root@web:~# du -sh /var/lib/libvirt-old/ /var/lib/libvirt/ 52G /var/lib/libvirt-old/ 52G /var/lib/libvirt/ root@web:/var/lib/libvirt# systemctl restart libvirtd.service root@web:~#Tak, a máme preklopených 54G virtuálok. V dvoch z nich si teraz v kľude urobíme testy výkonu.
Teraz si zopakujeme test výkonu diskov vo virtuálkach. Bude to identický test, ako bol v dieloch Hry s KVM 6: Thin Provisioning - FreeBSD NAS 2 a Hry s KVM 8: Thin Provisioning - Ubuntu NAS 2. Aj s drobným doplnkom.
Teraz si teda zaplníme ZFS náhodnými dátami, veľkosť zápisu bude cca 1M, počet zápisov 39 tisíc, výstupný súbor bude /EXPORTS/fill a pozrieme si rýchlosť už počas zápisu. Ako prvý pôjde Ubuntu 19.10:root@Ubuntu-1910-NAS:~# dd if=/dev/urandom bs=1M count=39k status=progress of=/EXPORTS/fill 41158705152 bytes (41 GB, 38 GiB) copied, 987 s, 41.7 MB/s dd: error writing '/EXPORTS/fill': No space left on device 39253+0 records in 39252+0 records out 41159360512 bytes (41 GB, 38 GiB) copied, 988.41 s, 41.6 MB/sKeď sme mali farmičku na rotačnom HDD, tak bola rýchlosť takéhoto zápisu 15.0 MB/s, teraz sa zdvihla na 41.7 MB/s. To je skoro trojnásobný nárast, v reále to bolo rýchlejšie 2.8x.
Tak, a poďme si vyskúšať či funguje autotrim aj v ZoL. Ak nie je vo východzom stave zapnutý, tak ho zapneme a vyskúšame:
root@Ubuntu-1910-NAS:~# zpool get autotrim EXPORTS NAME PROPERTY VALUE SOURCE EXPORTS autotrim off default root@Ubuntu-1910-NAS:~# zpool set autotrim=on EXPORTS root@Ubuntu-1910-NAS:~# rm -v /EXPORTS/fill removed '/EXPORTS/fill' root@Ubuntu-1910-NAS:~# df -h /EXPORTS/ Filesystem Size Used Avail Use% Mounted on EXPORTS 39G 6.4G 32G 17% /EXPORTS
Autotrim vo východzom stave nebol zapnutý. Jeho zapnutie spôsobilo drobnú chybu: pri odmazaní 38G súboru ostalo uzamknutých 6.4G (17%) z miesta ktoré sa samé neuvoľnilo. Teda, uvoľnilo sa až po daní ZFS POOLu do offline pomoxou reštartu VM alebo odpojení a pripojení ZFS cez zpool export/import.
Poďme si teraz odmerať rýchlosť FreeBSD 12 pomocou identického testu s vyššie popísanými parametrami:
root@FreeBSD-12:~ # dd if=/dev/urandom bs=1M count=39k status=progress of=/EXPORTS/fill dd: /EXPORTS/fill: No space left on deviceerred 982.223s, 42 MB/s 39256+0 records in 39255+1 records out 41161981952 bytes transferred in 982.940522 secs (41876371 bytes/sec)
Na rotačnom disku sme mali rýchlosť 21 MB/s, a teraz 42 MB/s. To je zrýchlenie na približne dvojnásobok. Výsledná rýchlosť je ale takmer identická ako s Ubuntu 19.10 na SSD.
Nuž zrýchlenie na 42MB (336Mbit/s) nie je zlé, ale je to len polovica oproti výsledku z predchádzajúceho testu pomocou fio kde sme dosiahli približne dvojnásobnú rýchlosť 90.7MB/s (725.6Mb/s). Takže si poďme zopakovať ten test výkonu SSD s fio, ale s väčším objemom dát (40G).
root@web:/mnt/SSD/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=32 --size=46G --readwrite=randrw --rwmixread=20
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [m(1)][99.9%][r=260KiB/s,w=940KiB/s][r=65,w=235 IOPS][eta 00m:01s]
test: (groupid=0, jobs=1): err= 0: pid=18460: Fri Jan 10 20:36:36 2020
read: IOPS=1623, BW=6493KiB/s (6648kB/s)(8198MiB/1293049msec)
bw ( KiB/s): min= 16, max=33016, per=100.00%, avg=6728.91, stdev=9315.22, samples=2495
iops : min= 4, max= 8254, avg=1682.21, stdev=2328.80, samples=2495
write: IOPS=6486, BW=25.3MiB/s (26.6MB/s)(31.0GiB/1293049msec)
bw ( KiB/s): min= 8, max=129400, per=100.00%, avg=26413.47, stdev=37082.06, samples=2540
iops : min= 2, max=32350, avg=6603.35, stdev=9270.52, samples=2540
cpu : usr=3.57%, sys=12.20%, ctx=5014435, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwt: total=2098783,8386977,0, short=0,0,0, dropped=0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: bw=6493KiB/s (6648kB/s), 6493KiB/s-6493KiB/s (6648kB/s-6648kB/s), io=8198MiB (8597MB), run=1293049-1293049msec
WRITE: bw=25.3MiB/s (26.6MB/s), 25.3MiB/s-25.3MiB/s (26.6MB/s-26.6MB/s), io=31.0GiB (34.4GB), run=1293049-1293049msec
Disk stats (read/write):
sdb: ios=2097421/8382427, merge=5/383, ticks=20091196/20614631, in_queue=31402484, util=39.21%
root@web:/mnt/SSD/tmp#
A tu už vidíme ako nám spadol výkon SSD na cca 33MB/s (264Mb/s). To je síce o trochu menej ako priamy zápis vo VM, ale zápis vo VM mal od výroby nastavené cachovanie. Takže krásne vidíme že s objemom zápisu nám klesá aj rýchlosť.
Nuž, a čo na budúce? Otestujeme si odolnosť ZFS voči výpadku.
Tiskni
Sdílej:
Nerozumím řeči tvého kmene, nespletl sis server?
už jsem se jako trošku začínala bát že s tebou něco je jak se tady přestaly oběvovat zápisky tvýho blogísku ;D
Lamerský blogísek v hotentotštině na českém linuxovém serveru. Cool.