Byla vydána nová verze 9.17 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Je třetí sobota v září a proto vše nejlepší k dnešnímu Software Freedom Day (SFD, Wikipedie).
Bogdan Ionescu rozběhl webový server na jednorázové elektronické cigaretě.
Byla vydána beta verze Ubuntu 25.10 s kódovým názvem Questing Quokka. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.10 mělo vyjít 9. října 2025.
Bola vydaná nová verzia 4.13 security platformy Wazuh. Prináša nový IT hygiene dashboard, hot reload dekodérov a pravidiel. Podrobnosti v poznámkách k vydaniu.
Americký výrobce čipů Nvidia investuje pět miliard dolarů (přes 100 miliard Kč) do konkurenta Intel, který se v poslední době potýká s vážnými problémy. Firmy to včera oznámily ve společné tiskové zprávě. Dohoda o investici zahrnuje spolupráci při vývoji čipů pro osobní počítače a datová centra. Akcie společnosti Intel na zprávu reagovaly výrazným růstem.
Dlouholetý balíčkář KDE Jonathan Riddell končí. Jeho práci na KDE neon financovala firma Blue Systems, která ale končí (Clemens Tönnies, Jr., dědic jatek Tönnies Holding, ji už nebude sponzorovat), někteří vývojáři KDE se přesunuli k nově založené firmě Techpaladin. Pro Riddella se již nenašlo místo. Následovala debata o organizaci těchto firem, které zahraniční vývojáře nezaměstnávají, nýbrž najímají jako kontraktory (s příslušnými důsledky z pohledu pracovního práva).
V Amsterdamu probíhá Blender Conference 2025. Videozáznamy přednášek lze zhlédnout na YouTube. V úvodní keynote Ton Roosendaal oznámil, že k 1. lednu 2026 skončí jako chairman a CEO Blender Foundation. Tyto role převezme současný COO Blender Foundation Francesco Siddi.
The Document Foundation, organizace zastřešující projekt LibreOffice a další aktivity, zveřejnila výroční zprávu za rok 2024.
Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
ddrescue /dev/sdx /dev/sdy disk-logKopie zašifrovaných dat. Výsledek
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ddrescue byl pouhých 16KB nepřečtených dat na 2T disku.
Pak následovala fyzická výměna disku a díky tomu, že disk se skládl na UUID tak se pole automaticky složilo. A následnýbtrfs scrub start /mnt/polezahlásil asi 17000 opravitelných chyb, žádné neopravitelné chyby a pole bylo v pořádku. Podle mne včasné varování na problémy s diskem mě zachránilo od větších potíží a btrfs RAID 1 považuji za velmi funkční.
Tiskni
Sdílej:
fyzický disk -> LUKS > btrfs RaidNicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždycky
Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.Nižší vrstva LUKS v XTS modu a (stejně si myslím že i v jiných) nemá žádnou kontrolu a vezme blok z disku, prožene ho algoritmem a dodá blok do vyšší vrstvy. A můžeme to chápat jako prosté substituční zobrazení blok na blok, kdy samozřejmě zobrazení závisí na číslu bloku. Pokud btrfs pracuje se stejnými bloky jako LUKS, tak podstavná vrstva nesníží nijak obecnost a spolehlivost btrfs, protože ano při malé chybě v HW dodá LUKS sice zcela jiný blok, ale ten by i při malé chybě btrfs označil jako chybný a řešil chybu na úrovni bloku. Pokud nejsou data z LUKSu ok, není to, že problém má LUKS (pokud by nenastalo nějaké kritické prolomení) ale problém má HW, LUKS ten problém přenese na vyšší úroveň a btrfs ho identifikuje. A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni. Možná na úrovni souborů, ale tím jsou názvy souborů a struktura adresářů veřejná, veracrypt kontainer a cokoliv, co nevyužije CoW je nesmysl. Jediná nevýhoda, kterou v mém postupu vidím, že stejná data se pro každý disk šifrují jinak, takže zvýšení zátěže u krypto vrstvy. Jinak vše mi připadá OK a tento zvýšený overhead akceptuji.
Nicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždyckyTo sice jo, ale z principu, protože jde o COW systém bych řekl že tam dochází k většímu žonglování s daty, protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat. Ale nevím. Možná se mýlím.Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.
A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace. Ale nevím. Nepoužívám to, protože mě k tomu nic nenutí a navíc šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení. Ale pokud ti ten zbytečný overhead nevadí, tvoje věc.
protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat.Myslím, že data firmware disku nezajímají. Kompresované video silnými algoritmy je podobně "nedeterministické" (a myslím tím stream a ne obálku) FW vezme blok a uloží jej na pozici, max si zefektivní mechanické pohyby čtecích hlav. A CoW (ale jakýkoliv FS) ať dělá co chce, tak má elementární operaci s blokem dat a pokud je stejná velikost mezi FS vrstvou a diskem tak je to transparentní. (problém jsou když ty velikosti stejné nejsou a někdy ani nemohou být např standardní RAID 5 nad 4 disky má základní velikost
3 x strip a to není 2^x pro žádné x)
Netuším, co tím můžeš myslet. Na úrovni FS potřebuješ zašifrovaná data a v paměti potřebuješ pracovat z rozšifrovanými daty. Pokud na disku nepotřebuješ zašifrovaná data a fyzickou bezpečnost máš zajištěnu jinak, nemusíš šifrovat. Stavět zašifrovaný souborový FS jako ecrypt nad btrfs je také pitomé.A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace.
[...] šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení [...]pokud nesifrujes tak nemusi nic louskat ani hledat jinej zpusob jak zistat data, kdyz mu je rovnou "das" nesifrovana
19.7.2020 22:24
mount -o degraded ... (nebo si ten "souhlas" dát do fstabu či linux cmdline).
Nikoliv. Tohle je naprosto správná reakce na ztrátu redundance. Je dobře, že se konečně opravdový RAID takhle chová. Názory, že pole, které má garantovat redundanci, by se mělo bez redundance jen tak sestavit a fungovat, jsou hluboce zakořeněná pověra, která ne a ne chcípnout. 
Situace s jedním poškozeným diskem v RAID1 se (zcela správně) považuje za kritickou. Data v takové situaci "bojují o holý život", řečeno patosem. Jediným a prvořadým cílem musí být obnovení redundance, nikoliv "obvyklý" provoz systému.
Kdyby se filesystém namountoval, jako by nic, dovedu si živě představit davy takyadministrátorů bez řádného monitoringu, jak by to napřed pár měsíců nepostřehli, pak by to dalších pár měsíců nechali dál "fungovat", když to do té doby "fungovalo", a nakonec by selhal i druhý / další disk. 
Řekl bych, že Facebook i řada dalších uživatelů Btrfs v business-critical nasazení ví velmi dobře, proč jim zrovna tohle chování vyhovuje.
pokud by pri 4x Disk v RAID1 delalo opravdovej RAID1, tedy mirror pres vsechny disky, nikoliv pouze block vzdy jen na dva, tak by toto degradovani kriticke nebylo...
Aha — takže 4 disky by měly mít v raid1 profilu kapacitu jednoho disku, podle tvého světonázoru?
Mimochodem, ráčil ses obtěžovat přečíst si dokumentaci? Tipuju, že (jako obvykle) ne. Proč číst dokumentaci, když se dá střílet od boku, že jo… Inu, je to takhle:
raid1 — 2 kopie, 1/2 kapacityraid1c3 — 3 kopie, 1/3 kapacityraid1c4 — 4 kopie, 1/4 kapacityTakže, kdyby tazatel opravdu (ale opravdu) chtěl 4 kopie — výměnou za polovinu kapacity ve srovnání s raid1 —, asi by zvolil raid1c4, ne?
Pojďme se ještě bavit o tom, jestli by se degraded pole s jedním chybějícím diskem mělo automaticky namountovat v raid1c4, dejme tomu.
Ne, nemělo.
Proč? Inu, ze stejného důvodu, ze stejného principu: Souborový systém má garantovat odolnost proti selhání kterýchkoliv 3 disků. Je v situaci, kdy tuhle odolnost garantovat nedokáže. Tedy situace je kritická a je na uživateli, aby rozhodl, jak ji řešit. To je stejná situace jako u raid1, jenom jiné N.
Pokud někdo s touto^^^ zásadou nesouhlasí, řešení je jednoduché: přidat do příkazové řádky kernelu rootflags=degraded (a někdy taky přidat degraded do /etc/fstab). Hotovo. Pak se to namountuje stůj co stůj, žádný problém, a řádný monitoring si musí uživatel zajistit po svém. Nebo taky ne; to už je jeho problém.
…i kdyz BTRFS dedela opravdovej RAID1, a kvuli obavam o data pri rebootu nesestavi pole, melo by alespon pripravit emergency consoly s dostupnym SSH, aby kompetentni admin usoudil zda nez se fyzicky dostavi na misto muze server nastartovat, nebo zda ma cekat nenastartovanej...
Huh? Cože? Že by jako Btrfs měl znova vynalézt kolo a vymyslet to, co normálně dělá + má dělat userspace v initramdisku? Jako vtip dobré.
Emergency shell je už asi tak 10+ let normální věc, ve které skončí každé distro, když se nepodaří otevřít a namountovat kořenový souborový systém. Nic nového pod sluncem. Tam se dají taky upravit parametry Btrfs.
Jestli má initramdisk SSH přístup, to už je věcí nastavení — nikoliv úkolem pro Btrfs. Serverový hardware má sériovou konzoli na odděleném ethernetu, takže mít SSH přístup do initramdisku by byl těžký overkill; stačí vzdálený přístup na sériovou konzoli. Hardware jiný než serverový je většinou vedle na stole, takže se bez SSH přístupu do initramdisku obejde.
Proč nemá initramdisk (většinou) lepší podporu pro Btrfs než obecnou konzoli, na to se ptej všech těch distribucí, které mají přes deset let zpoždění v zavádění Btrfs jako implicitního souborového systému. Dokud nebude Btrfs implicitní souborový systém, těžko se dá čekat 100% podpora pro jeho pokročilé funkce v initramdisku. Naštěstí se doba konečně mění a Fedora bude mít konečně (proč to 10 let trvalo???) Btrfs jako implicitní souborový systém. Snad se pak i podpora v initramdisku + dracutu výrazně zlepší.
Btrfs vynalézá jako první kolo, protože předchozí AIDy bez R ho nevynalezly. Nějaké další dotazy k tomu?
Netušíš, která bije. Howgh. A ještě se tím chlubíš. Doprdele šulin čurák piča už.
RAID 1-6 jsou naprosto jasně definované — bezva —, jenže žádná údajná implementace takové definice nesplňovala, dokud nepřišel ZFS a poté Btrfs.
ZFS a Btrfs poprvé implementují skutečnou redundanci. Bez planých slibů, s rozumně definovanými garancemi, atomicitou atd.
Na ZFS nebo Btrfs selhání jednoho disku nikdy neposere všechna data na RAID1, RAID 5 nebo RAID 6. Na nějakém fosilním nesmyslu, který je údajně jasně definovaný, přesně totéž selhání jednoho disku pošle do kytek všechna data. Už se to tady řešilo asi tak stokrát. Už je ten anti-Btrfs FUD fakt únavný.
Nechceš používat rozumný filesystém? Nemáš rád svá data? Dobře! Ale proč si to nenecháš pro sebe? Proč se tím chceš chlubit?
Zatímco Btrfs a ZFS opravdu garantují redundanci, AID bez R (tedy jakýkoliv údajný RAID před ZFS a Btrfs) nikdy nic negarantoval a naivně spoléhal na funkce (modelově dokonalých) disků, které zmizely v době, kdy se kapacita přehoupla přes 100 GB nebo tak. Jinými slovy, de facto negarantoval nic, zatímco de reklamí žvásty garantoval modré z nebe.
Ty jsi ale trouba k pohledání!
Kde přesně RAID1 něco říká?
Kde přesně RAID1 říká, že na všech discích jsou stejná data?
Ale hovno. Nikdy na všech discích nejsou stejná data. Už proto, že tam vždy musí být metadata, ať už jde o AID bez R nebo skutečný RAID, a ta metadata musí obsahovat nějakou unikátní (unikátní — chápeš, co to znamená, jo?) identifikaci každého disku.
Ach jo. Anti-Btrfs FUDisté a jiní mamlasové jsou únavní a otravní. Už to fakt stačí. Nemáme rok 2010.