Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
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.
Je to naprosto zbytečné. Když má RAID1 poškozená data na jedné z kopií, neexistuje spolehlivý způsob, jak zjistit, která kopie je ta správná. RAID1 naivně počítá s tím, že jediné selhání, které může nastat, je úplné selhání jednoho z disků. V takovém případě se data zkrátka budou číst jenom z druhého (resp. z ostatních) a nebudou se číst (až tolik) prokládaně. (Tedy throughput při čtení bude nižší.) Když všechny disky (přinejmenším zdánlivě) správně fungují, nikdo nikdy neodhalí poškozená data. Dokonce se může klidně stát, že se při každém čtení téhož souboru (s dostatečně dlouhým odstupem v čase i v objemu přečtených dat, aby původní data už nebyla v RAM) vrátí jiná data.
Pokud jde o klasický softwarový nebo hardwarový RAID 1, který nemá nic společného s filesystémem, jeho opakované kontroly nemají v podstatě žádný smysl. Když se na jednom z disků poškodí data, kontrola může klidně způsobit, že se poškozená data odpropagují na nepoškozené disky. Nebo taky naopak, při troše štěstí. Když má člověk RAID 1 se třemi disky, může se při kontrole alespoň použít ta verze dat, která převažuje. Nicméně se 2 disky nic takového nejde. Hlasování se sudým počtem hlasujících je vždy problém. Při třech discích a třech rozdílných verzích dat je taky každá rada drahá.
Řešením je jedině RAID 1 na úrovni filesystému (Btrfs, ZFS). Atomické checksumy zajistí, že při poškození dat na jedné z replik je vždy možné zjistit, která replika má pravdu, a (především) odhalit, že jsou data nějak poškozená. To vše při zachování (téměř) N-násobného throughputu při čtení, kde N je počet disků v RAID 1 konfiguraci.
Kontrola ano, oprava ne. Pokud z každého disku přečte jiná data, tak není možnost jak by poznal, která jsou ta správná.
Já bych doporučil check (určitě ne neustálou rekonstrukci pole, tím spíš se chyby zpropagují), po checku kontrolu /sys/block/md0/md/mismatch_cnt
(skripty v některých distrech to ostatně dělají automaticky), long test je v pořádku.
A pokud mismatch_cnt nebude 0, tak hodně štěstí. A funkční zálohy.
On většinou nepřečte z každého disku jiná data, protože čte data jenom z jednoho disku, tedy z několika disků prokládaně, aby se četlo rychleji. Na rozdíl v datech přijde leda až při nějaké explicitní kontrole, což už je zoufale pozdě, protože tou dobou už se poškozená data mohla přečíst a zapsat jinam, vrátit aplikacím a podobně. RAID na úrovni filesystému přijde na chybu v datech hned při čtení (i při prokládaném čtení), protože v případě chyby nesedí checksum. Pak lze podle checksumu najít na ostatních RAID1 discích kopii, která je platná.
On většinou nepřečte z každého disku jiná data, protože čte data jenom z jednoho disku, tedy z několika disků prokládaně, aby se četlo rychleji.
Tak při běžné činnosti jistě, tazatel se ale ptá na raid check / repair.
Naivnim pristupem bych to nenazval. Poskozeni dat ve smyslu nekonzistence vznikle poruchou ci chybou na plotne odhali interni checksum disku, takze disk vrati sektor jako chybny a system pouzije druhy mirror.
A toto funguje? Co jsem se setkal, tak nastávají dva případy. Buď se to disku podaří přečíst sektor a realokovat (což je činnost vlastního firmware disku) nebo disk vrátí chybu, potom ho raid vyřadí (a vrací data z jiného disku).
To co popisuješ afaik platí až pro systémy souborů s interním checksumem, kde chybná data zjistí až právě FS a ten se může pokusit ono vadné zrcadlo (obecně redundanci) opravit tím, že na nej zapíše správná data (potom opět nastane to, že disk to buď po vlastní ose zapíše, nebo je vadný a vrátí chybu).
Dle meho spise miri na dementy vseho druhu, co prepisou pomoci dd cokoli aniz by se zamysleli.
Zažil jsem hw řadič, který si výměnu disku po havárii starého interpretoval tak, že ten nový disk do mirroru prostě přidal a vůbec mu nevadilo, že oba disky v mirroru obsahují něco úplně jiného. Jaksi přeskočil synchronizaci. V tomto případě šel fs a data do kytek.
A toto funguje? Co jsem se setkal, tak nastávají dva případy. Buď se to disku podaří přečíst sektor a realokovat (což je činnost vlastního firmware disku) nebo disk vrátí chybu, potom ho raid vyřadí (a vrací data z jiného disku).Ano, i po chybe jednoho sektoru je disk z mirroru vyrazen. Zcela spravne a po zasluze. Spravce dostane email nebo cokoli a musí se situaci zabyvat. Jen jsem psal, ze raid1 nechrani jen pred uplnym selhanim disku. Jeste mozna poznamka - pokud se dobre pamatuji, kdyz je disk rozdelen a zmirrorovan po castech, je vyrazen jen prislusny oddil.
Zažil jsem hw řadič, který si výměnu disku po havárii starého interpretoval tak, že ten nový disk do mirroru prostě přidal a vůbec mu nevadilo, že oba disky v mirroru obsahují něco úplně jiného. Jaksi přeskočil synchronizaci. V tomto případě šel fs a data do kytek.Souhlas, chrani to take proti levnemu smejdu z vesmiru.
To je sice pravda, ale pokud v průběhu „check“ dojde k selhání tak o tom víš, bo to disk vyhodí - tak aspoň něco .
Pokud nebude swap na tom poli, tak false positive se vyskytnou jen ve specifických případech, takže lze mismatch_cnt normálně kontrolovat (tak jsem to pochopil a vyšlo mi to…).
Mám starší Raid1 na kterém je swap, který se i používá a běží na tom virtuály (XEN) a nikdy mismatch_cnt nebylo rozdílené od 0. Zkoušel jsem to na jiném stroji (RAID1) s virtuály a vyvolanou pseudo zátěží, a podařilo se mi toho docílit 1× (při pseudo-testování asi 6hod), pokud jsem hostitelský swap zahltil a systém se v zásadě uchlastal, ale není to jen tak, protože zmiňovaný script (raid-check) běží s nízkou prioritou a parametry (speed_limit_min, speed_limit_max) jsou/mám taky relativně nízké, takže k souběhu těch událostí nedochází. Je to o více paramtrech, takže ano, může to hlásit false positive, ale není to pravidlo, že bude (a komu se to děje pravidelně ať mě nekamenuje…).
Na základě toho kontroluji mismatch_cnt a protože to do swapu nechodí (ani virtuály), tak už několik měsíců a žádný mismatch se nezjevil (CentOS-í default - kontrola v neděli v noci…).
Ale souhlasím, je to naprd, ¡spravte to někdo!
dd if=/dev/zero bs=1M of=/bigfile;sync;sync;rm /bigfile
Tiskni
Sdílej: