Portál AbcLinuxu, 30. dubna 2025 10:12
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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.