Byly publikovány informace o zranitelnosti CVE-2026-46243 pojmenované CIFSwitch v Linuxu od roku 2007. Běžný uživatel může získat práva roota (lokální eskalaci práv). V upstreamu je již opraveno.
Nvidia na své konferenci NVIDIA GTC Taipei 2026 představila řadu novinek. Společně s Microsoftem představili superčip NVIDIA RTX Spark (až 6 144 jader GPU, 20 jader CPU, 1 petaflop AI výkonu v FP4 a 128 GB jednotné paměti). První notebooky a stolní počítače s tímto čipem od Nvidie místo Intelu nebo AMD by se měly na trh dostat na podzim letošního roku.
Na Kickstarteru běží kampaň na podporu kapesního počítače s Linuxem CardputerZero od společnosti M5Stack. Postaven je na Raspberry Pi Compute Module 0. Podporuje moduly M5. Koupit lze s rozšířeními LoRa a CC1101.
Tento týden se bude vyznačovat zejména deštěm, a proto vás může zajímat, že již v úterý proběhne 63. Virtuální Bastlírna, která se bude odehrávat přímo v teple vašich domovů a bastlíren. Proto se připojte k této volné otevřené diskuzi bastlířů, techniků, vědců, ve které se probírají novinky a zajímavá témata z techniky. Mezi největší novinky bude tentokrát patrně patřit oznámení hackerského nástroje Flipper One. Zároveň úspěšně probíhá
… více »86Box (Wikipedie), tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 6.0. Přibyly například zvuky pevného disku. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Byla vydána nová verze 4.6 audio přehrávače Audacious (Wikipedie). Z novinek lze vypíchnout nový plugin pro procházení soubory, podporu audio formátu Musepack SV8 nebo přechod na build systém Meson.
Alliance for Open Media vydala verzi 1.0.0 specifikace svobodného videoformátu AV2. Jean-Baptiste Kempf, prezident neziskové organizace VideoLAN stojící za svobodným multiplatformním multimediálním přehrávačem a frameworkem VLC, představil na svém blogu dekodér AV2 s názvem dav2d.
V aktuálním přehledu vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) bylo oznámeno vydání nové verze 0.2.0.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.5.1. Přehled novinek na GitHubu.
Byla vydána nová stabilní verze 26.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Yarara. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Pokud chcete RAID1 ze dvou disků, je otázka, co vám přinese řešit to pomocí btrfs. Myslím, že stejnou službu jako btrfs vám v takovém případě udělá i mdadm a teprve nad ním můžete mít btrfs.Třeba možnost řešení některých případů silent-data-corruption? Když mi jeden disk vrátí blok jako OK, ale btrfs nesouhlasí checksum, nemůže v případě mdadm dělat nic. V případě RAID1 na úrovni btrfs může zkusit týž blok přečíst z druhého disku a opravit ho na prvním. Takový ZFS to umí, a je to jeden z důvodů proč pod něj nedávat jiný RAID (mdadm, HW).
To, že pole pokračuje v provozu dál, už je popis nějakého chování, které je ve skutečnosti v rozporu s tou definicí.Jo, ale za předpokladu, že si tu definici nejdřív vhodně roztrhnete a nepohodlný kus odstraníte. Jinak jako vždycky melete ptákoviny. Mít možnost to jednou připojit v degradovaném režimu a pak už to bude read-only, znamenalo dodatečnou práci na straně vývojářů a tedy nic, co by tam bylo pro další vývoj v rámci vylepšování uživatelské stránky. Další vývoj už tam byl, někdo přidal čítač/flag a dodatečné chování. Chování, které naprosto jednoznačně popírá účel RAIDu: umožnit nepřerušené poskytování služby v případě havárie hardware.
Chování, které naprosto jednoznačně popírá účel RAIDu: umožnit nepřerušené poskytování služby v případě havárie hardware.Jenže to je nepochopení RAIDu (bohužel časté nepochopení). RAID neslouží k nepřerušenému poskytování služby v případě havárie, RAID slouží k předcházení škodám způsobených havárií – tedy k minimalizaci ztrát dat a ke zkrácení doby výpadku. Když vám z dvoudiskového RAID 1 vypadne jeden disk, máte dvě možnosti – buď pokračovat dál s jedním diskem a modlit se, aby nevypadl ani ten, a nebo systém zastavit, zreplikovat data na druhý disk a spustit ho znovu v režimu RAID 1. Oba případy jsou legitimní, a správce musí vědět, která varianta platí. Někdy je totiž opravdu mnohem levnější na chvíli zastavit systém a opravit ho, než riskovat ztrátu dat. Třeba banka radši bude chvíli sypat požadavky na příkazy k úhradě do fronty a neprovádět je, než aby je dál potvrzovala a zapisovala do systému, který může selhat – a banka pak bude mít den starou zálohu a k tomu hromadu potvrzených transakcí, o kterých nic neví.
Disk se naprosto bezne vymenuje za chodu, bez jakyhokoli vypadku systemu.Jenže tohle není jediný způsob, jak docílit bezvýpadkovosti. Vlastně je to ten nejhorší způsob. Komu nikdy nekleklo pole nebo řadič při výměně disku, ať hodí ... zálohovací páskou. A tenhle zastaralý způsob přemýšlení nad storage mě vlastně na celé věci vadí nejvíc. Sám používám BTRFS od roku 2010, v 2011 jsem napsal články a od té doby to jenom používám k maximální spokojenosti. A v roce 2020 vyjde článek, který se na btrfs dívá optikou starých storage někdy z 80 let. Prostě storage se nedělá tak, že to závisí na jednom stroji. U normálně navrženého storage (a nejen to, libovolného systému) nelze spoléhat na stabilitu jednoho stroje, ale je potřeba to mít distribuované. A potom je úplně jedno, jestli k výměně disku ten FS musím odmountovat nebo ne. Data pro klienty budou dostupná. A pokud změním myšlení tímto směrem, tak se současně odlehčí nároky na ten daný FS. Je fakt úplně jedno, jak se to zachová pouze s jedním diskem. Data jsou jinde. Na místo takových kravin ten fs může řešit podstatnější věci, jako atomické snapshoty, nezávislé subvolume apod. Ne, místo toho se hromada lidí zasekla v době někdy před 20 lety a požadují nejdřív funkční RAID podle jejich zkreslených představ, včetně nesmyslných R5/6 a až potom si možná přečtou něco navíc. Kdy ty vyšší funkcionality začnou používat fakt nevím. Ale což, tohle myšlení se projevuje i v jiných oblastech. Dneska každý může mít 10 emailových účtů, ale jsou lidé, kteří si hýčkají jen ten jeden a rozčilují se při sebemenším výpadku. Takže jo, klidně si stavte jedno 50 diskový pole, které když z libovolných důvodů vypadne, tak musíte poslat zaměstnance domů, protože to přece nejde vyřešit nijak jinak...
degraded, a jádro už si samo domyslí, jestli tím myslíte RW nebo RO.
Je mozne, ze nad tim proste nikdo ani vterinu nepremyslel a proste to tam jen tak placnul. Mimochodem MS ma podobny system (umi redundanci na zarizenich, nemusi mit stejnou velikost proste to jen garantuje, ze tam jsou 2 kopie na 2 discich (nebo vic dle nastaveni)) jmenuje se storage spaces. Svete div se- RAID1 tomu rezimu nerikaji.
man mkfs.btrfs (starej debian 9 - old stable). Názornější už to snad být nemůže.
RAID
a block group profile type that utilizes RAID-like features on multiple devices: striping, mirroring, parity
PROFILES
There are the following block group types available:
┌────────┬────────────────────────────────────┬────────────────────┐
│ │ │ │
│Profile │ Redundancy │ Min/max devices │
│ ├──────────────┬────────┬────────────┤ │
│ │ │ │ │ │
│ │ Copies │ Parity │ Striping │ │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│single │ 1 │ │ │ 1/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ DUP │ 2 / 1 device │ │ │ 1/any (see note 1) │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID0 │ │ │ 1 to N │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID1 │ 2 │ │ │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│RAID10 │ 2 │ │ 1 to N │ 4/any │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID5 │ 1 │ 1 │ 2 to N - 1 │ 2/any (see note 2) │
├────────┼──────────────┼────────┼────────────┼────────────────────┤
│ │ │ │ │ │
│ RAID6 │ 1 │ 2 │ 3 to N - 2 │ 3/any (see note 3) │
└────────┴──────────────┴────────┴────────────┴────────────────────┘
Jelikoz to neni zdaleka prvni pripad, ktery vidim, ze se na tohle nekdo nachytal tak to vidim jako problem. Pritom to stacilo projevit trochu empatie, predvidavosti ze na druhe strane bude chybujici zaneprazdneny clovek a naznacit mu, ze je neco jinak... treba nazvem BTRFS REDUNDANCY1 nebo tak neco. Nic tezkeho.Chápu jak to myslíš, ale nesouhlasím se závěrem. Pokud si někdo při nasazení nové technologie nepřečte ani manuálovou stránku, tak mu ani jiné pojmenování příliš nepomůže, jen zkrátka narazí někde jinde. Obvykle o něco později, kdy bude ještě složitější to vyřešit. Zkrátka každá profese vyžaduje pokoru v určitých místech a k běžné práci admina patří i to, že čte dokumentaci a zkouší si různé scénáře provozu dané technologie. To je alespoň můj pohled na svět a moje zkušenost, ještě jsem nenarazil na žádnou technologii, který by neměla nějaké vedlejší efekty, které by mi bez čtení dokumentace / testů byly dopředu zřejmé.
Ne najednou, ale pokud se mezi smrti tech jednotlivcu stihne prepocitat pole, tak muzou umrit.Jasně a toto je dost silná podmínka. V nějaké diskusi vedle někdo radil použít co nejvíc do nejmenších disků. Jenže i to narazí na pravděpodobnost úmrtí dalšího disku během rebalance. Pokud do btrfs raid-1 dám 50 disků (jak se někdo ptal), tak pravděpodobnost výpadku dalšího disku během rebalance po výpadku prvního už není zrovna malá. A když se to stane, tak se 100% přišlo o část dat. Jednoduše proto, že btrfs ty bloky rozhazuje více méně náhodně, takže lze tvrdit, že kopie bloků z libovolného jednoho disku jsou rozprostřeny na zbývajících 49 diskách. A když po výpadku jednoho disku vypadne i další, tak se 100% přišlo o nějaká data. A vzhledem k tomu, že stačí, aby vypadl libovolný náhodný disk, tak šance na ztrátu dat s větším počtem zařízení dost rychle roste. Proto bych ocenil (a už to má být v 5.5) zvolit vyšší míru redundance. 3 pro větší počet disků se zdá být velmi rozumné.
Tiskni
Sdílej: