Byla vydána (𝕏) zářijová aktualizace aneb nová verze 1.105 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.105 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ve Firefoxu bude lepší správa profilů (oddělené nastavení domovské stránky, nastavení lišt, instalace rozšíření, uložení hesla, přidání záložky atd.). Nový grafický správce profilů bude postupně zaváděn od 14.října.
Canonical vydal (email) Ubuntu 25.10 Questing Quokka. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2026.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzi 1.5.0.
Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
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.