OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
mkfs.btrfs -m raid1c4 -d raid6
Stačí -m raid1c3 -d raid6
.
Po tomhle čtení bych se vyhnul RAID modům BTRFS na sto honů.
Nějak špatně čteš. Pokud by ses chtěl vyhýbat Btrfs RAIDu na sto honů, musel by ses pak vyhýbat taky všem ostatním (R)AIDům asi tak na tisíc honů (ať už to s honěním souvisí jakkoliv):
"…btrfs raid5 is quantitatively more robust against data corruption than ext4+mdadm (which cannot self-repair corruption at all)…"
Drobné shrnutí faktů:
mdadm
/ dmraid
.Otázka je vždy stejná: S čím srovnáváme? Samozřejmě, že Btrfs má nedostatky. Jak závažné? Ve srovnání s čím? Který obdobný software nemá nedostatky?
(Já osobně mám Btrfs s -d raid5 -m raid5
už cca 5 let, disky jsem v tom měnil, žádný problém se nikdy nekonal. Jistě to není dokonalé, ale je to pořád lepší než mdadm
/ dmraid
.)
Takže napsat si vlastní okopávače, abych ráno nečuměl jak puk na rozpadlé pole.
Vypadá to, že máš požadavky mimo realitu, špatnou představu o rizicích a jejich vzájemném porovnání, nebo možná obojí. Čumění na rozpadlé pole čeká s mnohem větší pravděpodobností toho, kdo nepoužije Btrfs.
RAID 5 and 6 have "lots of edge cases", though, and have been famously unreliable.
A věříš vůbec na silent data corruption?
Já například nevěřím na autonehody. Nikdy se mi totiž žádná nestala. Autonehody proto neexistují.
Tohle^^^ zní úplně stejně hloupě jako následující:
A věříš vůbec na silent data corruption?
Nevím, jak předřečník, ale já v silent data corruption rozhodně nevěřím — ani trochu. Věřit se totiž dá jedině v to, co je neověřitelné.
Silent data corruption je ovšem ověřitelný, nesčetněkrát pozorovaný, statistikou "modelovatelný" a fyzikou vysvětlitelný jev. Není to nic, v co by se dalo (ne)věřit.
No já si teď brzy budu kupovat novou sestavu a s ohledem na silent data corruption do ní chci pořídit paměti s ECC. A časem chci přejít na Btrfs. Z počátku budu ale muset zůstat na ext4, protože Btrfs asi nestihnu nastudovat a vyzkoušet. Mám teď v plánu dát Mint na volný HDD s Btrfs a hrát si s tím a simulovat různé problémy, abych pochopil co a jak. Až pochopím, tak na Btrfs konečně přejdu. A právě kvůli silent data corruption. Takže pak budu s tebou, Alešem, Heronem a lertimirem tento fs bránit proti zbytku světa.
RAID používat nebudu. Alespoň zatím ne, ale možná časem změním názor. Po instalaci OS a jeho nakonfigurování udělám jeho snapshot a pro jistotu jej zazálohuji Clonezillou. Data (datový oddíl) budu denně syncovat a jednou za čas udělám zálohu dat. Časem možná zjistím, že RAID by byl lepší a pak se podle toho zařídím. Zatím s ním ale nemám vůbec žádné zkušenosti a ani plně nedokážu posoudit, jestli jej potřebuji, nebo ne.
Pokiaľ sa ti v priebehu mesiaca pokazia dáta, tak si zlou verziou môžeš zlikvidovať korektné dáta pri ich synchronizovaní. Pozor na to.
Tím myslíš silent data corruption, nebo chybu uživatele?
Co se týká silent data corruption, tak v budoucnu to budu mít pořešeno díky RAM s ECC a Btrfs.
Co se týká té druhé varianty, tak zatím dobrý. V systému mám nastaveno, aby se při mazání souboru nepoužil koš a nemůžu si vybavit, kdy jsem toho litoval. Kdysi ano, ale už je to spoustu let nazpět. Takže při synchronizaci, nebo zálohováni ani neverzuji, ale zrcadlím a zatím OK.
Tak nahoře jsi mi napsal:
Pokiaľ sa ti v priebehu mesiaca pokazia dáta, tak si zlou verziou môžeš zlikvidovať korektné dáta pri ich synchronizovaní. Pozor na to.
Takže co můžu dělat pro ochranu svých dat ve vztahu k aurora borealis, nebo chybě na disku, kterou fw nereportuje? Jak můžu tedy dávat "pozor"?
Zatím mi jde pouze o úřední dokumenty.
Napsal jsem to nepřesně. Mám to teď takto:
V pc mám datový oddíl, který syncuji na NAS (RPi+HDD). Používám k tomu program FreeFileSync. V něm lze nastavit 4 druhy synchronizace:
Rozpoznat a provést změny na obou stranách
Odstraněné, přesunuté, nebo přejmenované soubory a
konflikty budou detekovány automaticky pomocí databáze.
Vytvořit zrcadlovou kopii levé složky tak, aby po
synchronizaci pravá složka přesně odpovídala levé.
Kopírovat nové a aktualizované soubory do pravé složky.
Nastavení vlastních pravidel synchronizace.
Já tedy používám typ "Databáze". Když na datovém oddílu v pc něco přibude, tak ten den večer spustím sync. Když něco smažu/změním, tak se na NASu daný soubor po synchronizaci přemístí do koše. Jednou za čas, když zapnu nb, spustím sync i tam. Pokud na datovém oddílu v nb přibude soubor, nebo pokud něco změním, tak před vypnutím nb provedu sync. Výsledkem tedy je, že mám naprosto stejná data mezi pc, NAS a nb.
Dále mám ext. HDD, který mám rozdělen na 2 oddíly. Na prvním nešifrovaném mám zálohy šifrovaných operačních systémů (pc, nb a flash). Na druhém, šifrovaném oddílu mám zálohu dat, kterou pořizuji tak jednou za 2-3 měsíce. Před tím tu předešlou smažu.
V pc mám ještě další HDD, který je celý šifrován a na něm je vždy aktuální obsah toho externího HDD. Tento HDD zapínám pouze pro zálohování.
Nejsem tedy chráněn např. proti požáru. To ještě budu muset pořešit. Ale proti selhání hw bych řekl, že ano. Takto mi to zatím stačí. Jak jsem psal, už roky jsem nelitoval, že bych něco smazal a pak to potřeboval. Vlastně důležité dokumenty z úřadů vůbec nemažu. Ty jen přibývají, takže tady chybu udělat nejde. Člověk se sice může umáznout, ale pak to není problém okamžitě obnovit. Situace by byla jiná, kdybych např. programoval a pracoval na nějakém projektu. Tam by se hodilo mít každodenní stav toho projektu zazálohován. Člověk něco smaže, po čase zjistí, že to bylo správně a při mém současném způsobu zálohování a syncování by to mohl psát znovu. Ale to zatím není můj případ, takže jsem v klidu. Ten čas ale možná nastane a pak se zařídím úplně jinak.
Časem možná zjistím, že RAID by byl lepšíLepší vůči čemu? Vůči tomuto?:
Data (datový oddíl) budu denně syncovat a jednou za čas udělám zálohu dat.To je úplná blbost. RAID a záloha jsou kompletně oddělené věci a jedna nenahrazuje druhou. Tj RAID není ani lepší, ani horší, protože toto nesnese srovnání. RAID může být používán ke spoustě účelům, někdo preferuje nepřerušený běh služby, někdo jiný rychlost, někdo velikost v případě paritních raidů. Ale zálohy jsou stále nutné, tak jako byly vždy. Největší podíl na vytažení záloh je chyba uživatele. To RAID fakt nezachrání. Toto ve skutečnosti pomáhají řešit moderní FS jako je BTRFS, lze dělat snapshoty tak často, jak je to potřeba a uživatel si může sám listovat časovými snapshoty a najít si smazaný / přepsaný soubor. Ale ani toto nijak nenahrazuje řádnou zálohu.
Spíše vůči tomuto:
Po instalaci OS a jeho nakonfigurování udělám jeho snapshot a pro jistotu jej zazálohuji Clonezillou.
Já dělám zálohy OS Clonezillou jen po upgradu systému. Takže např. po upgradu z Mint 20 na Mint 20.1. Člověk udělá zálohu a pak toho v OS spoustu změní. Když by těsně před vydáním Mint 20.2 odešel HDD, tak bych sice mohl na nový HDD obnovit tu zálohu, ale musel bych toho spoustu dolaďovat. U RAIDu by to mohlo odpadnout. IMHO. Moc o tom nevím.
Jinak právě jsem si uvědomil, že bude dobré zálohovat OS i těsně před tím upgradem. Až budu používat Btrfs, tak snapshoty budou docela komfort.
týdně kontrolované AIDE
Iluze jistoty je horší než absence jistoty.
Jak je userspace chráněný před čtením poškozeného souboru, který se poškodí mezi týdenní kontrolou a následným čtením? (No jasně. Nijak.)
Jak je vyřešená ochrana dat po zápisu do souborů, mezi změnou a následným týdenním checksumováním? (Checksum se udělá z toho, co tam za týden je…? Aha. No jo.)
Zkrátka, když podivné, víceméně custom řešení dělá něco, co má správně dělat filesystém v kernelu, je to celkově na houby.
A za těch 15 let ani jedno data corruption, asi zázrak.
Pravděpodobnost a statistika 101: Kdyby se něco významného dělo v něčem tak titěrném jako 40 TB, byl by stav hardwaru nejspíš velmi špatný.
/dev
, funkčně je to ± totožné s LVM), pohodlné nastavení komprese, spolehlivý RAID (btrfs v jeho RAID1 mě celkem potrápil), spare disky, …
ZFS tedy funguje jako kombinace LVM s dm-crypt a btrfs. Uvnitř je to asi trochu složitější řešení, ale správa je snazší a, podle mých současných zkušeností, se zdá být spolehlivější.
Oproti tomu ZFS má také svoje mouchy – paměť použitá jeho cache se tváří jako použitá, což by na souborovém serveru nemělo vadit. Trochu větší problém je nemožnost zmenšit oddíl se ZFS.
Tiskni
Sdílej: