V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
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: