Byla vydána verze 1.96.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Společnosti IBM a Red Hat představily Project Lightwell s investicí 5 miliard dolarů. Jedná se o důvěryhodné clearingové centrum pro bezpečnost open source softwaru a zabezpečení dodavatelských řetězců s novým AI modelem a globální skupinou více než 20 000 softwarových inženýrů. Služby centra budou dostupné prostřednictvím komerčních předplatných. Project Lightwell staví na iniciativách jako Anthropic Glasswing nebo OpenAI Trust Access for Cyber.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 26.05. Podrobný přehled novinek v poznámkách k vydání.
Český stát by v budoucnu mohl provozovat vlastní alternativu ke komunikačním aplikacím typu WhatsApp, Signal, Telegram, Facebook Messenger a podobně. Cílem je zajistit bezpečnou datovou komunikaci pro stát a jeho důležité subjekty, jako jsou bezpečnostní složky, ministerstva a další organizace.
Už za týden, ve čtvrtek 4. června, se v Národní technické knihovně v pražských Dejvicích uskuteční další konference věnovaná tématům spojeným s IPv6 - Den IPv6. Program akce a registrační formulář jsou k dispozici na webu akce. Kapacita konference je omezená, proto organizátoři doporučují, aby se vážní zájemci přihlásili včas (k dnešnímu dni zbývá přibližně 30 volných míst). Konferenci Den IPv6 2026 organizují i letos společně sdružení CESNET, CZ.NIC a NIX.CZ.
Zařízení Steam Deck OLED bylo znovu naskladněno, ale vlivem rostoucích cen pamětí a úložišť má novou, vyšší cenovku. Steam Deck OLED 512 GB stojí nově 779 EUR (stál 569 EUR) a Steam Deck OLED 1 TB stojí 919 EUR (stál 679 EUR). Samotné zařízení se nijak nezměnilo a nové ceny tedy pouze odráží aktuální náklady na komponenty a další globální logistické výzvy, se kterými se potýká celá branže.
Český telekomunikační úřad zahajuje novou etapu využívání vysokofrekvenčního rádiového spektra v pásmu 26 GHz. Toto pásmo bude od 1. 7. 2026 otevřeno pro provoz moderních bezdrátových sítí, zejména sítí páté generace (5G), pevných bezdrátových přístupových sítí (FWA) a lokálních či průmyslových sítí určených například pro výrobní areály, logistická centra nebo technologické kampusy. Současně s otevřením pásma 26 GHz přistoupil ČTÚ ke zpřístupnění informací o využívání rádiových kmitočtů v tomto pásmu.
Logitech představil myš Signature Comfort Plus M850 L s polstrovanou opěrkou dlaně pro větší pohodlí a sadu s touto myší a klávesnicí s integrovanou opěrkou dlaní Signature Comfort Plus Combo MK880.
Gaël Duval se rozepsal o novinkách a plánech Murena a /e/OS. Počet uživatelů telefonů Murena a mobilního operačního systému /e/OS bez aplikací a služeb od Googlu se blíží 100 000. Ambicí je, aby se /e/OS stal třetí mobilní platformou v Evropě i na světě, s potenciálem dostat se i na PC. Blíží se vydání nové verze 4 s funkcemi zálohování a obnova, import e-mailů z Gmailu a rozpoznávání hlasu. Murena Workspace přinese videohovory, elektronický podpis a správu zařízení (MDM).
Dnes a zítra probíhá Ubuntu Summit 26.04. Na programu je řada zajímavých přednášek. Sledovat je lze na YouTube. Úvodní slovo měli Mark Shuttleworth a Jon Seager.
Trochu experimentuji. Mám btrfs device single, původně ze dvou HDD, připojil jsem k tomu 3. a 4., po krátkém používání jsem 4. opět odpojil a pokusil se odpojit 1., kterým to celé bylo přimountované. Během odpojování mi Cron spustil rsync do jednoho subvolume. Čímž se možná něco poblblo, možná ne, ale přinejmenším rsync se zastavil. Takže jsem ho killnul a zastavil cron.
V ten okamžik (resp. cca 1/2 dne po kolizi s rsyncem) jsem možná udělal chybu, protože jsem se pokusil killnout proces btrfs delete, což nejde a zatím stále běží. Jelikož to je pokusný stroj nechal jsem to tedy přes víkend pracovat a opravdu se něco děje.
jádro - systém je 32bit, protože je to "studená" záloha instalace pro stroj, který nemá 64bit CPU
Linux version 3.16.3 (root@charon) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #1 SMP Mon Oct 6 15:10:18 CEST 2014
systém
cat /proc/cpuinfo ... model name : Intel(R) Pentium(R) CPU G630T @ 2.30GHz ... cpu MHz : 2300.000 cache size : 3072 KB ...
související procesy z topu - něco to dělá, ale netuším, co přesně
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15149 root 20 0 0 0 0 R 99,4 0,0 175:09.01 kworker/u4:4 3499 root 20 0 0 0 0 R 89,8 0,0 3017:01 btrfs-transacti
devid 3 byl před zadáním delete zcela prázdný, postupně přibyly 4GB za 3 dny běhu, devid 1 je ten, který jsem chtěl odstranit a kterým to je přimountováno do /mnt/backup_btrfs, v okamžiku zadání btrfs delete byl /dev/sde1 zcela prázdný a ještě dlouho po pokusu o kill na něm byly jen 2GB
btrfs filesystem show --all-devices
Label: none uuid: 86a80782-b8f9-4d8f-9a61-4aa8e516f589
Total devices 3 FS bytes used 77.88GiB
devid 1 size 149.05GiB used 5.03GiB path /dev/sdd1
devid 2 size 298.09GiB used 79.01GiB path /dev/sdc1
devid 3 size 111.79GiB used 4.00GiB path /dev/sde1
Btrfs v3.12
sdd1 je první disk z původní dvojice v btrfs single device
/dev/sdd1 on /mnt/backup_btrfs type btrfs (rw)
btrfs delete stále běží po pokusu o zabití kill -9
8703 ? D 18:48 btrfs device delete /dev/sdd1 /mnt/backup_btrfs/
zajímavé, že v /dev není vidět /dev/sdc1 ani /dev/sde1, ale jen první disk z btrfs single device
ls /dev/disk/by-uuid/ -l ... lrwxrwxrwx 1 root root 10 18. říj 00.54 86a80782-b8f9-4d8f-9a61-4aa8e516f589 -> ../../sdd1
obsah jednoho subvolume/snapshotu, kterých je na btrfs 430
ls -l /mnt/backup_btrfs/daily_rsync_subvolume celkem 0 drwxr-xr-x 1 root root 1076 7. říj 04.05 bin drwxr-xr-x 1 root root 442 6. říj 15.11 boot drwxr-xr-x 1 root root 770 15. srp 14.18 __dalsi_balast_pro_zatizeni_btrfs drwxr-xr-x 1 root root 3152 17. říj 18.03 etc drwxr-xr-x 1 root root 34 6. úno 2012 home drwxr-xr-x 1 root root 3830 7. říj 04.02 lib drwxr-xr-x 1 root root 10 17. srp 2011 opt drwx------ 1 root root 600 15. říj 12.55 root drwxr-xr-x 1 root root 2852 7. říj 04.15 sbin drwxr-xr-x 1 apache apache 512 18. čen 10.55 srv drwxrwxrwt 1 root root 106 17. říj 18.03 tmp drwxr-xr-x 1 root root 138 29. říj 2010 usr drwxr-xr-x 1 root root 106 6. říj 23.18 var
poslední související záznamy v messages, pak už nic nepřibylo (po kolizi s rsyncem)
cat messag* | grep -i btrfs Oct 17 17:21:22 charon kernel: BTRFS info (device sdd1): disk space caching is enabled Oct 17 17:21:58 charon kernel: BTRFS info (device sdd1): relocating block group 73043804160 flags 20 Oct 17 17:25:00 charon kernel: BTRFS info (device sdd1): found 27915 extents Oct 17 17:25:00 charon kernel: BTRFS info (device sdd1): relocating block group 60158902272 flags 20 Oct 17 17:33:21 charon kernel: BTRFS info (device sdd1): found 63267 extents Oct 17 17:33:22 charon kernel: BTRFS info (device sdd1): relocating block group 27946647552 flags 20 Oct 17 18:00:01 charon run-crons[8854]: (root) CMD (/etc/cron.hourly/zalohovani_rsync_btrfs.sh) Oct 17 18:03:46 charon kernel: BTRFS info (device sdd1): disk space caching is enabled Oct 18 00:58:39 charon kernel: BTRFS info (device sdd1): disk space caching is enabled Oct 18 05:11:40 charon kernel: BTRFS info (device sdd1): found 63312 extents Oct 18 05:11:41 charon kernel: BTRFS info (device sdd1): relocating block group 16135487488 flags 20
Aktuálně je tedy na btrfs filesystému 430 snapshotů, v každém z nich je různě aktuální záloha celého Linuxu, mezi některými jsou změny více radikální, protože jsem aktualizoval celé Gentoo. Plus trocha balastu ve větších souborech ... testuju tím zálohovací skripty, takže obsah filesystému je postradatelný.
Ale když už se to takto pěkně pokazilo (nebo je to normální, že to tak dlouho trvá?), tak se chci dozvědět, co možná nejvíc o možné diagnostice, opravě.
Co vy na to?
FS jsem vytvářel pomocí mkfs.btrfs -d single /dev/sdc1 /dev/sdd1 a další disk přidával např. btrfs device add /dev/sde1 /mnt/backup_btrfs/
Krátce po přidání čtvrtého vypadalo btrfs device takto (z mých poznámek během experimentování)
btrfs filesystem show --all-devices
Label: none uuid: 86a80782-b8f9-4d8f-9a61-4aa8e516f589
Total devices 4 FS bytes used 75.08GiB
devid 1 size 149.05GiB used 5.03GiB path /dev/sdd1
devid 2 size 298.09GiB used 77.01GiB path /dev/sdc1
devid 3 size 111.79GiB used 0.00 path /dev/sde1
devid 4 size 465.76GiB used 0.00 path /dev/sdb1
Btrfs v3.12
Platí i v tuto situaci, že druhý /dev/sde1 a třetí /dev/sdb1 nebyly přidané v režimu single, ale RAID 0?
A nebo spíš jinak ... to, že btrfs rozkládá zátěž na víc disků mi nemusí vadit, žádný z nich není vadný (snad, testem předtím prošly), žádný jsem fyzicky zatím neodpojil (byť jsou všechny na USB), všechna data jsou stále přístupná i když se na pozadí děje něco, do čeho nevidím. Takže i když s tím provedu takovou divočinu, jako odebrání jednoho z prvních disků na kterém byl fs sestaven, tak by se to mělo úspěšně přeorganizovat. Nebo ne?
Mimochodem, ve výpisu
btrfs filesystem df /mnt/backup_btrfs Data, single: total=73.01GiB, used=72.94GiB System, RAID1: total=8.00MiB, used=16.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: total=6.00GiB, used=4.95GiB Metadata, single: total=8.00MiB, used=0.00 unknown, single: total=512.00MiB, used=49.17MiB
... se mění poslední položka unknown a postupně zmenšuje položka Metadata, RAID1: To bych chápal tak, že btrfs stále pracuje a proto mi nezbývá než počkat až svou práci dokončí.
Mě se BTRFS za 4 roky nikdy nepodařilo zbořit (krom jednoho případu na kernelu 2.6.18).
Podle mě tam dochází k tomu, že btrfs delete se snaží realokovat všechny bloky jinam, zatímco se na ten FS sypou další data (a i na ten odebíraný disk). Takže tak trochu chybka. Takže teď omezit ostatní provoz a prostě počkat. Navíc je tam docela dost metadat (5GB na 73GB dat, u mě je to na R1 asi 400MB na 380GB), což samozřejmě ničemu neva (jak jsi psal, je tam dost snapshotů a asi i souborů).
Od okamžiku, kdy se do toho připletl rsync a poblblo se to (resp. rsync se zastavil na cca hodinu na jednom z mnoha malých souborů než jsem ho ukončil) jsem na to nic dalšího nezapisoval a nechal to v klidu pracovat.
Metadat je hodně, protože snapshotů je 429 + subvolume kam rsync zálohoval. Soubory v subvolume mají dohromady 37G a i s adresářema jich je 783768 (říká find * | wc). Trochu extrém, ale při zálohování maildirů je možné leccos, proto to zkouším na tomto.
ano, to prebalancovani muze trvat dost dlouho, jestli mas disky usb tak klidne i par dni vyhoda je, ze nevadi restart... se mění poslední položka unknown a postupně zmenšuje položka Metadata, RAID1: To bych chápal tak, že btrfs stále pracuje a proto mi nezbývá než počkat až svou práci dokončí.
btrfs filesystem df /mnt/backup_btrfs
jinak me se kousl RAID5 pri zapisu spousty dat, asi neco podobneho, jako vidis ty;
po restartu se to tvarilo normalne, scrub nic nenasel, zapisovany adresar jsem smazal a zapsal znova
ted uz to nejakou dobu nedela
říká
btrfs filesystem df /mnt/backup_btrfs Data, single: total=73.01GiB, used=72.94GiB System, RAID1: total=8.00MiB, used=16.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: total=6.00GiB, used=4.97GiB Metadata, single: total=8.00MiB, used=0.00 unknown, single: total=512.00MiB, used=28.33MiB
Určitě jsem nechtěl RAID0/10/5, nejde mi o zrychlení, ani redundanci, ale spíš o možnost "nastavovat" v nouzi prostor pro zálohy, když nastane situace, kdy není snadné disk vyměnit, nebo je potřeba větší prostor, než jsou běžně/levně koupitelné kapacity. Nebo pro případ, že mám spoustu příliš malých HDD, které se k ničemu lepšímu nehodí (třeba 500G) a chci na ně duplicitně zálohovat "něco" navíc. Tj. získám tím určité pohodlí při obnově ze zálohy, nebo delší historii záloh, ale zároveň příliš neriskuji, protože existuje ještě jedna záloha na zcela jiném úložišti s jiným fs. Tím pádem mne i zajímalo, co btrfs provede v trochu víc extrémních situacích.
btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/backup_btrfs
nojo, mas smotany dohromady single a raid1, to asi neni uplne normalni...
Nemá. Všechna data má single. Metadata jsou buďto duplikovaná (na jednom disku) nebo R1 na multidevice. Tohle chování je správné.
porad to nechapu, jak chces ty disky pridavat a ubirat a pritom nechces redundanci?
Jenomže on nepožaduje (jak to chápu) redundanci proti (hw) výpadku disku. On to přidává pomocí btrfs device add a ubírá pomocí btrfs device delete. Při tomto způsobu o žádná data a ani metada při odstranění disku nepřijde, btrfs to realokuje jinam.
neni lepsi mit alespon metadata R1? a data teda single no
Ale on to tak má:
Data, single: total=73.01GiB, used=72.94GiB Metadata, RAID1: total=6.00GiB, used=4.97GiB
signalizuje nejak btrfs, ze uz muze?
Ano. Příkaz delete dojede a ve fi show to zařízení zmizí.
Tiskni
Sdílej: