Společnost Cloudflare představila Cloudflare OS (GitHub), tj. open source platformu navrženou pro integraci umělé inteligence (agentů) přímo do pracovních procesů organizací.
Byla vydána nová verze 5.13 svobodného multiplatformního softwaru pro konverzi a zpracování digitálních fotografií primárně ve formátů RAW RawTherapee (Wikipedie). Vedle zdrojových kódů je k dispozici také balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
Jean-Baptiste Kempf na svém blogu představil novou verzi 9.0 "Lei" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie).
Richard Hughes oznámil, že službu Linux Vendor Firmware Service (LVFS) umožňující aktualizovat firmware zařízení na počítačích s Linuxem, nově sponzoruje také společnost NVIDIA.
Edvard Rejthar na blogu zaměstnanců CZ.NIC představil svou aplikaci SlideRshow (GitHub). Funguje jako prohlížeč fotek, ale i jako jejich organizér a prezentátor. Neinstaluje se, běží přímo v prohlížeči. Bez serveru. Offline.
Kermit, tj. protokol pro přenos souborů, vznikl před 45 lety. Při této příležitosti byla po 15 letech od vydání poslední stabilní verze 9.0.302 vydána nová stabilní verze 11 implementace C-Kermit. S podporou IPv6.
První verze konverzního nástroje Pandoc byla vydána před 20 lety. Jeho autor John MacFarlane při tomto výročí rekapituluje jednotlivé etapy vývoje a přidávání nových funkcí – rozšíření nejen Markdownu a podporu mnoha dalších formátů.
Srpen přinesl nejen další spalující vedro, ale také Virtuální Bastlírnu s neméně žhavými novinkami. Využijte tedy předpovědi na deštivý čtvrteční večer a od 20:00 se připojte online k tomuto neformálnímu setkání kutilů, techniků a vědců, kde se strahovskými bastlíři proberete nejzajímavější věci, na které jste narazili za poslední měsíc. Pokud jde o novinky, řeč zcela jistě přijde na systém INDX pro tiskárny Průša, který na konci
… více »Firma T-Mobile blokovala „dezinformační web“ AC24 bez toho, aniž by k tomu měla závazný pokyn orgánů veřejné moci. Píše to ve svém rozsudku Městský soud v Praze, který po čtyřech letech uzavřel kauzu blokace zmíněného webu. Operátor musí uhradit škodu ve výši 35 tisíc korun. Advokát společnosti T-Mobile se snažil i u odvolacího senátu argumentovat tím, že firma jednala v dobré víře, když na stránky omezila přístup poté, co ji k tomu vyzvalo
… více »Padla obžaloba v bitcoinové kauze. Státní zástupkyně chce pro Blažka 6,5 roku vězení, pro Titze 8 let.
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
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz3 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.
Tiskni
Sdílej:
