Po 9 týdnech vývoje od vydání Linuxu 6.14 oznámil Linus Torvalds vydání Linuxu 6.15. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Tiskni
Sdílej:
Důvod je jasný – fragmentace. Všechny copy-on-write systémy s tím mají problémy. Pro nástin možného řešení se podívej na oznámení different transaction models od Edvarda Šiškina, vývojáře Reiser4. (Ano, Reiser4 stále ještě neumřel, i když umírá už dlouho. Aneb nevěř ničemu, co vydrží pět dní krvácet a nepojde. Ale oznámení je napsané hezky.)
Klasický neobjektivní plk. Zcela chybí srovnání s Btrfs ve stavu, kdy nedělá nic jiného než ext4 (tedy je bez komprese, bez jediného použití cp --reflink, bez subvolumes a snapshotů a tak dále.) Komprimovaný filesystém není, nebyl a nebude rychlejší než nekomprimovaný. Tak to v životě nechodí a nějak nechápu, kde se bere fáma, že snad ano. Kdyby si tam někdo ukládal zásobu nul, pak by komprese pomohla, ale jinak asi ne. Na komprimovaném filesystému je v podstatě každý seek celkem složitý kus aritmetiky a nedají se pak naplno využít vymoženosti spojené s DMA, protože data uložená na disku a data v paměti (připravená v čitelném stavu) nejsou stejná a mezi oběma reprezentacemi se musí převádět. V dnešních kernelech se nikdy nečte a nepíše jinak než přes mmap() a při představě, jakým způsobem funguje mmap() na komprimovaném filesystému, je mi na blití. Takže by to chtělo buď vyzkoušet ext4 s kompresí (ve snu), nebo Btrfs bez komprese a bez (explicitního) použití COW funkcí.
Ale ani potom by srovnání nebylo objektivní. Btrfs má checksumy dat i metadat, což ke killer feature, proti které ext4 vypadá jako ubohá hračka pro děti.
Já mám autodefrag zapnutý a je to OK.
Spíš bych doporučoval (kromě komprese) vypnout (resp. nezapínat) inode_cache. U té jsem viděl problémy se zamykáním, které způsobovaly krátkodobé tuhnutí systému při intenzivních operacích nad filesystémem.
No to asi musí udělat, protože jinak by checksum nebyl stoprocentně atomický. (Mohl by být, ale za cenu extrémního zhoršení výkonnosti.)
21.3.2014 09:22
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Proč ho používat, i když vypnu kompresi (nikoliv všechno)?
Protože copy-on-write žádné zásadní zpomalování nepřinášíAaaaano. sudo apt-get update a odchod na oběd.
Proč hned myslet na nejhorší myslitelnou distribuci? V některých distribucích zkrátka některé věci nefungují čistě ze zásady.
Ale zpět k tématu: Vždycky mě pobaví některé omyly, mýty a polopravdy, které kolují nejen mezi řidiči, 
ale i mezi uživateli Linuxu. Copy-on-write nebude mít při aktualizaci téměř žádný vliv na výkonnost ani na fragmentaci, protože soubory se při aktualizaci buď ponechají nezměněné (kdy se copy-on-write výborně hodí), nebo se celé přepíší (což znamená, že copy-on-write na úrovni bloků se vůbec nepoužije, tj. nebude tam žádný fragmentovaný (mezi)stav, kdy soubor některé bloky sdílí se svou původní verzí a některé ne). Existují samozřejmě i různé slabší balíčkovací systémy, které přepíší kompletně celé soubory vždy, bez ohledu na to, zda se mezi verzemi změnily. I to se stává. O to menší pak bude vliv copy-on-write.
A vůbec, vše zmíněné je třeba brát v úvahu jen v tom jediném speciálním případě, kdy se aktualizace systému provádějí atomicky do Btrfs snapshotů (tj. vytvoří se snapshot, v něm se provede aktualizace a pak se do aktualizovaného snapshotu přebootuje). Pokud se aktualizuje „klasickým“ neatomickým způsobem, nemá to s copy-on-write už vůbec nic společného, v pozitivním ani negativním slova smyslu.
Zkrátka a dobře, je třeba nepřisuzovat copy-on-write jakési magické vlastnosti. Spousta lidí si plete copy-on-write s deduplikací, která může mít za jistých specifických okolností negativní vliv na latenci i throughput.
Btrfs může být pomalejší než jiné filesystémy z mnoha důvodů nesouvisejících s copy-on-write. Například někdo může chtít atomické udržování několika replik dat i metadat v rámci jediného disku. (Ostatní fiesystémy, kdo z vás to má? ZFS: „Já!!!“) Nebo zkrátka počítání a udržování checksumů zabere jistý drobný čas navíc a zápis do bloku vždy znamená taktéž aktualizaci několika checksumů v příslušném inode (zatímco na čtení to téměř nemá vliv, protože inode s checksumem se musel přečíst tak nebo tak — tady opravdu záleží jen na tom, kolik času zabírá výpočet checksumů). Btrfs má zkrátka některé klíčové vlastnosti, které až donedávna ve filesystémech chyběly, případně byly dostupné jenom na Solarisu. Za některé z těchto vlastností se ovšem „platí“.
Ne že by byl Phoronix kdovíjak důvěryhodný zdroj, ale tady, tady ani tady nevidím žádnou výkonnostní apokalypsu, která by vybízela k odchodu na oběd. Vzhledem k tomu, co Btrfs umí, je jeho výkon poměrně solidní. Samozřejmě se „pořadí soutěžících“ liší benchmark od benchmarku, což se dá čekat.
Jen aby mě zase někdo nechytal za slovo: Tvrzení, že přepsání celého souboru nemá s copy-on-write „vůbec nic společného“, rozhodně vyžaduje podrobnější vysvětlení.
Pokud by se zkrátka otevřel soubor a přímo do něj by se zapsala jeho nová verze, implementace by se na copy-on-write a klasických filesystémech lišila, protože CoW filesystém by (obecně) nepřepisoval bloky přímo na místě, ale používal by „wandering logs“ a podobné triky, což znamená, že poloha bloků nové verze souboru na disku by byla jiná než původně. To ale nijak nesnižuje výkonnost — naopak jsou wandering logs v mnoha směrech efektivnější než klasické žurnálování, protože odstraňují nutnost dvojího zápisu.
Jenže balíčkovací systémy většinou nefungují tak, že by otevřely soubor a rovnou na místě ho přepsaly. Taková operace by nebyla atomická a hrozilo by, že by třeba někdo spustil „napůl přepsanou“ binárku a podobně. Proto se zpravidla vytvoří nový soubor někde vedle (pod jiným názvem) a následně (po kompletním zápisu celého souboru) se přejmenuje na název cílového souboru. Protože přejmenování souboru je atomická operace, nikdo neuvidí nekonzistentní obsah souboru. Jenže v tomto případě se celá operace odehrává na copy-on-write i klasických souborových systémech zhruba stejně. Pozice bloků souboru (i kdyby byl jejich počet stejný) bude po aktualizaci nutně jiná než původně. (Už proto, že původní a nový soubor musely chvíli koexistovat.) Takže s copy-on-write tohle opravdu nemá nic společného, copy-on write na věci v podstatě nic nemění.
Třetí možnost, tedy aktualizace pomocí Btrfs snapshotů, jsem už rozebíral výše. Tam nemá srovnání s klasickými filesystémy smysl, protože klasické filesystémy nic takového neumožňují.
Proč hned myslet na nejhorší myslitelnou distribuci? V některých distribucích zkrátka některé věci nefungují čistě ze zásady.Aha, tak nic, no. Končíme. Až to s "nejhorší" distribucí nebude při činnosti, kterou provozuju několikrát týdně, cca desetkrát pomalejší než ext4, tak zas přijď prudit s úžasnými featurami.
No já nevím, ale kdyby mě nějaká distribuce brzdila v běžné práci a způsobovala by, že bych musel používat technologie pár let staré, změnil bych distribuci. Ale někdo to třeba vidí jinak.
Muzu se zaptat, jak nasledujici operace:Protože manuální checksumy nejsou atomické (tedy jsou 100% na hovno) a znamenají, že člověk slouží počítači, nikoliv počítač člověku.
ioctl(fd, FIFREEZE, 0); checksum(); ioctl(fd, FITHAW, 0);muze vest k neatomickemu checksumu?
To má být vtip? Vždyť z toho koukají problémy úplně na první pohled, až to řve:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.3.2014 20:06
20.3.2014 21:47
21.3.2014 11:48
21.3.2014 15:49
21.3.2014 08:07
26.3.2014 08:30
26.3.2014 19:45
FIFREEZE a data souboru po FITHAW nebo naopak?FIFREEZE?Čím je garantováno, že userspace nikdy neobdrží neplatná data v případě, že checksum nesedí?Z volání ioctl() bych si tipnul, že ten kód je v userspace. Takže to asi bude garantováno tím, že userspace vypočítá checksum a ohlásí chybu, když nesedí.
Jak přesně je zajištěna ochrana metadat (například struktury inode pro každý soubor a B(*)-stromů adresářů) pomocí tohoto checksumu?Cílem je detekovat silent corruption, tj. zjistit, že soubor byl poškozen. To tohle zajistí, k čemu ochrana metadat?
Z volání ioctl() bych si tipnul, že ten kód je v userspace. Takže to asi bude garantováno tím, že userspace vypočítá checksum a ohlásí chybu, když nesedí.
Aha. Takže tenhle zázračný kód v userpace nějak zajistí, že každá libovolná aplikace v userspace dostane něco jako EIO, když se pokusí přečíst blok se špatným checksumem?
A teď ještě Červenou karkulku. Ta bude pravdivější.
Cílem je detekovat silent corruption, tj. zjistit, že soubor byl poškozen. To tohle zajistí, k čemu ochrana metadat?
No jasně. Rozumím tomu dobře tak, že silent corruption metadat je zcela v pořádku a není třeba se před ní chránit? Jednou jsem na svém počítači našel soubor s velikostí kolem 100 PB (který rozhodně nevznikl jako sparse file). Ovšem to bylo v roce 2005 na Ext3.
Takže tenhle zázračný kód v userpace nějak zajistí, že každá libovolná aplikace v userspace dostane něco jako EIO, když se pokusí přečíst blok se špatným checksumem?Když už to potřebuješ po lžičkách: tenhle zázračný kód v userspace zajistí, že aplikace, která stojí o dobré zajištění svých dat proti poškození, pozná, když k poškození dat dojde. O každé libovolné aplikaci není řeč - pokud si ta data nekontroluje, nejsou zjevně dost důležitá.
Rozumím tomu dobře tak, že silent corruption metadat je zcela v pořádku a není třeba se před ní chránit?Jak je vidět, bylo rozpoznáno, že došlo k poškození souboru. To jsme chtěli, ne?
To je prostě nesmysl. Například celý slavný hardwarový RAID5 (když už se bavíme o tom skvělém hardware, který nemění data) je téměř na hovno, protože pokud se jeden z disků porouchá nějakým zákeřným způsobem, tedy neselže úplně, ale například kvůli vadnému kabelu občas vrací špatná data (což je problém, který se v praxi objevuje, jakkoliv se to může zdát nepravděpodobné), je z toho silent data corruption hnedle. Zatímco RAID5 vestavěný v Btrfs dokáže určit, který z disků má pravdu a který ne (přesněji řečeno, snížit pravděpodobnost neodhalené chyby o dalších mnoho řádů), klasický hradwarový RAID5 nic takového nemá a neumí. Jistá odolnost vůči silent data corruption je klíčová výhoda RAIDu vestavěného ve filesystému v kombinaci s checksumy ve filesystému. ZFS to má, Btrfs taky a ostatních filesystémů by se Jirka Paroubek zeptal: Kdo z vás to má?!
Zajímavé je, že i RAID1 je bez podpory ve filesystému jen hračka pro děti. Například když jeden ze dvou disků v RAID1 selže, použije se ten druhý. Ano, v pořádku, to dá rozum. Ale co když jeden z disků z jakéhokoliv důvodu vrací špatná data? Co když se vypnul násilím systém, jeden disk stihl pár posledních bloků commitnout a druhý ne? Pak mezi nimi bude nutně rozdíl, ať už je to jakkoliv drahý hardware. A když se čte, čte se samozřejmě prokládaně kvůli výkonnosti, nic se mezi oběma disky neporovnává. Takže se na chybu nepřijde. A i kdyby se porovnávalo, nepomůže to, protože není jasné, který z lišících se disků má pravdu. Btrfs to ovšem ví, protože tam má checksum.
Slinty o dokonalém hardware už dnes neletí. Pokud mi Btrfs umožňuje používat o půl řádu levnější hardware a dosáhnout spolehlivosti srovnatelné se serverovým hardwarem, může to být jedině plus.
Pokud někdo touží po údajně větší stabilitě, ZFS má RAIDZ (ekvivalent RAIDu 5, 6 i některých vyšších stupňů redundance) rovnou tady a teď.
Faktem ale zůstává, že jak mdraid tak dmraid poskytují pouze iluzi redundance, nikoliv opravdovou redundanci. (Totéž platí pro hardwarový RAID.) Například v případě RAIDu 5 totiž chrání pouze před situací, kdy jeden disk náhle úplně selže. Vůbec ale nechrání filesystém před situací, kdy je některý z disků částečně funkční a vrací tu a tam neplatná data, ať už kvůli problémům ve firmware řadiče, v kabelech nebo přímo v disku.
(Koneckonců právě příchod filesystémů typu ZFS a Btrfs pomohl odhalit několik závažných chyb, dlouho schovaných v discích i řadičích téměř bez povšimnutí.)
Btrfs a ZFS umí zařídit redundanci dat a metadat dokonce i na jednom jediném disku (tedy udržovat kopie atomicky a poznat, která z kopií je v pořádku), což je další feature, kterou mdraid, dmraid ani hardwarový RAID v podstatě nemá ani s více disky.
Nebrání, ale bude to zcela a stoprocentně na hovno: Když se budou kopie lišit, nikdo nijak nezjistí, která kopie má pravdu. Btrfs to ovšem se svou vestavěnou replikací zjistí, což je jedna z těch zásadních výhod, o kterých jsem tu psal.
Nemluvě o tom, že v rámci jednoho filesystému je mnohem víc možností, jak optimalizovat přístupy k disku při udržování několika replik dat, takže by mě vůbec nepřekvapilo, kdyby udržování dvou replik dat i metadat na Btrfs bylo mnohem výkonnější než ono nefunkční řešení s mdadm nebo LVM.
Praktické fungování s tu a tam poškozenými daty není fungování v pravém slova smyslu, podobně jako iluze bezpečnosti není opravdová bezpečnost.
Nikde není psáno ani půlkou slova, že by snad Btrfs prakticky nefungoval. Stížnosti na „nepraktický“ výkon Btrfs mají obvykle společného jmenovatele: Uživatel se podívá do Wiki, jaké experimentální features si může na Btrfs zapnout, a všechny je zapne. Nebo zapne kompresi a myslí si, že filesystém s kompresí by měl běžet rychleji než bez komprese.
Žádný software není dokonalý a nikdo tu nikde netvrdil opak.
Praktické fungování s tu a tam poškozenými daty není fungování v pravém slova smysluProsil bych o nějaký spolehlivý údaj, jak často se tohle "tu a tam poškození" děje.
Žádný software není dokonalý a nikdo tu nikde netvrdil opak.Kromě Vás, neboť implicitně předpokládáte, že Btrfs nemůže způsobit tiché poškození dat, které kvůli chybě unikne detekci.
Pokud by kvůli chybě v kódu Btrfs došlo k poškození dat, byl by to zkrátka bug jako každý jiný. Na platnosti argumentů ohledně důležitosti filesystémů s checksumy to nic nemění.
Jsem líný googlit údaje o silent data corruption. Párkrát jsem ji viděl na strojích, se kterými pracuju, což mi bohatě stačí k tomu, abych se jí obával. Tedy nepoužívám prehistorické filesystémy bez checksumů.
Pokud by kvůli chybě v kódu Btrfs došlo k poškození dat, byl by to zkrátka bug jako každý jiný. Na platnosti argumentů ohledně důležitosti filesystémů s checksumy to nic nemění.Pokud by kvůli chybě v hardwaru došlo k poškození dat, byla by to chyba jako každá jiná. Na platnosti argumentů ohledně nedůležitosti filesystémů s checksumy to nic nemění.
Nuemí sice některé hi-fi sci-fi věci, které umí btrfs, ale to co umí, dělá dobře, rychle a spolehlivě (narozdíl od některých ostatních filesystémů, jako např. ext* nebo btrfs, které jsou buď pomalé nebo nespolehlivé nebo oboje). Výkon nemá vynikající v nějakém konkrétním ohledu, ale velmi dobrý všeobecně/průměrně.
Koncem loňskýho roku jsem utrpěl havárii disku (laptop spadl za běhu na zem), z disku, který dělal příšerný zvuky, jsem vytáhl dost děravý image, nicméně xfs_repair zachránil vše, co zachránit bylo možné (ve výsledku asi 90% dat). Nakonec jsem neztratil nic důležitýho.
Btrfs bych klidně dal na nějaký experimentální systém. Ale co se týče dat, na kterých záleží, imho se vyplatí být trochu konzervativní, používat dlouhodobě ověřená řešení.
21.3.2014 14:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
22.3.2014 16:26
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
na USB discisch jsem musel prejit z XFS na na EXT4, protoze xfs_repair byl na dennim poradku.
A dovod? Pouzivam xfs na usb disku uz relativne dlho (cez rok), ale problem som s tym este nezaznamenal a nie je to tym, ze by som ho nejak setril. xfs_repair som na nom este behat nemusel. Tamto znie skor ako problem s hw disku nez xfs.
na velky pocet malych souboru je EXT4 mirne lepsi
Ako v com. Rychlost operacii s metadatami je mierne lepsia, ale na druhu stranu ma ext4 obmedzenu velkost metadat a, teda, skutocne velke mnozstvo malych suborov nezvlada.