V Praze probíhá Flock 2026, tj. konference pro přispěvatele a příznivce Fedory. Přednášky lze sledovat také na YouTube.
Node-RED (Wikipedie, GitHub), webová aplikace postavená na Node.js pro vizuální programování a propojování hardwarových zařízení, API a online služeb, byl vydán ve verzi 5.0. Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 3.27.0 FreeRDP, tj. svobodné implementace protokolu RDP (Remote Desktop Protocol). Opraveno bylo 5 zranitelností.
Řídící výbor GCC schválil záměr do GCC začlenit backend WebAssembly.
Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Platí taková známá poučka: xfs je rychlý souborový systém, rozhodně rychlejší než ext3. Copak to asi je, rychlost filesystému? Rychlost čtení a zápisů je závislá na disku. Nebo že by závisela ještě na něčem?
No jasně, přece na použitém typu filesystému.
Rychlost filesystému jsem si testoval tímhle přiblblým skriptem. První pokus jsem dělal na svém PC, kde mám SATA disk WD1600JS-23M na řadiči Sil 3112. Přechodem od ext3 k xfs se mi skutečně rychlost zvýšila, a to faktorem 1.5 . Druhý pokus jsem udělal na serveru, kde je na SCSI připojeno čtyři roky staré diskové pole EasyStor na ATA discích. I tady se to zrychlilo, dokonce faktorem 2.5 .
To mě tak potěšilo, že jsem ten server vypnul a se všemi uživatelskými daty jsem tam pěkně přešel na xfs. Potom jsem se teprve zamyslel nad tím, čím je to asi tak hrozně rychlé. Že by si ext3 veškerá data ukládal napřed někam a potom znovu ještě někam jinam, to se mi nějak nezdálo. Ale jak jinak může být práce s diskem pomalejší nebo zase rychlejší? Mimochodem, nejméně 2.5 krát se zrychlil i dump (teď je to ovšem xfsdump).
O ten server se starám už dlouho. Občas si tam pustím
vmstat 1a jednu sekundu za druhou se tam dívám na diskový provoz ve sloupcích bi a bo. Někdy to ukazovalo nuly, potom to vyběhlo na nějakých 30 MB/s - to když zrovna někdo něco dělal - a zase se to vrátilo k nulám nebo malým číslům. Po přechodu na xfs se tenhle charakter zatížení zachoval, ale ve špičkách to běžně šplhá až na 90 MB/s.
Tak to vidíte, xfs ten disk dokáže nějak víc zaměstnat. Ale jak toho docílí, to já prosím pěkně nemám tušení.
Tiskni
Sdílej:
Že jako jádro v případě ext3 čeká na potvrzení od disku a potom teprve považuje diskovou operaci za provedenou, takhle jsi to myslel? Je na to nějaká volbička mountu?
To ovšem odporuje pozorované skutečnosti, že diskový provoz se ve špičkách ztrojnásobil. A zrychlení dumpu taky nevysvětlíš kešováním.
To ovšem odporuje pozorované skutečnosti, že diskový provoz se ve špičkách ztrojnásobil.Tak porovnejte celkový počet blokových operací provedených s diskem.
A zrychlení dumpu taky nevysvětlíš kešováním.xfsdump pracuje s přes FS, nikoliv samostatně přímo s blokovým zařízením (Věta z manuálu: xfsdump does not dump unmounted filesystems). Takže se cache využívá. Já nezpochybňuji výkon XFS, jen bych podstatný díl zrychlení připisoval jiným vlivům, než je lepší organizace dat na disku.
Že jako jádro v případě ext3 čeká na potvrzení od disku a potom teprve považuje diskovou operaci za provedenou, takhle jsi to myslel? Je na to nějaká volbička mountu?
Při předběžných testech jsem pracoval na prázdných filesystémech. Ten server provozuju už delší dobu, a během historie byly i nějaké ty úplné obnovy ze zálohy. Stojím si za tím, že zvýšení propustnosti ze 30 na 90 MB/s nelze vysvětlit fragmentací.
Při předběžných testech jsem pracoval na prázdných filesystémech. Ten server provozuju už delší dobu, a během historie byly i nějaké ty úplné obnovy ze zálohy. Stojím si za tím, že zvýšení propustnosti ze 30 na 90 MB/s nelze vysvětlit fragmentací.
man tune2fs, zapnout dir_index, a mountovat to třeba s parametry data=writeback,commit=600. Defaultní nastavení ext3 je zkrátka mnohem paranoidnější než nastavení xfs...
Dík, někdy si to zkusím. Paranoia může být důvod zpomalení, snad. V jednom datovém centru ve Francii prej používají pro aplikační data výhradně xfs, mají tam docela hodně instalací a dušovali se mi, že něco tak báječně stabilního jako je xfs jinak neviděli. Oproti tomu paranoidní defaulty ext3 třeba mají nějaký důvod.
Páni kolegové třeba mají pravdu, že všechno souvisí s fragmentací. Jestli xfs dává požadavky do disku tak, aby tam bylo hodně po sobě jdoucích bloků, tak to třeba udělá svoje.