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.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Řešení dotazu:
Stálo by za úvahu trochu vyhledávat na ABCLinuxu. Tohle už se tady řešilo minimálně dvacetkrát za posledních cca 5 let.
Chci udělat RAID1, ale ze dvou disků a jeden jako hot spare nebo rovnou použít tři?
Hot spare je v tak malém systému všeho všudy nefunkční nesmysl, disk k nepotřebě, vyplýtvaná kapacita. Nejlepší je mít 3 disky a na nich 2 repliky dat, což dá solidní 3/2 kapacity jednoho disku. Tedy, pokud je z nějakého důvodu požadavkem vyhnout se paritnímu RAIDu, který by dovedl se stejným hardwarem a stejnou redundancí poskytnout dvojnásobek kapacity jednoho disku.
Jaký filesystém? EXT4 a SW raid?
Ach jo… Už zase tohle… Ne. Neexistuje žádný SW RAID na Ext4 nebo s Ext4. Nic takového prostě neexistuje. (Opět doporučuji hledat ve zdejší historii.)
Nebo použít HW raid?
Jen to ne.
Zaprvé, je to recept na ztrátu dat. Něco se stane s proprietárním řadičem a jeho proprietárním formátem metadat a všechno je fuč, bez šance na obnovu na jiném systému.
Zadruhé, většina takzvaně hardwarových takzvaných RAIDů je ve skutečnosti AID bez R, který jen čeká jako žralok s otevřenou hubou, kdy bude moci sežrat data.
Chci použít SW raid.
Dobrý nápad, ale pozor na věc:
Souborové systémy se skutečným RAIDem jsou například Btrfs nebo ZFS.Ano, btrfs má sice skutečný RAID, a tazateli by se mohlo líbit, že do toho může snadno přidat ty 3 disky a mít 1.5násobek kapacity, a taky snapshoty, kompresi a další super funkce, ale naprostý fail je, že btrfs (a asi ani ZFS, ale to nepoužívám) nemá (použitelný) fsck. Takže až se mu to rozbije tak je nahranej (doporučovaný a asi jediný použitelný postup je odlejt data pryč, vytvořit FS znova a nalejt data zpátky).
…ale naprostý fail je, že btrfs (a asi ani ZFS, ale to nepoužívám) nemá (použitelný) fsck…
Tohle je naprostý nesmysl a naprosté nepochopení, k čemu u starých a špatných souborových systému (ne)sloužil fsck.
Takže až se mu to rozbije tak je nahranej…
S čím tady srovnáváme? Co je baseline? S Ext4 bude tahle „nahranost“ mnohem horší a pravděpodobnost rozbití mnohem vyšší. Takže, co přesně je ten svatý grál, který funguje lépe než Btrfs a ZFS? Yeti už byl viděn, ale ta zázračná technologie dosud ne.
Tohle je naprostý nesmysl a naprosté nepochopení, k čemu u starých a špatných souborových systému (ne)sloužil fsck.Já si myslím, že fsck slouží ke zjištění a opravě (potenciálně se ztrátou dotčených souborů, které si obnovíš ze zálohy) souborového systému, u kterého se poškodily invarianty datových struktur (že listy stromů a pointery hashtables neukazují na nesmyslná místa, že jsou všechny bloky označené jako alokované dostupné, a já nevím co vlastně FS dělá). Koneckonců teď jsem si otevřel manuál k btrfs fsck a tam se píše přesně tohle:
The filesystem checker is used to verify structural integrity of a filesystem and attempt to repair it if requested. The structural integrity check verifies if internal filesystem objects or data structures satisfy the constraints, point to the right objects or are correctly connected together. There are several cross checks that can detect wrong reference counts of shared extents, backreferences, missing extents of inodes, directory and inode connectivity etc.No a problém je v tom, že se na té stejné stránce píše taky
Warning Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.Jako možná už to funguje, už jsem to nějakou dobu nezkoušel. Ale s těmi varováními to nepůsobí moc důvěryhodně. Samozřejmě je možné, že autoři btrfs mají jinou hranici toho, před čím považují za nutné varovat, a ve skutečnosti to funguje stejně dobře jako fsck klasických fs. A kdy třeba se takový fsck může použít? Třeba když máš filesystém, který projde scrubem, a přitom se na něm děje tohle:
root@ferda:~/psql_bonanza_backup# ls pg_stat_tmp/ db_0.stat db_0.stat db_0.stat db_0.stat global.stat global.stat global.stat global.stat global.tmp global.tmp global.tmp global.tmp db_0.stat db_0.stat db_0.stat global.stat global.stat global.stat global.stat global.tmp global.tmp global.tmp global.tmp root@ferda:~/psql_bonanza_backup# ls -l pg_stat_tmp/ ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory total 0 -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? db_0.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.stat -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmp -????????? ? ? ? ? ? global.tmpJak to mohlo vzniknout? Třeba softwarovým bugem (race condition…), hardwarovým bugem disku (HW kecá co už zapsal a co ještě ne a přehazuje pořadí zápisů) nebo hardwarovým bugem paměti či procesoru (stroj nemá ECC, na stroji se přehřívá CPU a dělá chyby).
S čím tady srovnáváme? Co je baseline? Takže, co přesně je ten svatý grál, který funguje lépe než Btrfs a ZFS?Baseline je, že na ext4 pustím fsck, a ono se to ve většině případů dostane do konzistentního stavu. Možná to přijde o pár souborů, ty obnovím ze zálohy. Pokud to bylo fakt hodně špatný, tak pak je samozřejmě lepší FS zrušit a vytvořit znova.
S Ext4 bude tahle „nahranost“ mnohem horší a pravděpodobnost rozbití mnohem vyšší.Nebo nebude, protože je jednodušší a tak tam je méně věcí co se můžou rozbít (to není výtka na btrfs, pokud chceš mít všechny ty funkce, co btrfs poskytuje, tak to prostě složité být musí). Nebo nebude protože je víc otestovaný. A nebo samozřejmě bude, pokud je tvým problémem zrovna ten typ selhání disku který zachytí btrfs checksum.
Jen ze zajímavosti, ta chyba nastala na jakém kernelu / verzi btrfs / čase?Celkem nedávno, byl to Buster s kernelem 5.6 z backports, a pak se to upgradovalo na Bullseye s distribučním 5.10, a někdy tou dobou se to stalo. Je to Ryzen 5 3600, desktopová deska, desktopová nvidia a lidi na tom dělají machine learning a byly tam různé problémy - myslím že to vytuhávalo (nebo to byl vedlejší stroj?), několikrát jsme tomu natvrdo vyhodili elektřinu, procesor ukazoval nějak vysokou teplotu ale možná to byl bug ve čtení senzorů, dělají na tom junioři a už jsme měli případ že se jim něco zacyklilo a postgres asi za měsíc zapsala 100TB (většina povoleného TBW disku) než jsem si toho všiml a dokopal je to opravit, atd. Takže ano, technicky je to dost příšerný počítač a věřím že to klidně mohlo být způsobené HW chybou RAM/CPU nebo tomu třeba nvidia driver corruptnul nějaké datové struktury, ale tazatel taky neříká že ten jeho NAS je nějaký super spolehlivý server. Redundance použita nebyla, ale vzhledem k tomu, že scrub prochází, by to asi nepomohlo.
Baseline je, že na ext4 pustím fsck, a ono se to ve většině případů dostane do konzistentního stavu.
Jak? Jak může bez atomicky udržovaných checksumů dat poznat konzistentní stav? Tenhle princip fungování fsck je jakýsi sen, nikoliv realita.
Dobře, dejme tomu, zkusí asi obnovit konzistentní stav (většinou) checksumovaných metadat; čert vem data. To je ovšem poněkud nedostatečné.
Jak to mohlo vzniknout?
Tohle jsem už zažil. Nevím, jak to vzniklo, ale vzpomínám si, za jakých okolností.
Před lety jsem měl SSD s firmwarem nekompatibilním s Linuxem, který dělal cosi neobvyklého při uspání. Systém následně vypadal jako hrad Trosky. Po cca 20+ násilných restartech z nevysvětlitelného stavu systému se tohle stalo — v nějakém adresáři bylo pár položek se stejným názvem.
Opravil to tenkrát (tolik obávaný) btrfs check --repair
, žádný problém. Jinak souhlasím, že taková věc by neměla projít scrub
em bez varování (a bohužel prošla).
Nechápu ovšem, oč lépe by stejnou situaci ustál Ext4 a jakou by mi dal záruku, že jde opravdu jen o poškození metadat v nějakém adresáři a že nejsou poničené moje datové bloky.
Pokud selhává hardware (který ve „spotřebitelském sektoru“ už desetiletí a půl nezaručuje, že „bariéra je opravdu bariéra“), nepopere se s tím korektně žádný souborový systém.
Aktualizace firmwaru od SSD tohle vyřešila, nepříliš překvapivě.
Takže se znova ptám: Kde je ten zázračný baseline, se kterým Btrfs srovnáváme?
…and then only after having accepted that no fsck successfully repair all types of filesystem corruption…
A tohle^^^ platí pro Ext4 mnohem víc než pro Btrfs, že jo.
Nebo nebude protože je víc otestovaný.
Takže ty statisíce strojů Facebooku, které mají už snad desetiletí Btrfs RAID1, nejsou dostatečný test? Stále nechápu, co je baseline pro srovnání.
A nebo samozřejmě bude, pokud je tvým problémem zrovna ten typ selhání disku který zachytí btrfs checksum.
Dejme tomu, že mým problémem bude přepsání (omylem, lidský faktor atd.) jednoho ze tří disků v RAID1 konfiguraci nulami.
Rádoby-abstraktní AID s Ext4 následkem toho kontaminuje a/nebo zničí všechna moje data. Chvíli mi navíc může vracet náhodné, nulovými bloky prokládané nesmysly, než se konečně položí.
ZFS a Btrfs i takovou mezní situaci ustojí a nebudou mi vracet poničená data. Jen v dmesg
bude dost dusno.
Jak může bez atomicky udržovaných checksumů dat poznat konzistentní stav?Konzistentní stav se pozná tak, že jsou právě všechny obsazené bloky dosažitelné, všechny soubory mají čitelná metadata (jak bylo ukázáno), nejsou tam hardlinky na adresáře atd. Samozřejmě to není konzistentní stav z hlediska aplikací a toho že soubor co jsi někam uložil a poté úspěšně proběhl fsync tam taky najdeš. Ale většinou je dost jasně vidět kterých souborů se to týká (právě z těch metadat) a tedy co je potřeba obnovovat a jestli je to problém.
Jinak souhlasím, že taková věc by neměla projít scrubem bez varování (a bohužel prošla).Protože scrub jenom zaručuje, že bloky, co jsme přečetli, jsou bloky, co jsme (někdy) před tím zapsali. V žádném případě nezaručuje, že obsah těch bloků je smysluplný, a bohužel ani příliš nezaručuje, že bloky jdou chronologicky. Bohužel se tohle málo ví, a leckdo říká "haha mám scrub, nepotřebuju fsck!", a je potřeba upozorňovat na to, že to tak není. A pak má na FS chyby, o kterých se nemá jak dozvědět, a narazí na ně až v okamžiku, kdy se třeba pokusí zapsat do nějakého souboru. (btrfs je dobrej že alespoň má nějaký fsck, ZSF pokud vím nemá vůbec nic)
Nechápu ovšem, oč lépe by stejnou situaci ustál Ext4 a jakou by mi dal záruku, že jde opravdu jen o poškození metadat v nějakém adresáři a že nejsou poničené moje datové bloky.Nedal by ti takovou záruku (btrfs ti ji taky nedává, stejně jako se poškodily bloky s metadaty se mohly poškodit i bloky s daty), ale pro opravu bys nemusel použít nástroj, který má na začátku dokumentace tučné varování, že ho nemáš používat.
A tohle^^^ platí pro Ext4 mnohem víc než pro Btrfs, že jo.Nevím proč by to mělo platit mnohem víc, napsal jsem nějaké důvody hovořící pro btrfs a nějaké pro ext4 a jejich přesné vyhodnocení by vyžadovalo v podstatě neproveditelnou analýzu konkrétního nasazení.
Zkrátka, Btrfs a ZFS dávají nesrovnatelně silnější záruky konzistentnosti dat než Ext4 béčko bez checksumů. To je celé. Takhle jednoduché to je.
Pročež tazateli (jako obvykle) doporučuji: Vyhni se Ext4 — béčku spoléhajícímu na zázraky — a použij takový souborový systém, který chápe, jak tenhle vesmír funguje, tedy Btrfs nebo ZFS.
Že prý ZFS nemá „fsck“ — no a? Kdo takový nesmysl na ZFS kdy potřeboval? No nehlaste se všichni.
Máš to rozbité.
Ten béčkový AID jsi testoval na přesně stejném hardwaru jako Btrfs? Nebo jsi (jako spousta jiných známých mudrců) dával Btrfs na vyřazený šrot, zatímco AID z nějakého důvodu dostal nový hardware? Režim povozu byl taky přesně stejný? Jenom se ptám, čisté pro úplnost.
(Nebo jsi na AID taky ztratil data, jenom jsi o tom (kvůli absenci checnsumů) nevěděl?)No a pak tu ještě kdysi byla ta sorta lidí, která zkoušela Btrfs na 5 let zastaralé sračce typu Debi(l)an a následně v roce 2014 říkala: „Šmarja! Jak to, že tam mám bugy z roku 2009???“ No … ehm … byly tam. Co se dá dělat…
Pořád lepší než rozesraný Ext4 každé tři roky, jak velí neochvějná tradice. Nemluvě o silent data corruption, která pracuje průběžně a 3 roky nečeká.
Má kernel ne starší než měsíc.
k3dar@t430s:~$ lsb_release -d Description: Ubuntu 20.04.4 LTS k3dar@t430s:~$ uname -vr 5.17.7-051707-generic #202205121146 SMP PREEMPT Thu May 12 13:20:51 UTC 2022
Pořád lepší než rozesraný Ext4 každé tři roky, jak velí neochvějná tradice. Nemluvě o silent data corruption, která pracuje průběžně a 3 roky nečeká.Máte to rozbité. Narozdíl od ostatních, kterým ty ext4 fungujou v tisícovkách bez výpadku a bez ztráty dat.
Tohle jsou zase perly. No, stane se. Já ti to zkusím vysvětlit polopatě.
Jak pomůže bezpečnostní pás, když na stojící auto spadne vagón olova?
Inu, bezpečnostní pás v takové situaci nijak nepomůže. To ale ještě neznamená, že by bezpečnostní pás nebyl důležitý. Pomáhá totiž v mnoha jiných nebezpečných situacích.
Tak. Už?
Ještě polopatěji: Btrfs, ZFS a plně checksumované souborové systémy prospívají tím, že místo celé pravděpodobnosti poškození dat v bloku čelí uživatel jenom pravděpodobnosti poškození dat v bloku krát pravděpodobnost kolize checksumů. To druhé (součin) je nesrovnatelně menší než to první.
Pravděpodobnost současného poškození několika bloků tak, že to čirou náhodou bude vypadat jako platná data, je cosi z říše fantazie. Jasně, nulová není, ale…
Úmyslně změnit data na Btrfs a odpovídajícím způsobem upravit všechny datové struktury je postup (v konečném důsledku) nerozlišitelný od skutečného zápisu — použijme tedy zdravý rozum, Occamovu břitvu atd. atp.
Ale hovno.
U Ext4 se nedá nijak poznat, jestli funguje bez ztráty dat.
Že prý ZFS nemá „fsck“ — no a? Kdo takový nesmysl na ZFS kdy potřeboval?WTF, vždyť o tom je celé vlákno. Dokolečka dokola: Jak teda FS bez fsck řeší detekci a opravu chyby struktury způsobené ať už SW (klidně můžeme připustit, že je driver FS bezchybný, ale kdokoli jiný v kernelu mu mohl přepsat kus dat) nebo HW bugem (RAM bit flip)?
Takže ty statisíce strojů Facebooku, které mají už snad desetiletí Btrfs RAID1, nejsou dostatečný test?Měl byste se řídit vlastní radou a hledat ve zdejší historii. Facebook skladuje zejména data, u kterých neposkytuje naprosto žádné záruky, že zítra budou tam, kam je uživatelé včera nahráli. Takže to není žádná metrika spolehlivosti souborového systému.
Samozřejmě nemá pravdu. Jako obvykle.
Btrfs RAID 5/6 je dávno vyřešené téma.
dmraid
/ mdadm
. Btrfs RAID 5/6 strčí vše zmíněné do kapsy, pokud jde o spolehlivost, už asi tak 5+ let.Když měníš disk, je to pomalá operace, která ho navíc šíleně zatíží.Rychlost rebuildu pole je volitelnou ve většině HW/SW implementací RAID. U pole postaveném nad SSD by to asi nemělo představovat větší výzvu. Samozřejmě u HDD-based RAID mix sekvenční zátěže(rebuild) a náhodné zátěže(aplikace) uživatele asi nepotěší. Uvažujme v kontextu min. RAID6, kdy zbývající redunance zajistí po dobu rebuildu ochranu proti výpadku dalšího disku (doba rebuildu je volbou mezi vytizenosti a prodlužováním rizika vyplý́vajícího z dočasně omezené redundance). Nemám nic proti oprávněné glorifikaci ZFS, ale je třeba si uvědomit že úspěšná kariéra většiny zde leží právě na základech desetiletí úspěšného fungování zatracovaného HW/SW RAIDu. Kontrola konzistence RAID pole se typicky provádí periodicky, co má ZFS za ekvivaletní aparát, který informuje o stavu kondice celé dostupné kapacity v rámci všech zúčastněných členů?
Tiskni
Sdílej: