Dotaz: Odroid. HC2 + ext4, nebo BTRFS?

[kol-ouch]

Ahoj,

Děda jde do světa, doma je nový Odroid HC2 + WD RED 4TB. Samozřejmě jsem narazil na stejný problém jako tady, ale třeba se to vyřeší - v současné době jsem r/w přes sambu na 40MB/s, což je dvakrát víc než u dědy, tak mám prostor na pokusy. Mám v plánu zkusit arch for arm, ubuntu

Chtěl bych se zeptat - na disku uvnitř je letitý ext4 - má cenu ho měnit na BTRFS? Hlavní důvod výměny je možnost využít BTRFS send/receive pro zálohy, nebo má cenu tam vytvářet nějaký mdadm?

Ps. Přes NFS jsem na rychlostech 85/100 MB/s (trochu zvláštní mi přijde, že čtení je pomalejší než zápis), rychlost přes iperf je 933mib/s, rychlost disku uvnitř teď nedám, ale bylo to zdaleka dostačující pro plnění gigabitové sítě

---

---

Odpovědi

[bigBRAMBOR]

minule stoleti, 21. stoleti, AID 3...2...1....start

[kol-ouch]

?

[k3dAR]

myslim ze pripravoval vlakno na prichod Andreje

[kol-ouch]

Aha :)

[Petr Fiedler]

[Andrej]

Tj. všechno podstatné se mi už podařilo vysvětlit. ✓

[Petr Šobáň]

Osobně bych tam nechal ten ext4 obzvláště jak je tam jeden HDD. (nechtělo by se mi to předělávat 4TB je dost i když není plný)

[kol-ouch]

Ok, plný je dost, ale pokud by to mohlo přinést nějaké zlepšení, tak bych do toho šel.

[kol-ouch]

Tak nic, pod archem to samy...

[Josef Kufner]

BTRFS na jednom disku je takové křehké. Když se něco podělá, tak se neumí opravit. V tom je EXT4 mnohem lepší. Sice nemáš checksumy dat a hrozí tedy silent data corruption, ale zas se to celé nepodělá kvůli každému škytnutí disku či kabelu. Přijdeš o nějaký ten soubor, ale zbytek přežije

Doporučil bych dát BTRFS alespoň na dva disky do RAID1, aby BTRFS zvládlo opravovat chyby. Třetí disk by pro důležitá data také mohl dávat smysl, ale s tím zkušenost nemám.

Co jsem koukal na statistiky spolehlivosti disků, nejlíp vycházejí 8TB modely. Dokonce líp než 4TB modely.

[Andrej]

BTRFS na jednom disku je takové křehké. Když se něco podělá, tak se neumí opravit.

Naprostý nesmysl, velké-N-krát vyvrácený.

V tom je EXT4 mnohem lepší

Kolosální nesmysl. Nebo vtip? Nebo flamebait pro pobavení?

Přijdeš o nějaký ten soubor, ale zbytek přežije

Tady^^^ je ale najednou řeč o Btrfs, nikoliv o Ext4, že? Trochu nekonzistentní písemný projev, tak celkově.

Doporučil bych dát BTRFS alespoň na dva disky do RAID1, aby BTRFS zvládlo opravovat chyby.

Jako by snad Btrfs neuměl duplikaci v rámci jednoho disku. (Na kterou se Ext4 nezmůže, zatímco u Btrfs je něco takového samozřejmost.)

Třetí disk by pro důležitá data také mohl dávat smysl, ale s tím zkušenost nemám.

Jako ostatně s Btrfs obecně, zdá se. Takže: Proč si neušetřit pár zbytečných FUDů?

[Josef Kufner]

Ne, není to nekonzistentní (a řeč byla opravdu o EXT4).

Právě ta absence několika kontrolních mechanismů, které má BTRFS navíc, je důvod, proč EXT4 vydrží víc. U EXT4 se prostě počítá s tím, že tam můžou být chyby a má nástroje na opravu. Když se kousek poškodí, tak zbytek filesystému zůstane funkční a fsck to při troše štěstí opraví (ve smyslu, že uvede filesystém do konzistentního stavu, nikoliv že zachrání data). A když se oprava nedaří, tak to jde připojit read-only.

U BTRFS je situace jiná. Tam se nepočítá s výskytem chyb. Předpokládá se, že je vše v pořádku a kontroluje se, že to tak opravdu je. Jenže pak něco v pořádku není a pokud není k dispozici kopie (např. díky duplikaci na druhý disk), tak filesystém jen suše oznámí, že je rozbitý a máš smůlu. Jednou ti umožní read-only mount a pak ani to ne. Nástroje na opravu prakticky žádné, ty co existují to spíš ještě dorazí. Jediná šance je vykopírovat data na jiný disk a vyrobit filesystém znovu. Pokud je to například zálohovací disk s hromadou snapshotů, tak je o zábavu postaráno (vlastní zkušenost).

Jasně, poškození dat na disku je chyba disku, nikoliv filesystému, ale filesystém je to, co se s tím musí umět vyrovnat. Například to, že poškozený disk lze v read-only režimu připojit jen jednou je jednoznačně blbost vývojářů – když to jde přečíst jednou, musí to jít i podruhé. Je to právě přístup k zotavení po chybách co dělá BTRFS tak špatnou pověst (a oprávněně).

[Andrej]

Ne, není to nekonzistentní (a řeč byla opravdu o EXT4).

Je to nekonzistentní. Přesněji řečeno, vyplývá to z naprostého nepochopení Btrfs, ZFS a filesystémů hodných 21. století obecně.

Právě ta absence několika kontrolních mechanismů, které má BTRFS navíc, je důvod, proč EXT4 vydrží víc.

Prdlajs. (Sorry jako, tohle je asi jako věřit v hovnomeopatii nebo v duhového jednorožce.)

U EXT4 se prostě počítá s tím, že tam můžou být chyby a má nástroje na opravu

Nemá. Bez checksumů metadat i dat nejsou žádné nástroje na opravu. Data jsou prostě náhodně posraná. Jinými slovy, Ext4 nebrat.

Když se kousek poškodí, tak zbytek filesystému zůstane funkční a fsck to při troše štěstí opraví (ve smyslu, že uvede filesystém do konzistentního stavu, nikoliv že zachrání data). A když se oprava nedaří, tak to jde připojit read-only.

A zase omylem mluvíš o Btrfs, nikoliv o Ext4. Tuhle výhodu má Btrfs, zatímco Ext4 ji nemá.

U BTRFS je situace jiná. Tam se nepočítá s výskytem chyb.

Podle mě jenom trolluješ. A v tom případě je to jistě skvělá zábava. Nebo jsi prospal celé desetiletí a za celé desetiletí sis nepřečetl nic o Btrfs? Těžko říct.

Jenže pak něco v pořádku není a pokud není k dispozici kopie (např. díky duplikaci na druhý disk), tak filesystém jen suše oznámí, že je rozbitý a máš smůlu.

Naprostý nesmysl. Nebo trolling. Nebo obojí.

Nástroje na opravu prakticky žádné, ty co existují to spíš ještě dorazí.

Odkaz na seznam nástrojů jsem už uváděl. Proč znova opakovat na hlavu postavený a vyvrácený pseudoargument?

Jediná šance je vykopírovat data na jiný disk a vyrobit filesystém znovu.

Prdlajs. Je rok 2020, ne 2010, víme?

Pokud je to například zálohovací disk s hromadou snapshotů, tak je o zábavu postaráno (vlastní zkušenost).

Jasně, teď přijdou anekdoty z doby před 10 lety. Super. Bezva. Byla to opravdu zkušenost, nebo jenom neochota číst manuálové stránky? Nebo hodně nespolehlivý hardware, na kterém by Ext4 kleknul a nevrátil ani byte, zatímco Btrfs v read-only režimu spoustu dat zachránil? Jak to vlastně bylo?

Jasně, poškození dat na disku je chyba disku, nikoliv filesystému, ale filesystém je to, co se s tím musí umět vyrovnat. Například to, že poškozený disk lze v read-only režimu připojit jen jednou je jednoznačně blbost vývojářů – když to jde přečíst jednou, musí to jít i podruhé. Je to právě přístup k zotavení po chybách co dělá BTRFS tak špatnou pověst (a oprávněně).

Btrfs nemá špatnou pověst. Jenom je kolem něj špatný hloupý FUD. Objektivní pověst má skvělou. A spoustu úspěchů v produkčních nasazeních typu Facebook.

Btrfs se umí s částečným i úplným selháním disku / disků vyrovnat, přesně podle stanovené redundance. Ext4 to neumí. Bavíme se tady o realitě nebo jenom o FUD povídačkách?

[kol-ouch]

Ja už jednu havárii na disku s btrfs zažil a do teď nevím čím to bylo - mám podezření na btrfs convert - fs byl dělaný právě z ext4 přes ten convert a po čase (dlouhém - byly to snad 2 roky) se disk ráno nepřipojil. Nakonec se mi ho podařilo připojit readonly a data přečíst. Od té doby se mi moc nechce mít všechny disky s jedním fs. Ale líbí se mi pár věcí co btrfs má, tak nevím jestli to risknout, nebo ne.

Ps samba se teď rozjela na 60/60 - to je taky případ sám pro sebe :)

[Heron]

Od té doby se mi moc nechce mít všechny disky s jedním fs.

To je rozumné opatření. Zejména na zálohy používám vždy jiný FS, než na původním úložišti. (Na Linuxu XFS, na FreeBSD UFS.)

[kol-ouch]

Jakou má XFS proti ext4 při použití na jednodiskovém domácím nasu výhodu? Nechce se mi moc laborovat s přesouvání 3TB dat abych pak zjistil, že to bylo zbytečně - co jsem četl, tak ext4 by mi mělo stačit s rezervou

Dík moc

[kol-ouch]

Ano, ext4 vám bude stačit. Já preferuju xfs dlouhodobě pro velké soubory, od roku 2012 to dostalo pořádnou dávku optimalizací i pro malé a metadata. Ale to ext4 taky. Takže rozhodně nemusíte měnit ext4 za xfs, nic podstatného vám to nepřinese.

[Andrej]

To já mám stále ještě pár záloh (velmi malých a velmi důležitých) na ZFS (na Linuxu; OpenIndianu už nemám). U XFS (nebo UFS) by to bohužel vedlo zpátky k nejistotě, kdy nevím, zda ty zálohy ve skutečnosti mám nebo ne , pročež těmto historickým FS vůbec nevěnuji čas.

Čistě teoreticky by asi bylo nejlepší mít ty ZFS zálohy navíc na úplně jiném kernelu, třeba FreeBSD, protože asi tak jediný důvod pro zálohy na jiném filesystému (a voser s nimi spojený) je onen doomsday scénář, kdy zásadní bug bude chvíli sedět v kernelu / VFS, sežere data a přijde se na něj až se zpožděním. (No … i když … Ext4 by mohl vyprávět.) V takovém případě pomůže mít zálohy co nejvíc oddělené, pokud jde o použitý software.

(A pak je otázka, jestli není lepší si ultradůležitá (a obvykle malá) data zašifrovat a nahrát do cloudu, jehož redundanci (geografické i všemožné jiné) se uživatel-jednotlivec nemůže rovnat.)

[Heron]

U XFS (nebo UFS) by to bohužel vedlo zpátky k nejistotě, kdy nevím, zda ty zálohy ve skutečnosti mám nebo ne

On někdo zakázal dělat sha512 sumy těch archivů? V případě trochu větší paranoie to lze okořenit Reed-Solomonem.

[Peter Golis]

Keby človek potreboval redundanciu pri archivácii digitálnych dát, tak ich umiestni v minimálne dvoch geografických lokáciách. Alebo aspoň použije archívny formát ktorý pracuje s paritou (rar, par, ...).

[Andrej]

Proč bych dělal manuálně nějaké checksumy? Sloužím já souborovému systému nebo souborový systém mně?

Ano, samoopravné kódy (místo pouhého checksumu) je feature, která pořád ještě trochu chybí. (Na rotačních discích se dá rádoby-nahradit duplikací dat i metadat v rámci jednoho disku. Na SSD duplikace nemá smysl (kvůli vestavěné deduplikaci některých (většiny?) řadičů) a bývá implicitně vypnutá i u metadat.)

[Heron]

Proč bych dělal manuálně nějaké checksumy? Sloužím já souborovému systému nebo souborový systém mně?

Tohle není o souborovém systému. Ve skutečnosti jsem chtěl napsat rovnou digitální podpis, ale to už by bylo dost OT v rámci tohoto dotazu. V kontextu tohoto vlákna se jedná o zálohy a u těch chceš mít jistotu, že jsou v pořádku a že s nimi nikdo nemanipuloval. "Manuální" checksum se hodí i pro přenos po síti apod.

[Andrej]

Dobrá, ale to bych ten checksum musel mít uložený (velmi) striktně odděleně od těch záloh atd. (aby nikdo nemanipuloval zároveň s ním). Což už je vskutku daleko off-topic.

Většinou když si něco zálohuju do cloudu, moje nastavení gpg rozumné ověření autenticity zahrnuje.

[Andrej]

Já osobně nemůžu convert doporučit, protože ho nemám dobře vyzkoušený na svých vlastních strojích, natož v nějakém větším nasazení.

Někteří ho chválí, jiní naopak říkají, že jim sežral svačinu.

Moje hypotéza je, že pravda bude uprostřed a negativní ohlasy můžou pocházet například z rozbitých Ext4. Jestliže konvertovaný Ext4 (kvůli svým nedostatkům v konzistentnosti dat) byl už v době konverze v nepříliš přesně definovaném stavu, mohlo se následně stát cokoliv. Taková už jsou rizika filesystémů bez checksumů / redundance / copy-on-write.

Tohle^^^ je hlavní důvod, proč bych se já osobně convertu vyhnul — nikdy nemůžu vědět, co přesně konvertuju.

Přijde mi nejlepší vytvořit Btrfs normálně pomocí mkfs.btrfs, podívat se, co zajímavého nového dnes umí (například --csum xxhash), a začít zkrátka od začátku.

[k3dAR]

ja osobne muzu convert nedoporucit, protoze pred casem pri jeho pouziti, se mi btrfs (muj pokus o btrfs c.1) rozsypalo behem par dni (puvodni ext4 byl ok, disk byl ok, po preformatovani zpatky na ext4 bylo ok)..., na druhou stranu se mi podivne zachovalo nedavno i btrfs (muj pokus o btrfs c.2) ktere bylo delane na cisto pres mkfs.btrfs, behem par hodin... udelal sem par subvolumes, nahral tam data, pak prejmenoval subvolumes(pokud se to delat nema, tak mi to nemelo dovolit a nasledne se chvili zobrazil obsah, pak ne, pak chvili jo, po odpojeni subvolumes uz to neslo pripojit, ale aspon to slo opravit, nicmene pokus sem radeji zastavil

[kol-ouch]

To je divné - subvolume normálně přejmenovávám

S tím convertovaným btrfs to bylo celkem zajímavý

[k3dAR]

jeste me napadlo, ze sem delal rsync (... --sparse --links --hard-links) a ted nevim zda primo do "dir" subvolumes, nebo do mountpointu nanej...

[Heron]

Subvolumes si můžeš přejmenovávat jak chceš.

po odpojeni subvolumes

Tím je míněno co?

[k3dAR]

mel sem ve fstab:

UUID="...."     /data.hddB/Dokumenty    btrfs   defaults,subvol=.subvolumes/Dokumenty           0       0

nebo rucne:

mount /dev/sdb1 /data.hddB/Dokumenty -o subvol=.subvolumes/Dokumenty

kdyz se to chovao jak sem popisoval, dal sem umount mountpointu a naslednej mount se tvaril ze zadnej error (ani s -v ani v dmesg nic) ale mounpoint byl prazdnej, pomohlo:

btrfs check --repair -p  /dev/sdb1

jeste me napadlo, neprejmenovaval sem subvolube (v prikladu. Dokumenty) ale nadrazenej adresar (v prikladu .subvolumes)

[trekker.dk]

Data jsou prostě náhodně posraná. Jinými slovy, Ext4 nebrat.

Pořád čekám, až se s tím setkám, ale zatím furt nic...

Objektivní pověst má skvělou.

"Objektivní pověst" je zajímavý termín pro váš názor.

[Andrej]

Data jsou prostě náhodně posraná. Jinými slovy, Ext4 nebrat.

Pořád čekám, až se s tím setkám, ale zatím furt nic...

To je ale zářivá logika, tohleto! Musel jsi nad tím dlouho přemýšlet?

Já si zase myslím, podle stejné logiky, že neexistují autonehody. Nikdy jsem totiž nebyl účastníkem žádné nehody. Pořád čekám, až se s nějakou nehodou setkám, ale zatím furt nic…

Takže nebudu používat bezpečnostní pás, airbagy si klidně nechám vymontovat — k čemu to všechno s sebou vozit — a ještě si nechám odlehčit auto o všechny ty zbytečné těžké výztuže ve dveřích a ve střeše.

[trekker.dk]

Já si zase myslím, podle stejné logiky, že neexistují autonehody. Nikdy jsem totiž nebyl účastníkem žádné nehody.

No, moc vám ta stejná logika nejde. "Setkal jsem se s dopravní nehodou" jaksi zahrnuje víc případů, než "byl jsem účastníkem dopravní nehody"

[Andrej]

Rozdíl je v tomto případě nepodstatný a nemění pointu, takže si myslím, že mi to celkem jde.

Pravdou je, že se ta analogie dá rozšířit ve smyslu "setkání" místo přímé "účasti": Ano, viděl jsem už párkrát nabouraná auta, ale nikdy jsem neviděl, že by se nehoda stala. (Ano, viděl jsem už párkrát poškozená data, ale nikdy jsem neviděl, jak a kdy přesně se to stalo.) Tudíž budu předpokládat, že ta nabouraná auta nejsou výsledkem nehod, nýbrž že se jenom tak někde objevují, sama od sebe, stejně jako poškozená data nejsou výsledkem silent data corruption, nýbrž se jenom tak sama od sebe někde objevují. Celkem analogicky potom silent data corruption neexistuje (stejně jako neexistují autonehody) a je úplně v pohodě používat filesystém z doby 10-gigabytových disků v době 10-terabytových disků.

Level nesmyslnosti je tady^^^ (opět) minimálně 27. Podívám se do kalendáře, rok je větší než 2010, použiju ZFS nebo Btrfs. Hotovo.

[trekker.dk]

Ne, nejde vám to. Když vidíte auto nabourané nehodou, tak můžete usoudit, že se nehoda stala. Já ho taky viděl. Narozdíl od těch poškozených dat, které jsem na ext4 ještě neviděl. (Vámi vylhané případy, které tady demagogicky označujete jako závadu ext4, samozřejmě nepočítám.)

[Andrej]

Narozdíl od těch poškozených dat, které jsem na ext4 ještě neviděl.

Komu že to nejde? Nedostatek zkušeností (nebo nedostatek zkušeností s dostatečně velkými systémy a úložišti) rozhodně neznamená, že se něco neděje.

Ještě jinými slovy, abych objasnil, v čem přesně je tady chyba: Je rozdíl, když nabourané auto nikdy neviděl obyvatel moderní technické civilizace (čemuž bych se opravdu divil) a když nabourané auto nikdy neviděl příslušník nekontaktovaného pralesního kmene (což lze očekávat). V každém z obou případů má taková informace / zkušenost / absence zkušenosti jinou váhu, že?

[trekker.dk]

Tuším, že za ta léta to nedostatkem zkušeností nebude, zkuste najít nějaké jiné ad hominem

[Andrej]

Ad hominem? Jaký ad hominem?

Trochu mi tahle reakce připomíná rčení o potrefené huse.

Chtěl jsem všeho všudy říct, že moderní filesystémy nebyly vyvíjené jen tak zbytečně, s vidinou hypotetických a neexistujících selhání. Ta selhání hardware, o kterých je řeč, jsou velmi reálná a výrazně ovlivnila vývoj a návrh moderních filesystémů.

Že jeden konkrétní uživatel / administrátor / engineer / kdovíkdo nějaký problém ještě neviděl, to neznamená, že problém neexistuje.

Já jsem dokonce i velmi rád, že jsem ještě neviděl všechny možné problémy tohoto světa. (Ale nepředstavuji si na základě toho, že neexistují.)

[Heron]

Právě ta absence několika kontrolních mechanismů, které má BTRFS navíc, je důvod, proč EXT4 vydrží víc.

Spíše je to důvod pro silent data corruption.

U EXT4 se prostě počítá s tím, že tam můžou být chyby a má nástroje na opravu.

Jak se tam ty chyby dostanou? Vadou HW? V tom případě ti BTRFS alespoň oznámí, že nesedí checksum datového bloku a do kterého souboru se to trefilo. Ext4 ti neoznámí nic.

Jenže pak něco v pořádku není a pokud není k dispozici kopie (např. díky duplikaci na druhý disk), tak filesystém jen suše oznámí, že je rozbitý a máš smůlu.

To jednoduše není pravda. Resp. jak je rozbitý? Pokud se chyba disku trefí zrovna do systémových stromů, tak ty jsou by default duplikované. (Pokud se bavíme o jednom disku.) Tzn to přežije. Pokud se chyba trefí do datových bloků, tak ext4 je ani nezjistí (viz výše), btrfs alespoň oznámí chybu checksumu.

Jednou ti umožní read-only mount a pak ani to ne.

Nevím o čem mluvíš. Jednou jsem to tady testoval a umožňoval degradovaný multidevice btrfs připojit opakovaně a to dokonce jako rw. Max potom přišel s tím, že to bylo v nějaké konkrétní verzi.

Navíc je otázka, jak se to má vlastně správně chovat. S tím tady (podle mě správně) argumentovat Filip Jirsák. Pokud si FS nastavíme s redundancí alespoň dvě kopie (btrfs raid-1), tak se FS nemůže (bez dalších disků) tvářit, že je vše v pořádku a měl by vyžadovat zásah admina. Jestli to někdy v minulosti vyřešili tak, že to nejde připojit rw, nevím, ale tohle řešení není automaticky špatné. Admin je odpovědný za to, aby tam bylo dostatečné množství disků (nebo jiné nastavení) k udržení jím požadované redundance.

V minulosti jsem měl několik bezesných nocí třeba u mdadm, který umožňuje sestavení i provoz v degradovaném režimu a někteří lidé toho zneužívají k tomu, aby "ušetřili" za disky. Tj místo správného počtu hned na počátku se to různě flikuje. Ve skutečnosti i toto btrfs řeší velmi elegantně. Na počátku začneme třeba se třema diskama a potom jen přidáváme další. Bez nutnosti zdlouhavného resilveringu.

Jediná šance je vykopírovat data na jiný disk a vyrobit filesystém znovu.

Což je za mě ta nejlepší varianta u každého fs. Jestli někdo spoléhá na fs, který musel být opravován externími příkazy (a neporadil si s tím driver fs), tak good luck. Navíc btrfs má nástroj restore, kterým umožní přečíst i velmi poškozený fs. Tj takový, který by při jiných FS ani nešel namountovat a tedy by nešly vykopírovat soubory.

[Josef Kufner]

Existuje ještě jedna ošklivá chyba, která může nastat: vadný kabel nebo kontakt. Spočívá to v tom, že komunikace s diskem selhává a část dat se nezapíše. Pak se restartuje sběrnice a disk se zas chytne. BTRFS skončí na tom, že ve stromu má nedokončené transakce, nesedí mu trans ID a neví co s tím. EXT4 si projde žurnál a nějak to dá dohromady (vypadávaly mi disky na USB celkem běžně a v pohodě se to ustálo několik let).

Co se týče kontrolních součtů, ty dělá i disk sám o sobě, takže pokud něco přečte blbě, tak už disk detekuje chyby a vrátí chybu čtení namísto nesmyslů. Je lepší, když má filesystém další kontroly, ale není to o tom, že by se nekontrolovalo nic.

[Andrej]

EXT4 si projde žurnál a nějak to dá dohromady (vypadávaly mi disky na USB celkem běžně a v pohodě se to ustálo několik let).

Protože Ext4 přesně v té^^^ situaci ztrácí data! Z.t.r.á.c.í  d.a.t.a.! Už? Tohle přece nemůže soudný uživatel považovat za výhodu.

Ext4 nemá checksumy dat, nemá redundanci (ani na jednom disku, ani přes víc disků) a nemá atomický copy-on-write. Tudíž může sice několik let předstírat, že funguje, jen ta data už na něm v původní podobě nebudou. K čemu je to dobré?

Chci vědět, která data mám a která nemám. Nechci za těch několik let, které to "ustálo" (ehm, ve skutečnosti neustálo) zjistit, že už ta data ve skutečnosti nemám.

Btrfs je nutný právě proto, že se stále větší kapacitou, se stále rychlejšími sběrnicemi a se stále levnější výrobou existuje stále častěji silent data corruption a spousta možných selhání řadičů / kabelů / disků.

[kol-ouch]

Ok, tak co když nechci mít všechno na jednom fs (na kterém jsem už o data málem přišel)?

Výše doporučené XFS?

[kol-ouch]

Btrfs + ZFS je asi nejlepší možná kombinace v tomto ohledu, pokud člověk trvá na "diverzifikaci" filesystémů.

Oba mají všechny klíčové vlastnosti, tedy copy-on-write, redundanci, checksumy dat i metadat atd. ZFS má ještě pár hezkých vymožeností navíc, které Btrfs zatím nemá. (Například atomické snapshoty přes víc než jeden subvolume.)

XFS je filesystém z roku 1993 (open-source od roku 2001), takže jeho použití má zhruba stejné chronické problémy a nedostatky jako například Ext4. Většina filesystémů, které jsou dnes v kernelu (a že jich je!) bohužel pochází z dob, kdy disky měly 1 GB, nikoliv 10 TB, kdy prakticky neexistovala silent data corruption, kdy běžný desktop málokdy měl víc než jeden disk atd.

Obvykle pracuju s vonější definicí pojmu na jednom FS a důležitá (a poměrně malá) data z Btrfs RAIDu 5/6 zálohuju na Btrfs RAID 1 na jiném stroji (který možná někdy dostane upgrade na RAID1c3 nebo tak). Což proti některým čistě hypotetickým doomsday scénářům chrání a proti některým zase ne.

[trekker.dk]

Protože Ext4 přesně v té^^^ situaci ztrácí data

Omyl. Hardware ztrácí data

[Andrej]

Protože Ext4 přesně v té^^^ situaci ztrácí data

Omyl. Hardware ztrácí data

Ext4 má mylné předpoklady o hardware. Například vůbec nepočítá s tím, že by hardware mohl ztrácet data. Tudíž Ext4 ztrácí data.

(Nemluvě o těch karambolech, každé cca 3 roky opakovaných (2009, 2012, 2015, 2018), kdy Ext4 opravdu sám od sebe ztrácel data kvůli bugům. Ale dobrá, ty nechme tentokrát stranou.)

[pavele]

Ještě pořád platí, že pro RAID1 s btrfs jsou potřeba minimálně 3 disky, nebo už to opravili?

[pavele]

Myslel jsem todleto:

https://www.reddit.com/r/btrfs/comments/iktbkz/failed_raid1_array/

https://www.reddit.com/r/btrfs/comments/bf01br/is_the_bug_with_recovering_from_a_2disk_raid_1/

[Andrej]

Anekdoty z Redditu jsou vskutku velmi zábavné.

[Andrej]

Ještě pořád platí…

Nikdy neplatilo.

[Jendа]

False. Když byla data mirrorovaná přes dvě devices, tak takový FS šlo ještě před 2 lety namountovat read-write pouze jednou. Pak se nastavil flag a už to nešlo až do opětovného přidání nějakého (klidně jednogigového souboru na loopbacku!) druhého device nešlo.

[Andrej]

Takže se zase zbytečně bavíme o situaci po kritickém selhání redundance?

Potom, samozřejmě — což už jsme řešili a vyřešili jinde, že ano —, je prvním a v té chvíli jediným cílem obnovení redundance, nikoliv read/write přístup.

Hernajs, ať už dají všichni pokoj s mokrým snem o neredundantním read/write mountování něčeho. Kdo to chce? Snad jedině ten, kdo nemá rád svá data.

[Jendа]

Já. Já si RAID pořizuji mimo jiné proto, aby počítač fungoval i těch pár hodin/dní, mezi okamžikem, kdy se rozbil disk, a okamžikem, kdy přijde nový a vymění se. Navíc s tvým argumentem by počítač nefungoval ještě několik hodin po výměně, než dojede resilvering, a tedy než je obnovena původně nastavená redundance. Skutečně mají tvé počítače několikahodinový výpadek po každém umření disku?

[Andrej]

Těch pár hodin / dní to jistě funguje. Údajný problém byl až při následujícím mountu, že?

Nebyly náhodou všechny vřesky a stesky jenom kolem toho, že se to nedá (automaticky) namountovat degraded?

Neřešili jsme náhodou už asi tak velké-N-krát, že si můžeš degraded přidat do příkazové řádky kernelu, když takové (nesmyslné) chování chceš?

Sorry jako, ale tahle krátká paměť FUDistů je už fakt trapná záležitost.

[Jendа]

Nebyly náhodou všechny vřesky a stesky jenom kolem toho, že se to nedá (automaticky) namountovat degraded?

Nebyly.

[Andrej]

Aha. Najednou. Pak tedy byly všechny vřesky a stesky zbytečné a/nebo prostým výsledkem dvojího metru.

[Jendа]

Těch pár hodin / dní to jistě funguje.

Ale nemělo by!! Není tam nakonfigurovaná redundance!!111!1

[Andrej]

Zase jsi nepochopil psaný text.

Bavíme se o nějakém odletu na kernel panic, když selže 1. až (N - 1). disk z N při redundanci N (což by se rozhodně nemělo stát)? Nebo je řeč o tom, zda se má automaticky provést degraded mount (což by se také rozhodně nemělo stát)? To jsou dvě hodně odlišné otázky, že?

Nevím, jestli ještě vaříš z vody nebo už jen z nějakých minerálních reziduí.

Abych to řekl polopatě a po lopatě: Samozřejmě, že uptime má trvat tak dlouho, jak jen to jde, i po selhání (N - 1) disků z N. Mimo jiné od toho tam ten RAID je, ne? Následující mount je ovšem úplně jiná situace / otázka / kapitola / fáze provozu Matrixu.

[Heron]

přijde nový

Jak přijde? Spare je snad v bedně, další disk na poličce.

Skutečně mají tvé počítače několikahodinový výpadek po každém umření disku?

Ne, buď je tam klasický spare nebo v případě btrfs další disk a dostatek volného místa na FS. Tj po každém umření disku dojde pouze ke snížení dostupného místa na FS. (Uznávám, toto by chtělo vyšperkovat. Dneska je nutné odstranit missing device, mohlo by to fungoval automaticky.)

[trekker.dk]

My, co doma neskladujeme přebytečný disk, aby se tu dva roky válel, kdyby náhodou nějaký chcípl, máme dělat co? Nechat zapnutý počítač?

[Heron]

My, co doma neskladujeme přebytečný disk, aby se tu dva roky válel, kdyby náhodou nějaký chcípl, máme dělat co?

Pointa je v tom, že se nemusí válet. Viz poznámka o "aktivním" spare. Ostatně člověku, který používá ceph, to asi nemusím vysvětlovat.

[trekker.dk]

Pointa je v tom, že se nemusí válet. Viz poznámka o "aktivním" spare.

To by byla dobrá poznámka, kdyby se desktopové základní desky vyráběly s víc než 6 SATA porty

[Heron]

Copak desky, dá se použít přídavný HBA, ale skříně.

[trekker.dk]

dá se použít přídavný HBA

jo, dá se, jeden v rozumné cenové relaci (pro domácí použití nechci za HBA dát víc peněz než za board) jsem zkusil a po pár týdnech zase vyhodil

[trekker.dk]

Dle vaší logiky: "měl jsem btrfs, ale počítač shořel. Btrfs ztrácí data."

Chyba hardwaru je chyba hardwaru, ne software nad ním.

[Andrej]

Nepochopení mé logiky (nebo … zkrátka logiky?) vídám v souvislosti s Btrfs často.

Jistě, chyba hardware není totéž jako chyba software. (Tvrdil to tu snad někdo?) Předností software ovšem může být odolnost vůči (některým) chybám hardware a/nebo správná detekce chyb hardware a reakce na ně.

Když se budeme držet těch analogií s auty, nepřesných ale ilustrativních: Dejme tomu, že mě nabourá Trabant, bez mého zavinění. To odpovídá té chybě hardware, kterou nemůžu ovlivnit nebo předvídat. Budu mít nějakou výhodu, když budu v té chvíli sedět v Rolls-Royce? Nebo pro mě nehoda dopadne úplně stejně, když pojedu taky v Trabantu?

Řekl bych, že Rolls-Royce (Btrfs) bude mít své výhody.

[trekker.dk]

Ano, předností software může být odolnost vůči některým chybám hardware, ale to jste netvrdil. Tvrdil jste, že filesystém ztrácí data. Která ovšem ztratil ten hardware

[Andrej]

Každý filesystém, který počítá s hypotetickým ideálním hardwarem a žije v jakési bublině odtržené od reality, v podstatě ztrácí data.

Dá se kolem toho slovíčkařit praktiky libovolně, ale faktem je, že některý filesystém se do 21. století hodí a některý zas až tolik ne.

[trekker.dk]

To je vaše interpretace vytvořená na základě závěru, který chcete učinit, nikoliv objektivní zhodnocení.

[Andrej]

Zatímco FUDy o "stabilním" Ext4 a "nestabilním" Btrfs, kterými se to tady půlka vlákna (už zase) doslova hemží, jsou zářným příkladem objektivního hodnocení, že jo.

[trekker.dk]

Navíc ve zmiňovaném případě předřečník tvrdí, že Btrfs se s tou situací nevyrovnal, takže kde je tu Trabant...?

[Andrej]

S čím přesně předřečník srovnává? Který jiný filesystém by se s uvedenou situací vyrovnal?

Dvojí metr je opravdu ptákovina a ohraná písnička.

[trekker.dk]

S čím přesně předřečník srovnává? Který jiný filesystém by se s uvedenou situací vyrovnal?

Použijte své oblíbené vstupní zařízení, posuňte si stránku o něco výše a můžete si to přečíst sám.

Dvojí metr je opravdu ptákovina a ohraná písnička.

Tak toho nechte, když se vám to nelíbí

[Andrej]

Neodbíhejme od tématu: Který filesystém (by) příslušnou situaci ustál? Nějaký příklad takového filesystému? (Jak už jsem psal jinde: Nevidím řešení v tom, že filesystém nějaký problém dokáže ignorovat; to není žádná výhoda.)

Pokud tedy nemáme příklad toho bájného filesystému, který by se ve stejné situaci zachoval výrazně lépe, máme tu nejspíš opět dvojí metr + mlácení prázdné slámy, že ano.

[trekker.dk]

Neodbíhejme od tématu: Který filesystém (by) příslušnou situaci ustál?

Použijte své oblíbené vstupní zařízení, posuňte si stránku o něco výše a můžete si to přečíst sám.

[Andrej]

Nápodobně.

Ono to tam totiž není napsáno. Proč? Protože žádný filesystém (a rozhodně ne zmiňovaný Ext4) příslušnou situaci neustojí. Už to vysvětluju asi tak podesáté: Když se filesystém chová, jako by bylo všechno v pořádku, a přitom klidně vrací náhodně poškozená data, je to průser, nikoliv výhoda. Že nějaký filesystém (například Btrfs nebo ZFS) dokáže velmi brzy upozornit na selhávající hardware, to je obrovská výhoda, nikoliv problém.

Smutné je, že někteří tak jednoduchou úvahu dodnes nebyli schopní zpracovat. To musí být spousta kilometrů dlouhého vedení.

Nemá smysl lpět na hardwaru, který selhává a pravděpodobně patří do sběrného dvora. Prý Btrfs nefunguje. A to je zajímavé, že v obrovských produkčních nasazeních (statisíce strojů) typu Facebook nějakým zázrakem funguje.

Takže, bude jméno toho zázračného (a dosud nezmíněného, ba možná dosud neimplementovaného) filesystému? Zkusím hádat: Nebude.

[trekker.dk]

Ono to tam napsané je, jen si to musíte přečíst a vzít na vědomí. Bude potřeba neodfiltrovávat informace, které se vám nehodí do krámu.

[LarryL]

Taky tam vidím jen Ext4. Pokud myslíš jiný než Ext4, tak hoď link. Tahle diskuze je už dost velká a hrát hru na schovávanou s radami typu "odscroluj si a najdi si to" je fakt zbytečná.

[Andrej]

Není. (Jak už jsem opakovaně vysvětlil.)

Tohle jsou fakt kilometry dlouhého vedení; to se nevidí.

[ewew]

To by už stačilo. Jedine čo si dosiahol je neustále pridávanie príspevkov.

Osobne mi je to jedno, že chodíš neustále v kruhu.

[Andrej]

Osobne mi je to jedno, že chodíš neustále v kruhu.

Zase někdo vidí kruhy, kde nejsou? No jo, nějak se tu s takovými roztrhl pytel.

V kruhu se točí všeho všudy FUDisté se svými stokrát vyvrácenými nesmysly, které nedovedou nijak obhájit.

Důvod, proč je dobré tyhle kolosální kraviny vyvracet, nejsou FUDisté samotní — těm není pomoci —, nýbrž ostatní, pozdější čtenáři takového vlákna. Když bude každý dotaz o Btrfs zaplevelený hloupým FUDem, na který nikdo nebude reagovat, může to vytvořit mylný dojem, že stabilní a léty "produkčních" nasazení prověřený filesystém má jakési záhadné problémy, kterých by se měl uživatel bát.

Ve skutečnosti, jak už jsem psal, by se uživatelé dnes měli bát nepoužívat Btrfs, nikoliv používat Btrfs.

[billgates]

Nevysvětlil jste nic, jen jste se pokoušel zamlžit to, že asi neumíte číst. Nebo posouvat webovou stránku

[Andrej]

Tak ten název toho bájného filesystému bude?

A jejda! Nebude! A zase nebude. Zase jenom kecy v kleci.

Zoufalství FUDistů par excellence.

[trekker.dk]

No dokud si tu stránku neposunete, tak nebude.

[Andrej]

Takkže nebude. Protože ten hypotetický zázračný filesystém neexistuje.

Jaké to překvapení! FUDista žvaní kraviny a nedokáže ty kraviny ničím doložit. Standard, klasika.

[trekker.dk]

Nebude, protože zřejmě neumíte posunout stránku.

[Jendа]

Jak se tam ty chyby dostanou? Vadou HW?

Nebo SW (jo, chápu, že to je neuvěřitelné, ale prý existuje software, ve kterém jsou chyby :)

V tom případě ti BTRFS alespoň oznámí, že nesedí checksum datového bloku a do kterého souboru se to trefilo. Ext4 ti neoznámí nic.

To už tu píšu asi po sté: btrfs checksumy checksumují opravdu jen že to, co se přečetlo, je to, co se před tím zapsalo. Neřeší vůbec, jestli datové struktury stále dávají smysl! To řeší fsck, který byl před ~4 lety naprosto nepoužitelný. Doufejme, že to od té doby opravili.

Jednou jsem to tady testoval a umožňoval degradovaný multidevice btrfs připojit opakovaně a to dokonce jako rw. Max potom přišel s tím, že to bylo v nějaké konkrétní verzi.

Bylo to pro všechny verze od začátku do 4.něco a umožnilo to jednou rw a pak už pouze ro.

Pokud si FS nastavíme s redundancí alespoň dvě kopie (btrfs raid-1), tak se FS nemůže (bez dalších disků) tvářit, že je vše v pořádku a měl by vyžadovat zásah admina.

On se netváří, že je vše v pořádku, a zásah admina nepomůže, protože ten flag nebylo možno obejít (bez patchování kernelu). RAID si lidé typicky pořizují proto, aby systém fungoval i při selhání jednoho disku, což zde splněno nebylo.

[Andrej]

Jak se tam ty chyby dostanou? Vadou HW?

Nebo SW (jo, chápu, že to je neuvěřitelné, ale prý existuje software, ve kterém jsou chyby :)

No ovšemže. Například Ext4 vlivem bugů posral lidem data v roce 2009, 2012, 2015, 2018 [všechny incidenty snadno dohledatelné]… Takže co? Je v plánu i 2021? Jo, to bude zase párty, co?

To je ale divné, že Btrfs v tom Facebooku a všude možně jinde, kde běží, tyhle tříleté výroční kalby s šavlí poránu nepořádá. To je ale záhada!

V tom případě ti BTRFS alespoň oznámí, že nesedí checksum datového bloku a do kterého souboru se to trefilo. Ext4 ti neoznámí nic.

To už tu píšu asi po sté: btrfs checksumy checksumují opravdu jen že to, co se přečetlo, je to, co se před tím zapsalo. Neřeší vůbec, jestli datové struktury stále dávají smysl! To řeší fsck, který byl před ~4 lety naprosto nepoužitelný. Doufejme, že to od té doby opravili.

A ani posté jsi to nepochopil. Tak ještě po sté první: Checksumy nezaručují dokonalou konzistentnost dat. Proč? Protože mají kolize. Co přesně tedy dělají checksumy? Snižují pravděpodobnost nededetekovaného poškození dat o několik (řádově třeba 10 až 20, podle typu checksumu) desítkových řádů.

A teď mi objasni, jak by se (jinak než náhodnými a krajně nepravděpodobnými kolizemi checksumů) dosáhlo toho, aby datové struktury (nějak, záhadně, ba kouzelně) nedávaly smysl, ale těmi checksumy by pořád procházely. Takový zázrak! To bude asi nějaký průlom v kvantové fyzice, že? Ve kterém žurnálu je o tomhle článek?

Jednou jsem to tady testoval a umožňoval degradovaný multidevice btrfs připojit opakovaně a to dokonce jako rw. Max potom přišel s tím, že to bylo v nějaké konkrétní verzi.

Bylo to pro všechny verze od začátku do 4.něco a umožnilo to jednou rw a pak už pouze ro.

Úspěšný r/w mount má zaručovat redundanci, která je v konfiguraci daného filesystému určená. Cokoliv jiného má být nanejvýš r/o. Uživatelům AIDů bez R tohle sice dlouho nedocházelo, ale je dobře, že se konečně takové základy fungování světa a Matrixu dostávají do obecného povědomí.

RAID si lidé typicky pořizují proto, aby systém fungoval i při selhání jednoho disku, což zde splněno nebylo.

Naprostý nesmysl. RAID si lidé pořizují proto, aby selhání N - 1 disků (při redundanci N) nevedlo ke ztrátě dat. Takový předpoklad se zásadně liší od předpokladu (a leckdy je v rozporu s předpokladem), že RAID s N - 1 disky bude (v nějakém slova smyslu) fungovat.

[Jendа]

No ovšemže. Například Ext4 vlivem bugů posral lidem data v roce 2009, 2012, 2015, 2018 [všechny incidenty snadno dohledatelné]… Takže co? Je v plánu i 2021? Jo, to bude zase párty, co?

To je ale divné, že Btrfs v tom Facebooku a všude možně jinde, kde běží, tyhle tříleté výroční kalby s šavlí poránu nepořádá. To je ale záhada!

Prohlášení, že v btrfs mohou být chyby, neposkytuje žádnou informaci o tom, zda v ext4 nebo jakémkoli jiném software chyby nejsou.

A teď mi objasni, jak by se (jinak než náhodnými a krajně nepravděpodobnými kolizemi checksumů) dosáhlo toho, aby datové struktury (nějak, záhadně, ba kouzelně) nedávaly smysl, ale těmi checksumy by pořád procházely.

Například tak, že někdo v implementaci B-stromu udělá race condition. Ale možná jsme já a vývojáři filesystémů co nejsou btrfs nebo zfs opravdu jediní na světě, kdo dělá chyby při implementaci datových struktur. Nebo dojde k chybě v RAM nebo při výpočtu v procesoru (udávaná chybovost minimálně non-ECC RAM (příspěvek je o hardwaru bez ECC) je ještě děsivější než udávaná chybovost silent data corruption pevných disků).

[Andrej]

No ovšemže. Například Ext4 vlivem bugů posral lidem data v roce 2009, 2012, 2015, 2018 [všechny incidenty snadno dohledatelné]… Takže co? Je v plánu i 2021? Jo, to bude zase párty, co?

To je ale divné, že Btrfs v tom Facebooku a všude možně jinde, kde běží, tyhle tříleté výroční kalby s šavlí poránu nepořádá. To je ale záhada!

Prohlášení, že v btrfs mohou být chyby, neposkytuje žádnou informaci o tom, zda v ext4 nebo jakémkoli jiném software chyby nejsou.

Podstatný rozdíl je ovšem hlavně v tom, že některý software se dokáže lépe vypořádat s chybami hardwaru a jiný hůř. Některému software se čtyři kritické chyby se ztrátou dat během jediné dekády mlčky tolerují, zatímco u jiného se (nahlas) předpokládá dokonalost. Už mě unavuje připomínat, jak nesmyslný je celý tenhle dvojí metr.

A teď mi objasni, jak by se (jinak než náhodnými a krajně nepravděpodobnými kolizemi checksumů) dosáhlo toho, aby datové struktury (nějak, záhadně, ba kouzelně) nedávaly smysl, ale těmi checksumy by pořád procházely.

Například tak, že někdo v implementaci B-stromu udělá race condition. Ale možná jsme já a vývojáři filesystémů co nejsou btrfs nebo zfs opravdu jediní na světě, kdo dělá chyby při implementaci datových struktur. Nebo dojde k chybě v RAM nebo při výpočtu v procesoru (udávaná chybovost minimálně non-ECC RAM (příspěvek je o hardwaru bez ECC) je ještě děsivější než udávaná chybovost silent data corruption pevných disků).

Jaký je vliv té chybovosti na pravděpodobnost poškození dat? Jak dlouho se data zdrží v RAM a jak dlouho na disku? Mám takové tušení, že tam bude celkem zásadní rozdíl v době uložení dat a v době působení všech možných vlivů na ně. (Inu, na všechno, co mi spravuje úložiště, si kupuju zásadně ECC RAM. Ne že by mi někdy selhala RAM třeba v notebooku, který ECC nemá, ale je to jako s autonehodami: sice jsem nikdy autonehodu nezažil, no nicméně když už je k dispozici bezpečnostní pás, samozřejmě ho použiju.)

Je příjemné vědět, že Btrfs dokáže tu a tam odhalit dokonce i problémy s RAM bez ECC (byť zdaleka ne vždy).

[trekker.dk]

Například Ext4 vlivem bugů posral lidem data v roce 2009, 2012, 2015, 2018 [všechny incidenty snadno dohledatelné]

A pokud to jsou ty samé, co tvrdíte vždycky, tak to většinou nebyla chyba ext4.

Úspěšný r/w mount má zaručovat redundanci, která je v konfiguraci daného filesystému určená. Cokoliv jiného má být nanejvýš r/o.

To je pouze váš názor. Redundance ovšem znamená - vždycky to tak v případě RAIDů bylo - že daná věc bude schopna fungovat plnohodnotně ve smyslu poskytované služby, i po selhání nějaké své části.

Naprostý nesmysl. RAID si lidé pořizují proto, aby selhání N - 1 disků (při redundanci N) nevedlo ke ztrátě dat.

Mýlíte se. Já jsem si RAID pořídil z obou důvodů.

[Andrej]

Naprostý nesmysl. RAID si lidé pořizují proto, aby selhání N - 1 disků (při redundanci N) nevedlo ke ztrátě dat.

Mýlíte se. Já jsem si RAID pořídil z obou důvodů.

Opravdový RAID nebo AID? Iluze R může být nakonec horší problém než úplná absence R.

[...]

Smiř se s tím, že RAID je redundance disku, která dodává počítači blokové zařízení, zatímco BTRFS je souborový systém, který dodává počítači souborový systém.

BTRFS může fungovat nad větším počtem blokových zařízení, takže také může poskytovat redundanci, obdobně jako RAID. Ale prostě to není RAID v původním slova smyslu.

A k tomu, jestli je lepší jedno nebo druhé, se nevyjadřuji.

[Andrej]

Dobrá tedy. Pak nezbývá než říct, podle této logiky, že Btfs je jakási blíže neurčená (leč znamenitě fungující) redundance, zatímco RAID (v jakési přehnaně pedantsky přesné definici) ještě nikdy nikde na světě nebyl implementovaný (zatímco AID je, bohužel, na každém rohu).

[trekker.dk]

Hm, RAID už nějaký pátek používám, takže máte zjevně chybnou logiku.

[Andrej]

AID chybně označovaný za RAID jsem také nějaký pátek používal, když jsem ještě příliš nechápal, jak tenhle svět funguje. Jo, už je to přes 10 let od té doby; čas letí.

Ten pocit, když AID 6 zničí všechna data kvůli poškození dat na jednom disku — k nezaplacení! (Neměl náhodou ustát poškození dat na 2 discích? Měl, jenže resilvering bez checksumu je jako airbag bez pásu.)

[trekker.dk]

A pak jste si oblíbil nějaký filesystém, celý život se vám převrátil vzhůru nohama a ztratil jste písmenko. To naštěstí všechny nepotká.

[Andrej]

Inu, někteří pochopí, jak zhruba tenhle Matrix funguje, a někteří ne. To se nedá nic dělat. Někteří možná jen potřebují víc času… (Ale smát se jim můžu už teď.)

Oblíbil jsem si důležité základní principy (kterými se řídí například Btrfs a ZFS), nikoliv jeden konkrétní filesystém.

[trekker.dk]

Někteří to chápou, ale vyšší prioritu dávají stabilnímu chodu věcí bez překvapení.

[Andrej]

Tak potom mají Btrfs nebo ZFS.

Protože nechtějí, aby jim předpotopní Ext4 v kombinaci s předpotopním AIDem pomalu a potichu sežral data.

(A protože už nežijí v době legendárních 36GB SCSI disků nebo něčeho podobného.)

[kol-ouch]

Příloha:

• 091F70BB-D863-4FCF-95C3-852677DA4A0D.jpeg (683964 bytů)

V tom případě se přímo nabízí otázka - využít tenhle doplněk, nebo ne? Ze by se mi chtělo experimentovat s 3TB dat, to úplně ne...

[pavele]

Nainstaluj, proveď pár tvrdých výpadků, nasimuluj výpadek disku, prostě jak se to bude chovat v tvých podmínkách. Pak uvidíš.

Nastuduj si, co zfs vyžaduje - velikost RAM na GB disku, počet disků, a co od zfs očekáváš.

Nastuduj si, jak se chová v krajních podmínkách, které mohou nastat v tvém případě použití, jak se přidává disk, vyměňuje vadný atd...

Pak budeš mít odpověď.

[trekker.dk]

Tak potom mají Btrfs nebo ZFS.

Možná to ZFS, i když u toho se taky nějaké překvapení najde. Nicméně furt nic tak překvapivého jako třeba že když zaplníte Btrfs, tak to nejde řešit smazáním dat.

Protože nechtějí, aby jim předpotopní Ext4 v kombinaci s předpotopním AIDem pomalu a potichu sežral data.

Takže používají aktuální Ext4 a aktuální RAID a nemají problém.

[Petr Fiedler]

Nicméně furt nic tak překvapivého jako třeba že když zaplníte Btrfs, tak to nejde řešit smazáním dat.

A nelze tomu předejít nastavením kvóty?

[Heron]

Lze tomu předejít hromadou způsobů a hlavně to byl problém někdy v roce 2013. Jako celá tahle diskuse je už jen zaplevelená trolením z obou stran. Aneb pojďme se teda bavit o xfs v roce 1997.

Ještě k tomu místu na disku. Vzpomněl jsem si, jak někdo (admin z banky) v nějakém článku doporučoval mít na disku 4GB soubor, který v případě docházejícího místa smaže. Jako jestli někdo není schopen nastavit monitoring volného místa na disku, které by zareagovalo rychleji než dojde posledních 4GB místa, tak by v té bance pravděpodobně měl pouze drhnout záchody.

Prostě pokud dojde místo na disku, tak je to chyba administrace a nikoliv fs.

[billgates]

No ja neviem. Mne sa uz niekolkokrat stalo, ze do /var/log to napchalo za par minut niekolko desiatok giga logov, pricom inak tam pribuda niekolko MB za den. Niekedy sa proste stane, ze sa cely disk zaplni. S tym musi kazdy FS pocitat.

[Heron]

Tak já neříkám, že se z toho FS má zhroutit, ale na běžícím systému by místo prostě dojít nemělo, protože se z toho více než jedna služba může docela pokazit - znáte někdo nějakou analýzu přežití různých služeb po zaplnění disku? Spousta z nich využívá různé filedb s logy apod, tak by mě zajímalo, jak na tom jsou. Svého času se velice snadno dala rozbít berkeleydb.

[Petr Fiedler]

No ja neviem. Mne sa uz niekolkokrat stalo, ze do /var/log to napchalo za par minut niekolko desiatok giga logov, pricom inak tam pribuda niekolko MB za den. Niekedy sa proste stane, ze sa cely disk zaplni. S tym musi kazdy FS pocitat.

Nemusí. Já třeba mám z tohoto důvodu oddělen /var a přiřadil jsem mu 15 GiB. Pokud se něco zblázní a začne to logovat, tak po zaplnění /var mi po rebootu systém naběhne. Což by se nestalo, kdyby se zaplnil celý /. Kdybych používal Btrfs, tak bych pro /var nastavil kvótu a zase by to bylo OK.

[trekker.dk]

Lze tomu předejít hromadou způsobů a hlavně to byl problém někdy v roce 2013.

Tak pokud je platným argumentem proti ext4 problém z roku 2009, problém z roku 2013 je platným argumentem proti Btrfs, ne?

[Petr Fiedler]

Platný není ani jeden. Nemáš se nechat vyprovokovat. Se mi právě líbí, že stále odpovídáš slušně a trpělivě. Takovouto argumentací jsi se ale ponížil a shodil jsi i to, za co tu "bojuješ".

[LarryL]

Možná to ZFS ... jako třeba že když zaplníte Btrfs, tak to nejde řešit smazáním dat.

Jsi si jistý, že ZFS tím netrpělo?. V tom článku je spousta možností jak to vyřešit. Pro EXT4 zase existuje spousta článků jak řešit problémy, které se zase u BTRFS/ZFS řešit nemusí. Tím, že problém s mazáním souborů při 100% zaplnění vychází ze samotného designu COW, tak při bližším zkoumáním bychom možná zjistili, že to je/byla nehezká vlastnost většiny COW filesystémů.

[j]

Obavam se chlapce, ze ses naprosto mimo, a o ucelu raidu nemas ani paru.

Presne jak tu nekde kolem zminil trekker.dk, raid ma predevsim zajistit, ze sluzba pobezi dal, i v pripade selhani nejake komponenty, v tomhle pripade disku a nebo ... trebas casti ram, protoze slusnej HW umi raid i v ramce.

Dalsim ucelem raidu je pak navyseni vykonu.

A do tretice, zvednuti kapacity.

Proti ztrate dat jsou zalohy. Nikoli raid, ten s tim nema nic spolecnyho. To ze nedojde ke ztrate dat je ciste vedlejsi efekt.

Co se pak tyce chovani btrfs, tak muj nazor na to je, ze volba byla velice nestastna, predevsim vzhledem k tomu, jak se raidy bezne chovaji. Ale nikoli zakonite spatna. Jednoduse proto, ze remount (at uz na bezicim systemu nebo pri restartu) JE admin akce. A pokud se v tom admin hrabe, tak by asi mel primarne zjistit, ze ma chciplej disk a tudiz ho vymenit. Cimz padem by jaksi vubec nenarazil na to, ze se mu to pri !druhym! remountu pripoji uz jen RO.

---

Dete s tim guuglem dopice!

[Andrej]

Zase další anonym, který trochu tápe v tom, jak tenhle Matrix funguje, a trochu se neobtěžoval číst vlákno výše.

Presne jak tu nekde kolem zminil trekker.dk, raid ma predevsim zajistit, ze sluzba pobezi dal, i v pripade selhani nejake komponenty, v tomhle pripade disku a nebo ... trebas casti ram, protoze slusnej HW umi raid i v ramce.

A přesně to Btrfs RAID zajišťuje, jak už tady bylo opakovaně zmíněno. Služba běží dál. Pojem běží dál ovšem nemusí nutně zahrnovat reboot — ten se do běhu jako takového většinou nepočítá, víme???

Ještě jednou (už asi popáté) připomenu, že tady není řeč o volbě Btrfs (který umožňuje několik možných chování v případě selhání disku), nýbrž o volbě uživatele. Uživatel si může v příkazové řádce kernelu (nebo v /etc/fstab) klidně nechat napořád kouzelné slůvko degraded, pokud si myslí, že se to takhle má chovat. V čem přesně je problém?

Další otázka je, o jaké službě se bavíme. Ano, pro mail server v JZD Vidlákov opravdu platí, že služba má běžet dál, za každou cenu, do roztrhání příslušného (nejspíš jednoho) stroje. Potud souhlas. (To Btrfs jaksi implicitně splňuje.)

U služby nějakých větších rozměrů (například u služby poskytované veřejně) je tohle celé nesmysl a RAID jako takový tam je téměř nepodstatný. RAID tam rozhodně nezajišťuje, že služba běží dál. To zajišťuje redundance mnoha (tisíců) strojů v mnoha geograficky oddělených lokalitách, redundantní na všech úrovních od synchronizačních primitiv (Paxos) až po jeden globální systém. Tolik jen ve zkratce k tomu, jak tenhle svět (ne)funguje a kde je RAID (ne)podstatný.

[trekker.dk]

Služba je i to, že můj domácí počítač jde vypnout a zapnout. To reboot zahrnuje jaksi z principu.

[k3dAR]

me hlavne unika proc je v poradku kdyz stavajici rw pripojeni po vypadku disku muze byt pouzivano treba rok, ale pokud 5minut po vypadku udelam 1(2) rebooty, tak uz nema byt v poradku rw pripojeni... chapu ze se to da okecet ruzne aby to vyznelo ze to v poradku je, ale to neni v poradku

[Josef Kufner]

Je to ptákovina a velmi dobrý důvod proč nemít degraded v /etc/fstab. BTRFS se prostě neumí vzpamatovat z degraded stavu. Dokonce pokud ti vypadne disk, třeba vadným kabelem, a dojde na degraded mount, tak už disk nejde vrátit. Musí se vymazat a přidat jako prázdný nový disk. Tím se samozřejmě riskuje, že případná poškození dat na zůstavším disku budou fatální. Drobný výpadek napájení tak dokáže nadělat velkou paseku.

Správné řešení by bylo, aby BTRFS dočasně nedostupný disk vzalo a sloučilo stromy zpět do jednoho. Je potřeba si jen poznamenat, kdy došlo k degraded mountům, aby šlo detekovat, zda disky nebyly připojovány na střídačku.

[Jendа]

Dokonce pokud ti vypadne disk, třeba vadným kabelem, a dojde na degraded mount, tak už disk nejde vrátit. Musí se vymazat a přidat jako prázdný nový disk.

LOL no jo, to fakt nemá nic jako write intent bitmap? (MD RAID si při krátkodobém vyndání disku pamatuje, které bloky měnil, a pak dosyncuje jenom ty -- samozřejmě si můžeš vynutit přečtení všech ostatních, abys zjistil, jestli je to fakt v pořádku. Každopádně pointa je, že nedojde k tomu vymazání, takže když po většinu doby vypadne nějaký jiný disk, data furt máš)

velmi dobrý důvod proč nemít degraded v /etc/fstab

No jo, ale když chci mít na btrfs /? A jak tady Andrej propaguje, partitions a LVM jsou pasé, celé to má být jeden FS a mít subvolumes. Tak to pak stejně musím namountovat celé.

[Josef Kufner]

Tak máš prostě smůlu a nenabootuješ. O data sice nepřijdeš, ale nedostaneš se k nim, neboť server je nedostupný.

Pokud dáš do /etc/fstab volbu degraded, tak po poruše nabootuješ jednou, vypadne proud a potřebuješ sehnat nový disk, aby bylo kam přesunout data.

[Andrej]

Proto jsem zmínil klíčovou frázi větších rozměrů.

Domácí počítač je asi tak stejně velká služba jako mail server JZD Vidlákov, tedy rozhodně ne větších rozměrů.

Na domácím počítači (pokud jeho data rozumně pravidelně zálohuji) si klidně nastavím/povolím degraded a pak není co řešit.

Ano, bylo by skvělé, kdyby Btrfs podporoval hot spare. Třeba něco takového v budoucnu přibude. V seznamu feature requestů na Wiki to je.

[trekker.dk]

To je možné, že domácí počítač a server JZD není služba větších rozměrů, nicméně taky máme (já i ti zemědělci) zájem na tom, aby to fungovalo, což nesmyslné rozhodnutí vývojářů Btrfs komplikuje

[Andrej]

…nicméně taky máme (já i ti zemědělci) zájem na tom, aby to fungovalo…

Tedy Btrfs je jasná volba.

…což nesmyslné rozhodnutí vývojářů Btrfs komplikuje

Které přesně rozhodnutí? Že budou při mountu striktně vyžadovat dodržení slibované redundance a komu se to nelíbí, může si někam připsat kouzelné slůvko degraded?

No to je ale hrozivé rozhodnutí! Hrůza pomyslet, fakt.

[trekker.dk]

Tedy Btrfs je jasná volba.

Fungovalo, aniž by se kolem toho muselo běhat a řešit překvapení: Btrfs je volba, které se jasně vyhnout

[Andrej]

Tedy Btrfs je jasná volba.

Fungovalo, aniž by se kolem toho muselo běhat a řešit překvapení: Btrfs je volba, které se jasně vyhnout

To musí být děsivé, takhle netušit, která bije, jak tenhle svět funguje, o co se vůbec jedná atd.

Jasně, takový Facebook se svými statisíci strojů pořád jenom běhá a řeší překvapení. (Nebo ne?)

Kdy už si anti-Btrfs FUDisté neuvědomí, že Btrfs nebo ZFS přináší mnohem méně překvapení než zastaralé filesystémy (protože dokážou včas odhalit problematický hardware a celkově mají mnohem lepší odolnost proti poškození dat)?

[trekker.dk]

Ext4 tím, že nefunguje na RAID 5 nebo že se najednou připojí readonly nebo že nedostatek místa nelze vyřešit smazáním dat, ještě nikoho nepřekvapil.

[Andrej]

To má být asi vtip, tohleto.

Že Ext4 nefunguje na RAID 5, to se ví. (Takže v tomto smyslu to jistě nikoho nepřekvapí.) Mnozí si mysleli, že mají RAID 5 pod Ext4, než zjistili, že to byl pouhý AID 5 se svým vyhlášeným data žeroucím resilveringem bez checksumů.

Ext4 má mnohem větší šanci, že skončí v režimu read-only, než Btrfs. Zaprvé má zastaralý FSCK, tj. spousta drobných oprav, které v Btrfs zvládnou algoritmy přímo v kernelu v rámci mountu, skončí u Ext4 jako read-only režim s nutností FSCK. Zadruhé nemá žádnou vestavěnou redundanci, ani v rámci jednoho disku, ani přes několik disků.

Ten FUD se zaplněním disku už je ohraný; co takhle zvolit novější gramofonovou desku než hitparádu 2013 nebo ze kdy tohle je? (Nemluvě o tom, že uživatel jiný než root nemá mít vůbec kvótu na to, aby zaplnil celý disk.)

[trekker.dk]

Že Ext4 nefunguje na RAID 5, to se ví.

Ale, odkdy? Poslyšte, vy máte takových problémů s věcmi, co jiným fungují, jestli ono to nebude rukama...?

Ten FUD se zaplněním disku už je ohraný

Historii nesmažete.

[Andrej]

Historii nesmažete.

Přesně! Ext4: 2009, 2012, 2015, 2018, … to byly roky, co? Je v plánu i 2021?

Mimochodem, nastavení dnešních strojů (o kterém byl taky původní dotaz) se řídí dávnou historií odkdy?

[trekker.dk]

Ext4: 2009, 2012, 2015, 2018, … to byly roky, co?

Btrfs: 2013 (a další), to byly roky, co?

A to je ještě rozdíl v tom, že ty bugy v Btrfs byly bugy v Btrfs, zatímco vy šíříte FUDy i o případech, kde bug byl v aplikacích, které něco dělaly chybně v rozporu se specifikací a opravoval to za ně filesystém.

[Andrej]

Jasně, protože aplikace přece mají nějakou moc nad tím, co dělá filesystém v kernelu. A teď ještě tu o Červené karkulce.

Btrfs je prostě lepší než předpotopní sračky, po všech stránkách. Tečka, hotovo. Ještě nějaké nepochopení? Ještě nějaké otázky?

Ach jo. Tohle snad není možné. Pořád někdo bude hájit ty sračku žeroucí data, například mdadm/dmraid + Ext4. Je tohle nějaká zvrácená forma Stockholmského syndromu nebo co?

[trekker.dk]

Jasně, protože aplikace přece mají nějakou moc nad tím, co dělá filesystém v kernelu

Ano, to mají, docela velkou. Ten mechanismus se jmenuje systémová volání, zkuste si to najít.

Btrfs je prostě lepší než předpotopní sračky, po všech stránkách.

Ano, problémy s Btrefs jsou prostě lepší po všech stránkách. Život by bez nich byl nudnější a člověk by musel přemýšlet, co dělat s volným časem.

Pořád někdo bude hájit ty sračku žeroucí data, například mdadm/dmraid + Ext4.

Já nevím, co jste s tím dělal, že vám to žralo data.

[Jendа]

Že budou při mountu striktně vyžadovat dodržení slibované redundance a komu se to nelíbí, může si někam připsat kouzelné slůvko degraded?

LOL GPT-3 s omezeným kontextem. Ne, mluvil o případu s kernelem před 4.12 (cca.). Ten už samozřejmě teď neplatí, ale bojí se, že na nějaké další podobné překvapení narazí.

[Andrej]

Zatímco pravidelných 3-letých průšvihů v Ext4 (a další, plíživé silent data corruption mezi nimi) se nejspíš nebojí. No jo. Klasika.

[j]

Jo, proste sme se jen dozvedeli, ze ses tupec, kterej naprosto netusi o cem zvani.

Mam tu vedle sebe HW za par mega a kazdej jeden kousek muzu restartovat klidne 100x, a i s mrtvym diskem (nebo vice diskama) pobezi dal, dokud bude technicky schopen provozu. A bude me (a zaplacenymu supportu u dodavatele) pravidelne posilat hlasky ze disk(y) je v hajzlu.

Coz kupodivu povede k tomu, ze tak do max 2 dnu ten disk "sam" dorazi a potazmo se "sam" vymeni. A vis proc ty tupce do 2 dnu? Jednoduse proto, ze selhani disku se nepovazuje za kritickou zavadu.

A znova opakuju, NIKDE NIC EXTRA kvuli takovymu chovani neni treba nastavovat. Chova se tak presne 100% vsech raidovych poli. A to vcetne tech, ktery vlastne podle tebe uz raid nejsou, protoze se chovaji stejne jako btrfs.

Tvuj finalni odstavec jen potvrzuje, jak moc velky hovno o tom vis, protoze mira zabezpeceni provozu kupodivu odpovida pozadavkum a predevsim financim. RAID je jedna zdaleka nejrozsirenejsich a zdaleka nejpouzivanejsich technik, protoze selhani disku je zdaleka nejpravdepodobnejsi typ zavady. Nemluve o tom, ze na provoz v clusteru musi byt aplikace navrzena a neumi to defakto ani vetsina databazi.

---

Dete s tim guuglem dopice!

[Heron]

Bylo to pro všechny verze od začátku do 4.něco a umožnilo to jednou rw a pak už pouze ro.

O tom teda dost pochybuju. Články jsem psal v roce 2011 od tehdy jsem s tím dělal psí kusy a na toto jsem nikdy nenarazil. Potom to někdo řešil tady na abc a to jsem testoval a opět nic. Asi jsem nějak ty konkrétní verze přeskočil.

RAID si lidé typicky pořizují proto, aby systém fungoval i při selhání jednoho disku, což zde splněno nebylo.

Nechám stranou tento konkrétní účel (který pro mě rozhodně neplatí), ale pokud si lidé něco pořizují, tak by si o tom jednak měli něco zjistit a pro svůj účel taky otestovat. Jestli někdo nasadí něco a doufá, že se to bude chovat stejně jako něco jiného, tak to je nejrychlejší cesta do potíží.

A přesně proto vznikají naprosto nesmyslné diskuse, kdy někdo nasadí něco a potom to používá podle zvykového práva něčeho zcela jiného.

[trekker.dk]

A přesně proto vznikají naprosto nesmyslné diskuse, kdy někdo nasadí něco a potom to používá podle zvykového práva něčeho zcela jiného.

Ano, to je situace, která nastane, když vezmete běžně používaný termín s nějaký významem a použijete jej pro něco jiného, což přesně udělali vývojáři btrfs, když jejich ne-RAID pojmenovali RAID. Je to jako kdyby výrobce prodával smartphone, ale ve skutečnosti ta věc uměla jenom fotit. To se nazývá podvod.

Pro srovnání si vezměte třeba Ceph - tam výraz RAID používají jen při srování "tato naše věc pojmenovaná X je něco jako RAID". A když to někdo nasadí, k žádnému zmatku nedojde.

[Heron]

No já nevím, možná mám nějaké telepatické spojení s autorem btrfs, protože mě od prvního setkání bylo naprosto jasné, co přesně je slovem raid v pojetí btrfs míněno. Je to dané už jen těmi vlastnosti multidevice, tedy libovolný počet libovolně velkých disků. Pokud si někdo pod pojmem raid-1 představuje jen to, že na všech discích jsou stejná data, tak by mě fakt zajímalo, co by se podle něj mělo stát v případě, kdyby se tam připojil menší disk. To by rázem přišel o data větší než, nebo by to ten disk mělo odmítnout? Fakt nevím.

Ale pro mě za mě si to pojmenujte jak chcete, já na konkrétním názvu netrvám. Nehledě na to, že pojem RAID si vykládají po svém i HW řadiče a třeba umožní vytvořit RAID-10 nad lichým počtem disků (vyzkoušeno omylem na Arece). To už by fakt člověk musel hejtit všechno.

[trekker.dk]

Pokud si někdo pod pojmem raid-1 představuje jen to, že na všech discích jsou stejná data, tak by mě fakt zajímalo, co by se podle něj mělo stát v případě, kdyby se tam připojil menší disk.

Že velikost reálně využitelného prostoru bude rovná velikosti menšího (ze dvou) disku? Jako u jakéhokoliv jiného RAIDu, ať už HW nebo SW. (Pro víc disků analogicky, i když na HW řadiči jsem tohle nezkoušel.) Což by ostatně mělo nastat i u toho btrfs (teď mluvím o případu s 2 disky), jen s tím rozdílem, že v principu může zkousnout, když menší disk dostane jako náhradu disku, co selhal (protože nereplikuje prázdné místo, tj. když se vejdou data.)

[Peter Golis]

Pokud si někdo pod pojmem raid-1 představuje jen to, že na všech discích jsou stejná data, tak by mě fakt zajímalo, co by se podle něj mělo stát v případě, kdyby se tam připojil menší disk. To by rázem přišel o data větší než, nebo by to ten disk mělo odmítnout? Fakt nevím.

Zaujímalo by ma, prečo by SW RAID nemal odmietnúť menší disk. On ten RAID nerobí s menšími mernými jednotkami ako s blokovými zariadeniami.

[root@CentOS-6 tmp]# truncate -s 1G del/file-5.img
[root@CentOS-6 tmp]# truncate -s 512M del/file-6.img
[root@CentOS-6 tmp]# losetup /dev/loop4 del/file-5.img
[root@CentOS-6 tmp]# losetup /dev/loop5 del/file-6.img
[root@CentOS-6 tmp]# mdadm --add /dev/md0 /dev/loop4 /dev/loop5
mdadm: added /dev/loop4
mdadm: /dev/loop5 not large enough to join array
[root@CentOS-6 tmp]#

[Heron]

Zaujímalo by ma, prečo by SW RAID nemal odmietnúť menší disk.

Ať si klidně odmítne (ostatně to tak dělají), ale ať mi teda někdo vysvětlí, jak by to šlo dohromady s ostatními deklarovanými vlastnostmi multidevice btrfs. Tj přidej disk, odeber disk (s ohledem na dostatek místa pro data), bez ohledu na počet a velikost. Tohle jsou vlastnosti deklarované už možná někdy v roce 2009.

[Peter Golis]

ak by to šlo dohromady s ostatními deklarovanými vlastnostmi multidevice btrfs

A prečo by to malo ísť dohromady? RAID na úrovni blokového zariadenia má inú filozofiu ako RAID na úrovni FS.

Ale na druhú stranu by ma zaujímalo ako si v prípade BTRFS vytvorím RAID Mirror tak aby boli dáta zapísané naraz v troch kópiách. Chcel by som mať totižto domáci NAS odolný voči výpadku jedného disku, a nechcem ten NAS pripájať cez UPS a Dízel Agregát.

[Heron]

Ale na druhú stranu by ma zaujímalo ako si v prípade BTRFS vytvorím RAID Mirror tak aby boli dáta zapísané naraz v troch kópiách.

BTRFS nabízí RAID1C3 nebo RAID1C4. Kdy data zapisuje ve 3 nebo 4 kopích.

[Peter Golis]

To je ale krásna novinka. Dokáže takto vytvorený RAID1C3 ustáť opätovné pripojenie po zlyhaní jednej z troch aktívnych kópií?

Ak áno, tak by to úspešne eliminovalo vyššie a hlavne už roky rokúce spomínaný problém.

[k3dAR]

to by me take zajimalo, ale podle toho co dinosaur psal asi ne, kdyz je podle nej v poradku ze po vypadku 1 disku je to pripojene v rw "jakkoliv" dlouho a rw pripojeni je v poradku ze to odmitne pri pristim(nebo prespristim) mountu...

[Heron]

Otestujte a dejte vědět.

[Peter Golis]

Krásne odôvodnenie, veľmi profesionálne.

Pán robí pre ktorú nadnárodnú korporáciu že vraví: "toto už funguje, ale nie je to otestované"?

[Heron]

Pardon?

Ptal jste se na možnost tří kopií, tak jsem vám poradil. Není přece mojí povinností vám to ještě otestovat ve vašem konkrétním případě. Od toho je to OSS a od toho jsou tyto veřejné poradny, aby každý mohl přispět. Takže až si to vyzkoušíte, můžete (nemusíte) dát vědět i ostatním.

[Peter Golis]

Už vám rozumiem mladý pán. Zaujímalo ma to len z toho pohľadu, či ľudia obhajujúci nejakú funkcionalitu s tou funkcionalitou aj prišli do styku inak ako prečítaním novín.

PS: Testoval som to, a jeden vypadnutý disk z RAID FS mi neohrozil pripájanie poškodeného poľa. Akurát že to nebolo u BTRFS. Samotný BTRFS ma začne zaujímať až keď doň konečne naimplementujú transparentnú deduplikáciu (za letu). Plánujú to zatiaľ len 7 rokov.

[trekker.dk]

Naučte se číst. "Nabízí" a "funguje" jsou jiná slova. Taky by bylo vhodné nepsat to, co předřečník netvrdil, jako jeho citaci, ale to už na vás asi bude moc

[Peter Golis]

Predrečník reagoval na vetu (citujem): Chcel by som mať totižto domáci NAS odolný voči výpadku jedného disku, a nechcem ten NAS pripájať cez UPS a Dízel Agregát. Ale to je asi na vás až priveľa.

[trekker.dk]

A dostal jste odpověď, že btrfs něco nabízí. Od té chvíle debatujete s hlasem ve vlastní hlavě.

[Peter Golis]

Áno. Dostal som informáciu o poskytovaní neotestovaného riešenia.

[Andrej]

Neotestovaného ve srovnání s čím? V jakém slova smyslu?

Ext4 je neotestované řešení, podle stejné logiky. Přesto ho někteří stále používají. (Naštěstí aspoň ta Fedora konečně dostává rozum.)

[Peter Golis]

Ja chápem že si si nevšimol o čo sa jedná, tak ti to pripomeniem:

Jedná sa o prístup k dátam po výpadku jedného z redundantných diskov. Schválne som obetoval asi 10 minút z môjho života aby som si overil že tú funkcionalitu BTRFS nik netestoval.

Spravil som si 4 LUNy (sparse, loopback) a nad nimi som vytvoril BTRFS pole s profilom RAID1C3 pre dáta a aj metadáta. Pochopiteľne som to pole pripojil, a nahral naň nejaké údaje. Následne som to pole odpojil, a zlikvidoval dva disky. Vo výsledku som mal nejaké údaje nahraté na poškodenom poli, ktoré ale malo stále zachovanú redundanciu. Alebo aspoň malo možnosť si ju zabezpečiť. Toto pole som sa následne pokúsil pripojiť, a výsledok ma neprekvapil:

root@Ubuntu-2010:~# mount -v -t btrfs /dev/disk/by-uuid/052cc789-14f1-4857-a2a5-0a98cda5ace0 /mnt/BTRFS
mount: /mnt/BTRFS: wrong fs type, bad option, bad superblock on /dev/loop21, missing codepage or helper program, or other error.
root@Ubuntu-2010:~# dmesg | tail
...
[  191.746410] BTRFS info (device loop21): disk space caching is enabled
[  191.746411] BTRFS info (device loop21): has skinny extents
[  191.747060] BTRFS error (device loop21): devid 1 uuid 799e5847-0daf-4d00-bdbb-139c23e99fc1 is missing
[  191.747093] BTRFS error (device loop21): failed to read chunk tree: -2
[  191.765276] BTRFS error (device loop21): open_ctree failed

Tak tomuto sa povie zrkadlenie údajov na viacero lokácií, aj s redundantným prístupom.

Oproti desaťročia overenej kombinácii (EXT FS a SW RAID) to naozaj a stále nefunguje. Ten BTRFS síce ponúka kontrolné súčty aj na dáta (eliminuje silent data corruption), ale práca s dátami na degradovanom (ale stále redundantnom) poli je viac ako riziková.

Alebo som snáď urobil niekde chybu? Skús ma vyviesť z omylu, a ukázať ako BTRFS pole prežije výpadok disku aj s viacnásobným reštartom.

[frr]

Možná bych si dovolil cosi velmi nesměle namítnout:

RAIDy jedné nejmenované značky se chovají tak, že když najdou při startu na množině přítomných disků nakonfigurovaný RAID volume, ve kterém evidentně jeden disky fyzicky schází (nebyl při startu vůbec nalezen mezi připojenými), ačkoli před vypnutím RAIDu ten disk byl do poslední chvíle živý, tak firmware RAIDu neřekne "volume je tímto degradován", ale namísto toho prohlásí: "tady měl být jeden zdravý disk, neviděl jsem ho za jízdy umřít, takže mě hezky zase vypněte a koukejte mi ten disk připojit zpátky, nejspíš máte jenom vytažený kabel. Kvůli tomu přece nebudu degradovat pole." V terminologii dané značky se tomu říká "incomplete array". Je to pojistka proti tomu, aby kvůli banální lidské chybě nebylo pole zbytečně označeno jako degraded, nemusel povinně proběhnout rebuild, nehrozila zbytečná ztráta dat, pokud se při rebuildu nedejbože najdou spící vadné sektory apod.

= jestli to náhodou není tak, že zdvořilé zmizení podkladového zařízení za studena není pokládáno za platnou degradaci svazku

A v tom případě bych taky čekal, že bude existovat nějaký postup, jak RAIDu říct "ale ano, ten disk vážně umřel, už ho nikdy neuvidíš, tak prosím vytáhni hlavu z písku a to pole laskavě nastartuj v degradovaném režimu".

Nácvik kritických situací je problematický u jakéhokoli RAIDu. Protože některé druhy realistických závad se simulují docela nesnadno.

[Peter Golis]

Ak sa smiem opýtať, čo je to za značku? Takéto chovanie mi pripomína výsledok z vyššie spomenutého testíku. A asi to bude jedna zo spoločností, ktoré spoluvyvíjajú BTRFS.

Ono, logicky to nie je zlá vlastnosť. Ale vyžaduje to mať dostatok rezervných diskov a zabezpečenie kontinuálneho napájania. A vyžaduje to aj šťastie, aby pri náhrade vadného disku neľahlo diskové pole kvôli zvýšenému I/O. A v takomto prípade by som už radšej použil RAID6 a nie mirror cez viacero diskov.

[frr]

"array incomplete" je charakteristická vlastnost firmwaru Areca. A s BTRFS pokud vím nemá tato značka nic společného. A tu záhadu už tady vysvětlili povolanější řečníci...

[Heron]

Arecy jsou vůbec super. Kdysi dávno se nám pravidelně zasekával řadič v diskovém poli a zjistili jsme, že je to vyčítáním senzorů (icinga). Při dostatečně rychlém vyčitání se to dalo zaseknout v řádu minut, jinak při běžném provozu to bylo v řádu týdnů.

Napsali jsme na arecu a ti nám poslali obratem patch. Proč to nebylo v officiálních updatech nám nějak neřekli.

Potom baterka neměla klíčovaný konektor, takže šla připojit na obě polarizace a když jste to udělali, tak to odpálilo řadič.

[frr]

děkuji za historky z natáčení, tyhle jsem neznal. Mě třeba s Arecou aktuálně tlačí bota v tom směru, že jejich SNMP subagent pro Windows nějak nefunguje s poslední generací ARC-1203 a ARC-1214. A máme zákazníka, který se dožaduje informací o stavu RAIDového svazku skrz Windows SNMP (z dvoukanálové ARC-1203-2i to ani jinak vypáčit nejde, větší Arecy mají svůj vlastní Ethernet, kde SNMP normálně funguje, ale už to znamená přiřadit další IP adresu). Prostě toho wokenního subagenta mají neaktuálního a nic moc s tím nedělají. Jinak jejich technická podpora reaguje, to je třeba pochválit - a vesměs nepoužívají čínské výmluvy typu "já špatně rozumět".

Arecu dlouhodobě preferuji proti Adaptecu a MegaRAIDu (ostatní značky už byly asimilovány a zlikvidovány) jednak kvůli bezproblémové trvalé dostupnosti a dodržování tradic, jednak protože jejich BIOSový konfigurační tool (vlastně terminál, to menu je vytvářeno firmwarem) i zabudované HTTP GUI jsou přehledné a lehkotonážní, přitom v případě potřeby podrobné. Adaptec má některé vlastnosti, které mi vadí, jejich menu je méně podrobné, a speciálně MegaRAID dělá z admina vyloženě blbečka (přitom podle SNMP se zdá, že pod kapotou je to složité jak autobus). A přitom zrovna MegaRAIDu ten SNMP subagent funguje. Pokud se k dotyčnému downloadu dokážete doklikat skrz nepřehledný web Broadcomu, a nevadí Vám over-engineered MIBka s milionem mrtvých položek.

Za mě Arecy převážně *jsou* super, pro normálního smrtelníka.

[Heron]

S MegaRaidem mám taky super historku. Odešel disk v raid5, strčili jsme tam nový a přidali do pole (nějakým cli příkazem). A řadič se nějak ani neuráčil udělat resilvering a začal ten disk prostě rovnou používat. Takže FS totálně v prd, data v háji.

Jako jo, Arecy jsou (po několika updatech firmware) docela dobré. Sice mají svoje vlastnosti, jako že třeba bez mrknutí vytvoří raid10 nad lichým počtem disků (takže ty stripe mají nějak distribuované a tedy by se to nemělo jmenovat raid10 ) ale jako funguje to.

[frr]

Že by byl MegaRAID takhle moc v háji, to mi přijde divné. Ledaže ten CLI příkaz nebyl moc otestovaný, protože CLI odhadem málokdo použije... nebo byl v dané situaci nevhodný. Podle mé čerstvé zkušenosti s mirrorem stačilo vrazit do šachty za jízdy factory clean disk a MegaRAID rovnou začal rebuildovat (pro srovnání, Areca má tohle chování údajně v posledních firmwarech vypnuté a je třeba ho kdesi v menu zapnout). Pokud rebuild na nový disk neklapne automaticky, tak se většinou snažím najít cestičku přes označení nového disku jako hot spare, v tu chvíli by po něm řadič měl chňapnout a začít na něj rebuildovat.

Zrovna minulý týden nás fungl nový MegaRAID překvapil tím, že když dá člověk vytvořit mirror ze dvou prázdných disků, tak to nedělá vůbec žádný init (přepis nulami) a nevšiml jsem si, že by to šlo nějak zapnout. Areca tuším taky umí "no init (to rescue volume)" ale je třeba si o to říct, když vytvářím volume. Jasně, pokud následuje mkfs, tak je teoreticky jedno, jestli byly disky prázdné nebo ne - protože validní novou strukturu prázdného FS vyrobí mkfs, a neodkazované prázdné místo je irelevantní...

[trekker.dk]

MegaRAIDu (ostatní značky už byly asimilovány a zlikvidovány)

Není to dneska LSI, Avago, Broadcom?

[frr]

Ano je to tak. Vaše poznámka mě poňoukla, konečně nakreslit mapu vzájenmého požírání výrobců malých RAIDů, kterou jsem měl v plánu už dávno.

[Heron]

Ehm, co takhle třeba -o degraded?

O data nepřijdete. Udělal jsem test, RAID1C3, tři zařízení. Nahrál data. Umount. Dvě zařízení jsem zrušil. Mount -o degraded, fs je normálně dostupný rw.

Tj no problémo.

Label: none  uuid: 6b47b4a3-c7f9-4c45-8f7a-c87cf8c9d0d2
	Total devices 3 FS bytes used 995.74MiB
	devid    1 size 16.00GiB used 1.26GiB path /dev/mapper/VGData-a
	*** Some devices missing

A celkem logicky to chce další disky:

root@tomas:/mnt/test# btrfs device remove missing /mnt/test
ERROR: error removing device 'missing': unable to go below three devices on raid1c3

Ale dá se to obejít:

btrfs balance start -dconvert=single -mconvert=dup /mnt/test

btrfs device remove missing /mnt/test

A FS je opět happy:

Label: none  uuid: 6b47b4a3-c7f9-4c45-8f7a-c87cf8c9d0d2
	Total devices 1 FS bytes used 997.07MiB
	devid    1 size 16.00GiB used 2.06GiB path /dev/mapper/VGData-a

Takže, na počátku raid1 se třemi kopiemi. O dvě (!!!) zařízení se přišlo. Buď mu je dodám zpět, ale pokud už nechci redundanci, tak to převedu na single a je to.

[Peter Golis]

Tu sa natíska krásna otázočka ako od BFU:

Ako zadám daný parameter pri štarte OS keď sa jedná o /, a koľko bežných reštartov to vydrží bez servisného zásahu? Jedná sa mi naozaj o bežnú prácu pri zachovaní redundancie. Nejedná sa mi o magický oltár, okolo ktorého musí človek tancovať aby neupadol v nepriazeň osudu.

Žiaľ, vypnúť a zapnúť je bežné riešenie u väčšiny populácie, aj mimo IT. Nevravím že je takéto riešenie vždy aj správne, ale je najpoužívanejšie.

[Heron]

Ako zadám daný parameter pri štarte OS keď sa jedná o /

Snad každý boot manager umožnuje ručně nastavit parametry jádra.

koľko bežných reštartov to vydrží bez servisného zásahu?

∞ + 1

[Peter Golis]

Takže sme sa zas vrátili do akademickej roviny. Teda že redundancia funguje len ak človek ručne pridá nejaké doplnkové parametre. Človek si predsa zapína RAID aby vedel s poľom fungovať vždy, nie len po vynútení.

To je oproti bežnej kombinácii EXT FS na SW RAID, alebo ZFS trošku dosť nepohodlné.

Mimochodom, má to ale značný háčik. Ak pripíšem dáta na degradované diskové pole, tak ich zapisuje v profile single, a nie mirror aj keď bolo pole vytvorené s profilom mirror. Nechcem vedieť prečo.

[Heron]

Teda že redundancia funguje len ak človek ručne pridá nejaké doplnkové parametre.

Ach jo. Já nevím, jestli jste troll nebo to myslíte vážně.

Zvolená míra redundance funguje vždy a je úlohou admina nastavit ten systém tak, aby i po očekávaném výpadku zařízení byly splněny dané podmínky. Tj nikoliv si nastavovat degraded jako default (jak tady někdo blbě radil), ale mít takový počet disků, aby při očekávaném výpadku počtu disků byly stále splněny podmínky. Tj pro raid1 a výpadku jednoho disku mít minimálně tři disky.

Problém je, že se tady (nejen v této diskusi) furt bavíme o jednom až dvou discích a tedy se neustále naráží na krajní podmínky a potom se vymýšlejí kravská řešení. BTRFS je multidevice fs, takže jich tam můžete mít kolik chcete. A ve chvíli, kdy máte dostatek disků a volné místo na fs, tak na tyto věci nikdy nenarazíte.

Človek si predsa zapína RAID aby vedel s poľom fungovať vždy, nie len po vynútení.

Pro mě tohle neplatí. Já si redundanci nastavuji, abych snížil riziko ztráty dat. Dostupnost se řeší jinak. Ono totiž tohle je další příklad tunelového vidění. Řeší se jen disky a dostupnost pole. Ale on ten komp může shořet jako celek. Takže pokud potřebujete dostupná data, musíte mít automaticky více kompů.

To je oproti bežnej kombinácii EXT FS na SW RAID, alebo ZFS trošku dosť nepohodlné.

Tak si to používejte, pokud vám to vyhovuje. Nikdo vám přece nic nenutí.

Ak pripíšem dáta na degradované diskové pole, tak ich zapisuje v profile single, a nie mirror aj keď bolo pole vytvorené s profilom mirror.

A jak přesně by to měl zapisovat jako mirror, když nemá dostatek zařízení?

[trekker.dk]

Tj pro raid1 a výpadku jednoho disku mít minimálně tři disky.

Když je to úlohou admina, tak mi určitě poradíte, jak vyřešit následující: mám server s 12 sloty pro disky, požadovaná úroveň je RAID 1, požadavky na kapacitu vyžadují použití šesti polí, přičemž server má tři druhy úložišť (v konfiguraci 1/2/3 spojená pole), na které se používají různé disky. Kromě prvního druhu úložiště vytvořeného z jednoho pole je zbývající volné místo úložiště menší než kapacita jednoho disku, který dané pole tvoří. Při výpadku kteréhokoliv disku musí být (váš požadavek) úroveň raidu zachována.

Jak?

Ale on ten komp může shořet jako celek.

Pravděpodobnost jednotlivých událostí tu hraje docela zásadní faktor. Kolikrát vám shořel komp a kolikrát vám chcípnul disk? Za mě ten rozdíl bude tak o dva řády.

[Heron]

Nemůžu tvrdit, že jsem tu slovní úlohu pochopil (nepřekládal jste Sira Humphrey Applebyho?), ale netuším, jaký smysl má pokládat neřešitelné otázky. Prostě si pořiďte 3 servery, nebo já nevím.

Pravděpodobnost jednotlivých událostí tu hraje docela zásadní faktor. Kolikrát vám shořel komp a kolikrát vám chcípnul disk? Za mě ten rozdíl bude tak o dva řády.

Jasně. Ale pointa byla v tom, že ty věci lze dělat a přemýšlet o nich i jinak. Buď budu mít jeden jediný pozlacený server, který nikdy nechcípne, nebo půjdou cestou jako google na počátku, tedy mít levné desky na poličce a když jedna chcípne, tak se nic nestane.

Právě proto jsem v soukromí přestal řešit bedny pro x disků, řadiče disků apod. Prostě mám vedle sebe několik beden, každá 6 disků na levné základce. Nakonec je to i levnější řešení, protože ta bižuterie kolem (tj bedna, zdroj, deska, cpu, paměti) jsou ve skutečnosti levnější, než nějaká jedna bedna pro 48 disků.

Navíc se tím získá i výpočetní výkon, takže můzu snadno rozhodit úlohy mezi x cores dostupných na síti. Ony i ty levné obyč i5 něco dokážou spočítat.

[trekker.dk]

jaký smysl má pokládat neřešitelné otázky. Prostě si pořiďte 3 servery, nebo já nevím.

Smysl je jednoduchý - ne ve všech situacích je možné splnit to, že v serveru bude pro každé pole spare disk. (I když jako pole budu brát hromadu disků spojených do jednoho btrfs, abych nezanedbal výhodu, kterou softwarový MD nemá.) Tohle je případ, kdy se tam prostě nevejde. I kdyby se vešel, bavíme se o nějakých 1/4 milionu v nevyužitých discích (i když na něj btrfs bude zapisovat, nevyužitelné volné místo bude vždy větší než kapacita jednoho disku, tj. v poli je nevyužitý disk)

V případě, že bych si pořídil "3 servery", tak se kvůli tomu požadavku dostávám na řádově miliony za hardware a nějaké statisíce ročně za místo v datacentru.

Obojí je více či méně ekonomický nesmysl - aspoň do určité velikosti firmy, pak už je to asi jedno. A režim fungování, že v případě výpadku disku někdo dojede DC disk nahradit nějakým spare ze skladové zásoby, je perfektně validní. I když vývojáři btrfs tvrdí opak.

[Peter Golis]

Ak pripíšem dáta na degradované diskové pole, tak ich zapisuje v profile single, a nie mirror aj keď bolo pole vytvorené s profilom mirror.

A jak přesně by to měl zapisovat jako mirror, když nemá dostatek zařízení?

To pole malo stále dostatok zariadení na zrkadlenie dát. Zlikvidoval som mu len dva zo štyroch LUNov. A aj napriek tomu to vyriešilo východzím profilom. Toto je krásne prekvapenie.

Tak si to používejte, pokud vám to vyhovuje. Nikdo vám přece nic nenutí.

Veď to aj robím. Používam to, čo mi vyhovuje, Do budúcnosti ma zaujalo či náhodou BTRFS nechce dohnať ostatné moderné FS. Ale vidím, že stále nie.

[Andrej]

Do budúcnosti ma zaujalo či náhodou BTRFS nechce dohnať ostatné moderné FS. Ale vidím, že stále nie.

Které? Prosím konkrétní seznam. Tohle je fakt hloupý FUD.

Ten seznam "moderních" filesystémů nebude; tobych se vsadil. :-P Jsem na něj opravdu zvědavý.

To pole malo stále dostatok zariadení na zrkadlenie dát. Zlikvidoval som mu len dva zo štyroch LUNov. A aj napriek tomu to vyriešilo východzím profilom. Toto je krásne prekvapenie.

No, jak jsi na tom s takovými těmi počty? Myslím jako první třída a tak…?

Takže: Máš profil raid1c3, jo? Co znamená c3? Tři kopie.

Když ze 4 zařízení odstraníš 2, kolik zařízení tam zbude? Že by dvě? Takže, jak přesně na dvou zařízeních vytvoříš tři kopie dat?! Zázrakem?

Jasně, mohl bys chtít, aby jen tak najednou na některém z toho nedostatečného počtu zařízení vznikl profil dup, sám od sebe. To by bylo zajímavé. Který jiný filesystém tohle má? (Hint: Žádný. Dvojí metr. Už zase.)

[Peter Golis]

Vytvorím si SW RAID nad štyrmi diskami, tak aby som mal tri kópie a jeden rezervný disk. Z toho mi prestanú fungovať dva disky, ale stále mi to zapisuje na dve kópie. Takže redundanciu mi to zachovalo.

V prípade BTRFS sa to celé zablokuje. A ak chce človek sprístupniť podobné pole v podobnej situácii podobne na zápis, tak sa mu vypne redundancia a zapisuje to len v profile Single. Čiže, stratí redundanciu aj keď ju mohlo použiť keďže tam boli stále dva plne funkčné disky.

[Heron]

Do budúcnosti ma zaujalo či náhodou BTRFS nechce dohnať ostatné moderné FS. Ale vidím, že stále nie.

Které? Prosím konkrétní seznam. Tohle je fakt hloupý FUD.

Vytvorím si SW RAID nad štyrmi diskami

SW RAID je FS? Zajímavé.

Jako tahle diskuse už je čistej trollismus.

V prípade BTRFS sa to celé zablokuje.

On vám někdo zakázal ten BTRFS vytvořit nad tím SW RAIDem se čtyřmi disky? Jako pokud nevěříte multidevice vlastnostem btrfs, tak si jej vytvořte nad polem a budete mít stále věci jako atomické snapshoty apod.

[Peter Golis]

On je to vôbec trolling tvrdiť že BTRFS má v sebe funkcionalitu redundantného poľa, keď pri najmenšom náznaku výpadku tú redundanciu zahadzuje.

[j]

To by me zajimalo, jak ti 3 disky na R1 nad btrfs pomuzou k tomu, aby byla splnena podminka, ze jsou stale vsechna data na nejmin 2 discich? Zeby presne nijak? Btrfs si totiz ta data pres ty disky rozhaze vicemene random, a tudiz kdyz ti jeden z disku chcipne, tak proste cast dat prijde o tu druhou kopii.

Pro predstavu, mejme 3 disky

1 ; 1 ; 0
0 ; 1 ; 1
1 ; 0 ; 1

Presne takhle to funguje, jinak receno, tretim diskem se zvedne celkova kapacita toho raidu. Kdyz chcipne ten treti disk, tak sem prisel o 2/3 duplikatu. Takze na tom nejsem o moc lip, nez kdyz mi chcipne jeden ze dvou disku.

Je totiz uplne jedno kolik tech disku bude, ve 100% po selhani disku dojde je ztrate duplicity. A je dokonce i uplne jedno, jestli budes prouzivat ten tripl/quadro raid, protoze tam plati presne totez, jakmile selze disk, uz to neni pozadovany raid.

---

Dete s tim guuglem dopice!

[Heron]

Tím, že je to stále platný raid1 a může dál zapisovat ve zvoleném profilu. Další data půjdou na ty dva disky, tj redundance je zachována a ty 2/3 se potom balancujou buď na ty dva stávající disky (proto je důležité mít volné místo) nebo na nové diskové zařízení. Jak prostě milý Watsone.

ve 100% po selhani disku dojde je ztrate duplicity

No to jistě, ale důležité je, že stále bude schopen zapisovat ve zvoleném profilu. Proto je důležité mít víc diskových zařízení a volné místo na výpadek požadovaného počtu disků. Mód raid1c3 je skvělý v tom, že po výpadku disku ta stávající data budou stále duplikována ve dvou kopiích. Tj tlak na rychlou výměnu vadného disku nebo rebalance je o to nižší. Pro úplné paranoiky je tady i raid1c4. Tj mít 6 disků, raid1c3 a máš super zabezpečená data a mnohem menší tlak na výmenu disku, než v případě libovolného jiného raid1e (dvě kopie). Je samozřejmně otázka, jestli u takto nízkého počtu disků není lepší použít raid6. To potom záleží na potřebě výkonu.

[j]

"Tím, že je to stále platný raid1 a může dál zapisovat ve zvoleném profilu."

Fakt? A ten prostor se vysublimuje z vakua? Nebo odkud se veme misto na ktery by se dalo zapsat, kdyz zmizi disk? Klidne muzes byt v situaci, kdy jeden z tech dvou zbyvajicich disku je 100% zaplnen. A zadny rebalance udelat nemuzes protoze nemas kam.

Na poctu disku vubec nezalezi, vysledek bude vzdy exaktne stejny.

---

Dete s tim guuglem dopice!

[Heron]

Možná kdybys přečetl víc než jen první větu...

Přibližně kolikrát je potřeba to napsat, než si toho někdo jako ty všimne?

(proto je důležité mít volné místo)

[Andrej]

Ako zadám daný parameter pri štarte OS keď sa jedná o /, a koľko bežných reštartov to vydrží bez servisného zásahu?

Používal jsi už někdy Linux? Příkazová řádka kernelu ti něco říká?

Už asi desetkrát je v tomhle vlákně zopakováno: Nastav si klidně flag degraded permanentně, rovnou v příkazové řádce kernelu i v /etc/fstab, pokud si myslíš, že se to takovým způsobem má chovat.

Kolik kilometrů dlouhého vedení máš ještě v zásobě?

Nejedná sa mi o magický oltár, okolo ktorého musí človek tancovať aby neupadol v nepriazeň osudu.

Pokud používáš Ext4 nebo jiné filesytémy navržené v minulém století, přesně u takového magického oltáře tancuješ a prosíš kvantová božstva, aby si z tvých dat neukousla příliš velké sousto.

[Peter Golis]

Ako zadám daný parameter pri štarte OS keď sa jedná o /, a koľko bežných reštartov to vydrží bez servisného zásahu?

Používal jsi už někdy Linux? Příkazová řádka kernelu ti něco říká?

Samozrejme že áno. Ale nerozumiem prečo by som mal v prípade použitia BTRFS vykonať zásah ktorý mi umožní aspoň čiastočne použiť to, čo je už desaťročia východzím chovaním u iných a bežnejších riešení.

Nejedná sa mi o magický oltár, okolo ktorého musí človek tancovať aby neupadol v nepriazeň osudu.

Pokud používáš Ext4 nebo jiné filesytémy navržené v minulém století, přesně u takového magického oltáře tancuješ a prosíš kvantová božstva, aby si z tvých dat neukousla příliš velké sousto.

Pokiaľ potrebujem zabezpečiť konzistenciu dát, tak nepoužijem čistý EXT4. Ale to som už spomínal.

[Andrej]

…čo je už desaťročia východzím chovaním u iných a bežnejších riešení.

Ne, není. Srovnáváš nesrovnatelné. To výchozí chování (celá desetiletí) bylo zhruba takové, že to naprosto nedefinovaně selhalo.

[Peter Golis]

Ako a čo zhruba nedefinovateľne zlyhalo?

[...]

Na btrfs.wiki.kernel.org se stále píše:

raid1 volumes only mountable once RW if degraded

Už před dlouhou dobou jsem tady v diskusi četl, že to snad už není pravda, ale TAM na kernel.org to mají pořád. A v minulosti jsem to zkoušel a pravda to rozhodně byla.

[Heron]

Není to pravda a já jsem se s tím za celou praxi s btrfs (od 2011) nikdy nesetkal. (Ale je klidně možné, že to bylo v některých verzích, které jsem přeskočil.)

I v rámci tohoto testu jsem to remountnul mnohokrát, stále rw. Jádro 5.7.

[...]

Pravda to je, resp. byla. Ověřeno osobně mnou a mnoha dalšími, dokonce se zde nad tím diskutovalo.

A kdyby sis to přečetl, což jsi evidentně neudělal, tak bys věděl, že se tam píše o kernelech 4.9.x, 4.4.x. Které jsou sice starší, ale stále používané. Kromě toho se tam mluví o btrfs raid1, což tvůj zmiňovaný pokus jaksi taky nebyl.

Takže ano, možná je to opraveno v nových kernelech, ale prostě mezi prostým lidem ta nedůvěra stále je, protože navíc to popsané chování nebyla chyba, ale feature...

[Andrej]

Pravda to je, resp. byla.

Celá tahle diskuse začíná být názorným přehledem toho, jak vzniká (a jak se udržuje při životě) nesmyslný FUD.

[Jendа]

Ne, tahle diskuze ukazuje, že FS je především o důvěře. Už mnoho let tu lidem cpeš do hlavy, že btrfs už je stabilní a nemusí se bát ho používat -- a ti, co to opravdu udělají, zjistí, že neexistuje fsck (<=2014?), nebo že „RAID1“ má počítadlo a degradovaný lze read-write připojit jednou (<=2018). Jistě, uvedené problémy jsou již opraveny, ale naprosto očekávaný strach lidí je „když ve stabilním FS bylo tohle, tak co za další překvapení nás tam ještě čeká“.

[Jendа]

Jo, nebo třeba rozbití FS když dojde místo (2013), jak užitečně dodává lertimir.

[Andrej]

Jinými slovy, opět 0 argumentů. Proč máš stále potřebu hájit fosilní souborové systémy? Cui prodest?

Tahle polopravda z minulosti už dnes neplatí. Kromě toho, který máme rok? 2013?

[Heron]

a ti, co to opravdu udělají

Já už to opravdu dělám od roku 2011 a fsck jsem nikdy nepotřeboval, na vlastnost raid1 jsem nikdy nenarazil a tak dále.

Z BTRFS se prostě stal jen otloukánek v diskusích. Nic víc. Ano, má svoje chyby, stejně jako jakýkoliv jiný software. Ale zatímco u ostatního to lidi tak nějak tiše ignorují (nebo ani nezaznamenají), tak na btrfs je potřeba si pořádně došlápnout. A to i v případech, kdy za to fs vůbec nemůže (viz případy potíží s lvm, nebo mdraidem, za které podle tazatelů může FS).

Vůbec nejzábavnější jsou hate typu: když tam mám sto tisíc snapshotů, tak je to pomalé. Ok fajn, tak mi udělej sto tisíc snapshotů na ext4 a potom přijď (tj kategorie nikdo jiný to sice neumí, ale budu to pro jistotu hejtit taky).

když ve stabilním FS bylo tohle

Mám asi milion historek tohoto typu. Víš, kdy jsem naposledy* přišel o FS (nikoliv o data, ta jsou na zálohách)? Byla to kombinace "vlastností" mdadm a systemd. Disky jsem měl na HBA, který začal zlobit. Náhodně je odpojoval a připojoval. mdraid má tebou opěvovanou vlastnost, že disk po objevení znovu připojí do pole a podle bitmapy začne syncovat. Takhle postupně vypadly asi 4 disky ze 6 (RAID10). Ano, jednoznačně chyba HW. Dal jsem to na jinej řadič, mdadm pole nesložilo. Tak jsem si s tím chtěl pohrát, složil jsem pole (--force). Systemd nenapadlo nic lepšího, než device, na které tou dobou už několik hodin čekal, přimountovat, pochopitelně rw. To byl poslední hřebíček do rakve. Chtěl jsem udělat ro check, chtěl jsem se na to podívat apod. Ne, "vlastnost" systemd mi to zhatila.

A takových případů mám hodně. Takže jestli se někdo pos*re z toho, že fs mu jde připojit jen RO (s tím, že všechna data má v pořádku), tak s prominutím v IT nic nezažil.

*) Ve skutečnosti to byl jediný případ za posledních 10+let.

[Jendа]

mdraid má tebou opěvovanou vlastnost, že disk po objevení znovu připojí do pole a podle bitmapy začne syncovat

Ty jo, já mám pocit, že pole bylo potřeba znovu sestavit (nebo device do běžícího pole ručně přidat), aby začal resync, což se typicky stane po rebootu (nebo samozřejmě ručním zásahu). Nedělá tvé systemd kromě automatického mountování (lol) i nějaké pokusy s automatickým přidáváním disků do pole?

Takže jestli se někdo pos*re z toho, že fs mu jde připojit jen RO (s tím, že všechna data má v pořádku), tak s prominutím v IT nic nezažil.

Já se z toho „neposral“, jenom to snižuje dostupnost, přidělává opruz a práci.

[Heron]

pole bylo potřeba znovu sestavit

No jistě. mdadm jej automaticky nesestavil, musel jsem mu pomoct.

Nedělá tvé systemd

To není mé systemd. Systemd zkrátka čeká až se objeví device, které se má připojit. event driven. Když o tom člověk ví, tak to není zase tak nelogické. Ale je potřeba pamatovat na zastavení té automaticky vygenerové unity z fstabu. Problém je, že to nastalo během divokého přechodu na systemd a nikdo na tyto zvláštnosti neupozorňoval. (Což je opět pikantní, já jako systemd hater jsem si nejdřív musel napsat články a potom si je přečíst, abych se o systemd něco dozvěděl. Ti systemd loveři jaksi nic nepsali.)

Poznámka na okraj, já už do fstabu žádné další fs nedávám. Cokoliv nad rámec rootfs si píšu rovnou jako mount a automount unity. Stejně jako už nepoužívám cron a na všechno si píšu timery.

[trekker.dk]

Z BTRFS se prostě stal jen otloukánek v diskusích. Nic víc.

Za což ovšem z velké části mohou lidi, co jej doporučovali, i když pro nasazení ještě vhodný nebyl.

Vůbec nejzábavnější jsou hate typu: když tam mám sto tisíc snapshotů, tak je to pomalé.

Pokud ten dotyčný dostal od Andreje-like člověka radu "použij btrfs" a nefunguje to, tak je to vcelku oprávněná stížnost.

[Andrej]

Ne, tahle diskuze ukazuje, že FS je především o důvěře.

Tak jak je potom možné, že dnes ještě někdo používá Ext4 a podobné "skvosty"?

Kromě toho, co je to ta důvěra? Jsou to nějaká přesná data z většího testování? Nebo jsou to dobře zdokumentované algoritmy podpořené náležitými matematickými základy? Nebo jsou to jenom dojmy, anekdoty a plácání prázdné slámy?

Celá tahle debata nakonec není o důvěře, nýbrž o nesmyslném dvojím metru, který se na moderní filesystémy aplikuje.

Už mnoho let tu lidem cpeš do hlavy, že btrfs už je stabilní a nemusí se bát ho používat

Opět jsi nepochopil, co tvrdím. Já necpu lidem do hlavy, že se Btrfs nemusí bát používat, nýbrž že se Btrfs mají bát nepoužívat. To je dost podstatný rozdíl.

A ano, už mnoho let mám pravdu; co se dá dělat.

zjistí, že neexistuje fsck (<=2014?)

No a? Samozřejmě, že u moderního filesystému typu ZFS nebo Btrfs nemá existovat fosilní nesmysl typu FSCK.

Není nijak překvapivé, že ani ZFS žádný FSCK nemá. (Přesto kolem něj existuje méně FUDu než kolem Btrfs, kupodivu.) Kde se asi tahle absence FSCK vzala? Že by snad experti na filesystémy, kteří vytvořili Btrfs a ZFS, netušili, co dělají, a potřebovali by poradit od chytrolínů na ABCLinuxu?

Pravda, pro Btrfs pár utilit na způsob FSCK (které jsem už zmiňoval) vzniklo. Nejspíš aby už chytrolíni drželi zobáky a aby mohli tu a tam dostat svá data z disků tak zbořených, že by to většina jiných filesystémů neustála — jenže dvojí metr praví, že Btrfs to přece ustát musí.

Rozpor v pseudoargumentech kolem FSCK je celkem zjevný:

• Na jedné straně se má ten moderní filesystém přece vždycky sám opravit a automaticky namountovat read/write, stůj co stůj — proto je přece moderní a redundantní, ne?
• Na druhé straně má pro ten filesystém existovat FSCK — a s ním tedy nejspíš i nějaký typický use case pro FSCK, známý z nežurnálovacích systémů pradávné minulosti.

Takže, co z toho^^^ platí? Jestli obojí naráz, tak který filesystém to obojí splňuje, jen tak pro zajímavost a pro srovnání?

Jistě, uvedené problémy jsou již opraveny, ale naprosto očekávaný strach lidí je „když ve stabilním FS bylo tohle, tak co za další překvapení nás tam ještě čeká“.

Proč se ten očekávaný strach nevztahuje na "stabilní" Ext4, který má každé 3 roky své (už skoro) tradiční bugy se ztrátou dat? Poslední dobrodružství se konalo v roce 2018, takže další je asi plánované na rok 2021, předpokládám…

Proč tomu očekávanému strachu nevadí, když data nejsou checksumovaná ani redundantní?

Proč ten očekávaný strach nekřičí, že nemá copy-on-write a atomické snapshoty, že u spousty use case dochází ke zbytečnému fyzickému kopírování víc dat, než by bylo potřeba, což by tolik nevadilo, kdyby data byla checksumovaná … jenže …

A takhle by se dalo pokračovat ještě dlouho.

[Jendа]

a fsck jsem nikdy nepotřeboval

No a? Samozřejmě, že u moderního filesystému typu ZFS nebo Btrfs nemá existovat fosilní nesmysl typu FSCK.

A jak tedy zjistíte, že datové struktury FS přestaly být validní? A ještě lépe, jak je opravíte? (pak je samozřejmě k diskuzi, jestli by se při jakémkoli poškození neměl celý FS zrušit a udělat znova; osobně si myslím, že pro nějaký drobný problém je to overkill když máte fsck který ověří že to je po opravě v pořádku, ale chápu že by bylo samozřejmě lepší to celé zkopírovat na čisto; ještě důležitější samozřejmě je zjistit, proč se chyba stala, ale to prostě často nejde -- jádro máte aktuální, pustíte přes noc memtest, nic nenajde, a co dál)

Kromě toho, co je to ta důvěra? Jsou to nějaká přesná data z většího testování? Nebo jsou to dobře zdokumentované algoritmy podpořené náležitými matematickými základy? Nebo jsou to jenom dojmy, anekdoty a plácání prázdné slámy?

Jsou to anekdoty, často bohužel osobně prožité. Já mám za sebou konkrétně

• degradovaný „RAID1“ lze rw připojit pouze jednou
• corrupt leaf a následně fsck rekurzivně smazal /
• vyrobil jsem soubor, jehož čtení vrátí I/O error, ale v dmesg nic není a scrub proběhne bez problému
• FS je ve stavu že při každém mountu je potřeba udělat zero log

(z důvodu nepoužití dvojího metru neuvádím problémy se snapshoty). To je asi tak o 4 zážitky víc než mám s ext4, navzdory tomu, že btrfs používám o dost méně.

Na jedné straně se má ten moderní filesystém přece vždycky sám opravit a automaticky namountovat read/write, stůj co stůj

To překrucuješ schválně, nebo fakt nečteš pozorně?

Proč se ten očekávaný strach nevztahuje na "stabilní" Ext4, který má každé 3 roky své (už skoro) tradiční bugy se ztrátou dat?

Ještě záleží na tom, jak složité je na ten bug narazit.

Proč tomu očekávanému strachu nevadí, když data nejsou checksumovaná ani redundantní?

Vadí, ale pokud si má vybrat mezi FS s checksumovanými daty ale historií podivných problémů a FS který nemá ani jedno (přičemž checksumuje disk, což je samozřejmě blackbox a kdo ví jaké jsou tam chyby, a redundanci dělá MD, což je naopak v pohodě), tak bere to druhé. btrfs ale furt zkouším a i na některých místech používám, a opravdu musím říct, že se problémy v posledních pár letech výrazně vyřešily. Ještě pár dalších let a třeba mu zase začnu věřit ;).

Proč ten očekávaný strach nekřičí, že nemá copy-on-write a atomické snapshoty

Křičí, a občas se mi stane, že si omylem něco smažu, a musím se vracet třeba k denní záloze, zatímco 5minutové snapshoty držené hodinu zpátky by byly super a snapshoty jsou hlavní důvod, proč btrfs chci.

že u spousty use case dochází ke zbytečnému fyzickému kopírování víc dat, než by bylo potřeba

Mám pocit, že tohle se u mě děje jenom když si chci něco zkusit s nějakým velkým souborem, kde by bylo vhodnější vytvořit snapshot než ho celý kopírovat.

[Andrej]

Na zjišťování problémů a automatickou opravu je scrub.

Může se zdát podivné, že připomíná "FSCK v kernelu", nicméně je to celkem v souladu s ideou, že systém má mít co nejdéle uptime a co nejméně důvodů být v neobvyklém offline režimu, kdy běží FSCK na odmountovaných discích a nic jiného se nedá dělat.

Kromě toho mělo kdysi dávno smysl mít FSCK mimo kernel kvůli velikosti příslušného kódu. To ale při dnešních velikostech RAM (a při nápadech typu deduplikace na ZFS) nemá až tak valný smysl, což je jeden z těch mnoha důvodů přechodu od FSCK ke scrubu.

Dlužno taky dodat, že scrub trvá (obecně) mnohem déle než FSCK (bereme-li třeba Ext4 za vzor, jak dlouho má trvat FSCK), protože u Ext4 nejsou žádné checksumy dat ke kontrole. Proto je lepší, když se dá se systémem (aspoň omezeně) pracovat během scrubu.

Případný oddělený FSCK pro Btrfs by taky znamenal, že by se musel na dvou místech udržovat kód, který by dělal něco velmi podobného, jen v jiném prostředí, s jinými požadavky na synchronizaci atd. Což nemusí být zrovna nejlepší využití času vývojářů.

…ale historií podivných problémů…

Otázka je, co z toho je skutečná historie Btrfs a co souvisí spíš s faktory mimo ten souborový systém.

Některé anekdoty mi (vzdáleně) připomínají začátky PulseAudio. V prvních 5 letech jeho existence jsem PulseAudio vyhazoval, jak jen to šlo, všechno buildil bez něj atd. Důvod byl ten, že to na žádném mém stroji nefungovalo. Nejčastěji zvuk nebyl vůbec. Nebo neexistovala možnost zároveň nahrávat a přehrávat, tedy mít normální online hovor. Nebo se místo očekávaného zvuku ozvalo něco divného, jako by si to rozdávali roboti.

Když se na to dívám zpětně, skoro nic z toho nebyly chyby v PluseAudio (byť něco málo možná jo). Jak se později ukázalo, vyplul zkrátka na povrch nepříjemný počet dlouho skrytých bugů v ALSA driverech všeho druhu.

Dnes mi PulseAudio funguje skvěle. Přes Bluetooth umí aptX. Přehrává mi všechno lokálně i po síti. Neumím si bez něj desktop představit.

Těžko říct, podobně na tom může být některý hardware (v anekdotách často zmiňovaný), který třeba s Ext4 "funguje" (v tom smyslu, že se na první pohled nic překvapivého neděje), zatímco s Btrfs to třeba najednou začne odlétat na některý z checksumů, které nesedí vlivem bitflipu v paměti.

To^^^ je samozřejmě znepokojivé a nepříjemné, ale nepřipadá mi to jako důvod nedůvěřovat Btrfs a důvěřovat tomu jinému filesystému. Rozumné dlouhodobé řešení podle mě netkví v tom, že se problém bude ignorovat a/nebo používat takový filesystém, který ho ignoruje.

Konkrétně tento nepříjemný zážitek s Btrfs jsem měl taky:

• FS je ve stavu že při každém mountu je potřeba udělat zero log

Bylo to v roce 2012. Chtěl jsem Btrfs RAID 5, jenže co s tím, když tenkrát žádný neexistoval. Disků bylo 5 a asi jsem na ně měl dát RAID 1 (v tom smyslu, v jakém ho definuje Btrfs), jenže i tuhle variantu jsem zavrhnul. (Přece nebudu mít jenom polovinu místa, blablabla, atd.)

Inu, udělal jsem tedy to, co se dělat nemělo a co návody velmi výslovně nedoporučovaly: mdadm AID 5 a na tom Btrfs. Problém s tím byl hlavně proto, že tahle kombinace měla nějaký notoricky známý problém se synchronizací; Btrfs prostě nebyl na tenhle režim provozu navržený a měl mít vlastní RAID. (Taky v Btrfs není žádný optimalizační hint jako stride a stripe width; prostě to nad softwarovým AIDem být nemá.)

Asi 2 měsíce to takhle běželo, jenže potom, po nějakém divném restartu, resilveringu toho mdadm a kdesičemsi dalším začala dlouho trvající otrava s btrfs-zero-log (což je dnes btrfs rescue zero-log; tenkrát to byla samostatná binárka). Sice ne při každém mountu, ale asi tak při každém pátém jo.

Celkově to rozhodně nebyla příjemná zkušenost, to ani náhodou, nicméně nenapadlo by mě vinit z důsledků takového experimentu Btrfs a/nebo usuzovat na základě toho cokoliv ohledně fungování Btrfs dnes.

[Heron]

Některé anekdoty mi (vzdáleně) připomínají začátky PulseAudio.

Totéž v bledě modrém se stalo při vývoji ZFS, kdy se postupně zjišťovalo, že některé disky lžou o provedení flush cache apod. Je celkem záhadou, že se na to nepřišlo už třeba při lvm bariérách, ale tak multidevice fs jsou mnohem náchylnější na to, co všechno se ne/zapíše na jednotlivé device.

Nebo experimenty mého kámoše s nvme diskem (Intel 600p NVMe), kdy mu to bořilo XFS. Prozkoumali to borci z RH a našli další bugy v HW.

[k3dAR]

a muzes se pls vyjadrit k? s tim diskem sem od te doby nic nedelal, muzu na nem provest nejakou diagnostiku pokud me nasmerujes

[Andrej]

V podstatě nemůžu; fakt netuším, co se tam mohlo stát. Určitě se na tom dají donekonečna zkoušet různé tooly pro obnovu, ale pokud se to (na příslušném disku / řadiči / hardwaru / kernelu) dál samo od sebe posírá, těžko říct, co s tím. Sám jsem takovou situaci nezažil. Kdyby jo, asi bych zkoušel postupně vyloučit možné příčiny, než by mi došla trpělivost a nahradil bych asi tak všechen hardware kolem toho.

[k3dAR]

neopakuje se to, stalo se to 1x hned po vytvoreni, pridani subvolumes, jejich pripojeni, nahrani dat, prejmenovani nadrazeneho dir s subvolumes, nasledne to opravil: "btrfs check --repair ..." pak uz sem to dal nepouzival (takze opakovani problemu nevylucuju), jde mi o to zda sem neco udelal spatne (to prejmenovani) nebo zda jde jeste neco zpetne zjistit toolama (v logu nic nebylo), HW je OK, pretim na tom disku byl ext4 a zadne problemy nebyli (nic v logu, smart, virtualy startovali, iso sem kontroloval ze soucet sedel), v tom HW mam druhej 3TB totoznej disk s mdadm(degraded raid1)/lvm/ext4 kterej je pouzivan, slo mi o myslenku prejit z mdadm+ext4 na btrfs raid1 na obou, pokud se to na 1 osvedci...

[Andrej]

Na přejmenování subvolume nic špatného nevidím. U nějakých snapshotů jsem je párkrát přejmenoval klidně skriptem po desítkách a nikdy jsem s tím neměl problém.

Jinak fakt nevím, co tam může být špatně. (Možnost zpětně to zjistit by byla velmi pěkná feature, ale obávám se, že to by mohlo jít jedině na nějakém striktně log-structured filesystému (a to ještě kdoví jestli).)

[k3dAR]

neprejmenovaval(uplne puvodne sem to spatne popsal) sem subvolume, ale nadrazenej adresar:

/.subvolumes(adresar)/{data,fotky,neco}(vse subvolume)

na

/.subvols(adresar)/{data,fotky,neco}(vse subvolume)

kdyz se to chovalo divne, prejmenoval zpatky...

[LarryL]

Budu střílet úplně od boku. Jestli jsi to zkoušel na notebooku, nemohlo to souviset s TLC bugem. Píše se o tom i na Arch Wiki v Known_issues

[LarryL]

... za "TLC bugem" měl být otazník.

[k3dAR]

nn, nebylo to na NB jedouciho na BAT, ale stolni PC

[Heron]

Problém je, že tento popis neobsahuje žádné podrobnosti. A upřímně řečeno je z toho patrno, že moc nevíš o čem mluvíš. "Přidání" subvolumes, jejich "připojení" apod. Subvolumes se vytvářejí prostě jako adresáře. Není potřeba je nikam připojovat (i když je to samozřejmě možné). Prostě z hlediska userspace jsou to jen adresáře s výhodami. (Tak to používám já, cd projekty; btrfs sub create další_projekt; práce; btrfs sub snap co kam.) Lze přejmenovávat cokoliv. Jak subvolumes, tak libovolnou část stromu. Nevíme, v jakém stavu (a proč) ten fs byl. Rozhodně je zvláštní hned na to pouštět repair, který se v manu uvádí až jako poslední možnost.

Prostě celá tato historka by se dala shrnout: udělal jsem něco nevím co, opravil jsem to nevím jak a dál už jsem to nepoužíval. Ergo, btrfs je nahovno.

[k3dAR]

divas se na to ve spatnem uhlu, me neslo o to dokazat ze je btrfs nahovno, me slo o to pochopit co se mohlo stat, jestli sem to zpusobil ja a jak tomu predchazet, abych naopak mohl na btrfs prejit... to ze popis neni presnej/podrobnej chapu, i to ze nevim o cem mluvim, jinach bych se neptal... nepatrne presnejsi popis sem psal vejs, tedy kroky ktere sem udelal...

[Heron]

Ok, jenže na odpověď je docela málo dat. Z popisovaných operací jsi neudělal nic špatně, ale nevíme, co se dělo okolo a jestli je to celé.

Ještě mě napadlo, že jsi to přejmenovával, když to bylo namountované, tak jsem to vyzkoušel:

Výchozí stav. yyy je obyč addr, aaa je subvol

# btrfs sub list .
ID 260 gen 56379 top level 5 path g2
ID 292 gen 56397 top level 5 path yyy/aaa

Namountujeme:

# mount /dev/disk /mnt -o subvol=yyy/aaa

Výpis mount:

/dev/disk on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=292,subvol=/yyy/aaa)

Přejmenujeme:

# mv yyy zzz

A výpis mount se změní:

/dev/disk on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=292,subvol=/zzz/aaa)

Tj i pro namountovanou subvolume můžeme přejmenovat její cestu.

Nebo i tu subvolume samotnou (což mě teda překvapilo, ale on to referencuje podle ID nikoliv podle jména zadaného při mountu):

# mv aaa bbb

/dev/disk on /mnt type btrfs (rw,relatime,ssd,space_cache,subvolid=292,subvol=/zzz/bbb)

Tj přejmenováním to fakt nebylo.

[trekker.dk]

Otázka je, co z toho je skutečná historie Btrfs a co souvisí spíš s faktory mimo ten souborový systém.

Takže ext4 ztrácí data, zatímco když btrfs udělá chybu, tak je to faktor mimo souborový systém. Nechtěl jste přestat s tím dvojím metrem?

nicméně nenapadlo by mě vinit z důsledků takového experimentu Btrfs

Ano, protože Btrfs je pro vás svatá kráva. Filesystém, který "musí být navržený" na to, aby fungoval nad SW RAID5, je chybný. Z jeho pohledu to má být blokové zařízení jako každé jiné.

[Andrej]

Takže ext4 ztrácí data…

Ano. Ve slavných letech 2009, 2012, 2015 i 2018 ztrácel data přímo vlivem bugů (ať už přímo v Ext4 nebo v interakci s VFS).

O tom, jaká je tady souvislost s nespolehlivými úložišti a silent data corruption, už bylo taktéž napsáno dost. Ext4 tiše toleruje chyby, jejich pravděpodobnost je technicky možné výrazně snížit (z pravděpodobnosti, že se stanou, na pravděpodobnost, že se stanou, krát pravděpodobnost kolize hashů).

…zatímco když btrfs udělá chybu…

Dvojí metr spočívá nejčastěji v definici toho, kdy udělá chybu. Pokud běží na hardwaru, na kterém mu prostě tu a tam nesedí checksum, jen tak sám od sebe, není to chyba Btrfs.

Když Btrfs (opravdu) udělá chybu, jistě je dobré to zdokumentovat, nahlásit a opravit, stejně jako u kteréhokoliv jiného softwaru. Tvrdil tu snad někdo opak?

Filesystém, který "musí být navržený" na to, aby fungoval nad SW RAID5, je chybný. Z jeho pohledu to má být blokové zařízení jako každé jiné.

Aha. No jasně. Podle některé je ten svět tak krásně jednoduchoučký… Málem by jim člověk tu představu záviděl.

[trekker.dk]

Ve slavných letech 2009, 2012, 2015 i 2018 ztrácel data přímo vlivem bugů (ať už přímo v Ext4 nebo v interakci s VFS).

l.ž.e.t.e.

Podle některé je ten svět tak krásně jednoduchoučký...

Ono je to tak jednoduchoučké. Blokové zařízení je blokové zařízení. Uložím tam data, dostanu odtud data. Pokud filesystém dělá nějaké ptákoviny, které dokážou způsobit problém, je blbě navržený

[Andrej]

Ve slavných letech 2009, 2012, 2015 i 2018 ztrácel data přímo vlivem bugů (ať už přímo v Ext4 nebo v interakci s VFS).

l.ž.e.t.e.

Pravil šiřitel lží a FUDů. Výborně.

Podle některé je ten svět tak krásně jednoduchoučký...

Ono je to tak jednoduchoučké. Blokové zařízení je blokové zařízení. Uložím tam data, dostanu odtud data.

Jo? Opravdu? A co když ne? Co když bude v každém TB jeden bit jinak? Vadí to? Někdy jo, někdy ne. Je lepší nemuset o takových věcech vůbec uvažovat.

Pokud filesystém dělá nějaké ptákoviny, které dokážou způsobit problém, je blbě navržený

Tady^^^ je ale najednou řeč o Ext4, že? Ano, pokud filesystém dělá nějaké ptákoviny — což jsou například nechecksumovaná data nebo naprostá absence jakékoliv redundance —, je blbě navržený.

Pravda, není fair Ext4 tolik kritizovat; návrh Ext4 je zkrátka poplatný své době a je prostou evolucí něčeho, co pochází z dob 1-gigabytových disků a 1-diskových počítačů. (Do roku 2020 tedy rozhodně nepatří.)

[trekker.dk]

Pravil šiřitel lží a FUDů

Ano, lží a FUDů jste tu pravil hodně.

Co když bude v každém TB jeden bit jinak? Vadí to? Někdy jo, někdy ne.

Kdyby se mi to stalo, asi by mi to vadilo.

Tady^^^ je ale najednou řeč o Ext4, že?

Ne, ext4 nemá s provozem nad RAID5 žádný problém. Příště čtěte pozorněji

[LarryL]

Kdyby se mi to stalo...

A dá se to trvdit s jistotou když ext4 nemá checksum? Nikdy jsem nedostal chybovou hlášku, že mi v RAM přeskočil bit, ale jelikož nemám ECC paměti, tak předpokládám, že se to statisticky už mockrát stalo.

[trekker.dk]

Pokud bude chyba v metadatech (která mj. ext4 checksumuje), ten filesystém bude nabořený. Pokud bude chyba v datech, na příslušném dokumentu se to s docela velkou pravděpodobností pozná. Dtto. s tou pamětí, něco nejspíš spadne

[LarryL]

Pokud bude chyba v datech, na příslušném dokumentu se to s docela velkou pravděpodobností pozná.

Ano, měl jsem na mysli v datech, které ext4 nechecksumuje. Pokud se změní bit v dokumentu, tak to může poznat SW, který dokument otevírá a sám si to "opraví" (pokud to vůbec bude považovat za chybu), ale uživatel (ty) se to dozvědět nemusí. Příklad: Když z HTML dokumentu odebereš koncový tag "body" nebo "html" (což je hóóódně odebraných bitů), tak to nepoznáš. Proto se ptám kde bereš jistotu, že jsi neměl nějaký bit na ext4 jinak.

Dtto. s tou pamětí, něco nejspíš spadne

To si nemyslím. Kdysi jsem četl, že se to může v editoru obrázku projevit jen tím, že ti přeskočí pixel v obrázku a to jako uživatel taky zřejmě nepoznáš.

[Andrej]

Pokud bude chyba v metadatech (která mj. ext4 checksumuje), ten filesystém bude nabořený.

Z čeho přesně vyplývá tahle^^^ implikace? To je nějaký nesmysl z hororového světa Ext4. Pro Btrfs nic takového neplatí.

Pokud budou metadata na jednom disku v profilu dup, opraví se prostě z druhé repliky, pokud druhé replice sedí checksumy. Život jde dál.

Pokud má filesystém replikaci přes víc disků, což může snadno mít, opraví se metadata z některé z ostatních kopií, kde sedí checksumy.

Pokud má filesystém paritu přes víc disků, dopočtou se metadata z té parity a z těch bloků ve stripu, ve kterých sedí checksumy.

Pokud je filesystém béčko typu Ext4 … ano, jedině pak bude nabořený a nic se neopraví.

Pokud bude chyba v datech, na příslušném dokumentu se to s docela velkou pravděpodobností pozná.

Jo, jasně. A dokument se pak manuálně obnoví ze záloh, že? Vtipné je, že přesně tohle mi jednou tvrdil týpek, který zálohoval pomocí rsync -ac a nechápal, proč je to -c špatně. Situace se pak jmenuje "v datech seno —> v zálohách seno".

[trekker.dk]

Z čeho přesně vyplývá tahle^^^ implikace? To je nějaký nesmysl z hororového světa Ext4. Pro Btrfs nic takového neplatí.

Ale platí, rozdíl je jen ve způsobu opravy.

[Andrej]

Rozdíl je v samotné možnosti opravy spíš než ve způsobu opravy.

Na neredundantním Ext4 bez checksumů se nic neopraví.

[trekker.dk]

Rozdíl je v samotné možnosti opravy

Ne, není, oba systémy mají metodu, jakým takovou chybu opravit.

[Andrej]

Prdlajs.

mdadm/dmraid + Ext4 [voser už sám o sobě] prostě nikdy nic neopraví. Posere se.

Jo, na tu zázračnou "metodu" jsem zvědavý. Tak, kdepak je ta metoda, bez checksumů každého bloku??? No jasně. Nikde.

[trekker.dk]

mdadm/dmraid + Ext4 [voser už sám o sobě] prostě nikdy nic neopraví. Posere se.

Musíte použít správný nástroj. Fsck se to jmenuje.

[Andrej]

Kdyby se mi to stalo, asi by mi to vadilo.

A zase ta tupá pseudologika ve stylu nebudu mít airbagy ani bezpečnostní pásy — autonehody se přece nedějí. A kdyby se nehoda stala? Jo, kdyby se mi to stalo, asi by mi to vadilo.

Odkudpak se s ubohým Ext4 bez checksumů dat může vzít jistota, že tam není silent data corruption?

Hlavně pokud někdo dál používá rozbitý hardware, na kterém Btrfs prý kdysi "selhal" (tedy ve skutečnosti fungoval, jak měl, a hlásil chyby checksumů), je víc než pravděpodobné, že už má ve svých datech seno a slámu.

Ne, ext4 nemá s provozem nad RAID5 žádný problém.

No ovšemže ne, protože nic takového jako RAID 5 s Ext4 neexistuje. Tedy Ext4 s tím nemá problém v tom smyslu, že něco takového jako RAID 5 vůbec neumí.

Ext4 může běžet nad AID 5 — a to je tedy vskutku výhra! (Poškození kteréhokoliv jednoho disku zničí všechna data. (Důvod, proč to mu tak je, se tady už řešil tisíckrát — resilvering bez checksumů je horší zlo než absence celého AIDu.)) Nechápu, proč někdo stále lpí na takových nebezpečných fosiliích. Nemá to smysl.

Nejblíž k RAID 5 se Ext4 dostane v kombinaci s dm-integrity, no nicméně jde o hodně velký voser, pokud jde o výkon, o celkovou složitost konfigurace z hlediska uživatele i o flexibilitu výsledného pole (přidávání / odebírání zařízení atd).

Zkrátka a jednoduše: Kdo chce RAID 5, potřebuje Btrfs nebo ZFS. (Jenom to některým docvakne dřív a některým později.)

[trekker.dk]

Tedy Ext4 s tím nemá problém v tom smyslu, že něco takového jako RAID 5 vůbec neumí.

Stačí si přečíst dokumentaci, zjistíte, že zcela bez problémů.

Poškození kteréhokoliv jednoho disku zničí všechna data

A možná i wikipedii na téma RAID

Kdo chce RAID 5, potřebuje Btrfs

A to nad SW RAIDem, což - vaše slova - návody velmi výslovně nedoporučovaly? Nebo se zabudovaným, který není doporučené používat?

[Andrej]

Poškození kteréhokoliv jednoho disku zničí všechna data

A možná i wikipedii na téma RAID

Tohle naivní nepochopení celého problému je velmi úsměvné. (Nebo by z něj běhal mráz po zádech, kdyby šlo o někoho v roli admina zodpovědného za moje data.)

Kdo chce RAID 5, potřebuje Btrfs

A to nad SW RAIDem, což - vaše slova - návody velmi výslovně nedoporučovaly? Nebo se zabudovaným, který není doporučené používat?

Jak přesně souvisí můj popis jakéhosi experimentu z roku 2012 s dlouhodobým ukládáním dat v roce 2020?

Každopádně, kdybych náhodou znova instaloval experimentální stroj, na jehož spolehlivosti nezáleží (jako tenkrát), a kdyby byl rok 2012, klidně bych takové dočasné pseudo-řešení zvolil znova. Jo, tenkrát před 8+ lety, kdy ZoL v rozumné podobě neexistoval a kdy Btrfs neměl RAID 5/6, byla spousta věcí komplikovanější než dnes.

V případě dat, na kterých mi dlouhodobě záleží, bych takovou habaďůru samozřejmě nedělal — stejně jako bych taková data nedal na Ext4 nebo na jiný neredundantní a nechecksumovaný FS.

[trekker.dk]

Tohle naivní nepochopení celého problému je velmi úsměvné.

Ano, je, ale i tak by bylo dobré, kdybyste se dovzdělal.

Jak přesně souvisí můj popis jakéhosi experimentu z roku 2012 s dlouhodobým ukládáním dat v roce 2020?

Tak, že v Btrfs byl zjevně nějaký problém při provozu nad SW RAID5 (což je mimo jiné opravdu hloupá chyba ze strany Btrfs), jakého překvapení se dočkáme příště?

[Andrej]

Tohle naivní nepochopení celého problému je velmi úsměvné.

Ano, je, ale i tak by bylo dobré, kdybyste se dovzdělal.

Nedovzdělanec povídá někomu, aby se dovzdělal. To jako fakt vážně? Ach jo. To snad ne. Jaký level hlouposti tady ještě nebyl pokořený???

Pokud někdo nechápe, proč AID 5 (nebo AID 6), na rozdíl od RAID5 nebo RAID6, pokaždé zničí všechna data kvůli selhání jednoho disku, tak ať třeba prostě drží zobák a jde něco dělat lopatou. Už je toho nechápání opravdu moc.

Jak přesně souvisí můj popis jakéhosi experimentu z roku 2012 s dlouhodobým ukládáním dat v roce 2020?

Tak, že v Btrfs byl zjevně nějaký problém při provozu nad SW RAID5 (což je mimo jiné opravdu hloupá chyba ze strany Btrfs), jakého překvapení se dočkáme příště?

Jakákoliv hypotetická chyba v Btrfs je pořád čajíček vůči data žeroucí sračce typu mdadm/dmraid + Ext4. Jakého průseru se dočkáme v roce 2021?

Citát dne, pro méně důvtipné, z jednoho z nejpesimističtějších hodnocení Btrfs RAID5: …btrfs raid5 is quantitatively more robust against data corruption than ext4+mdadm (which cannot self-repair corruption at all)…

FUDisti všech zemí, jděte už konečně do prdele. Víte prd o světě. Víte prd o filesystémech. Což by nikomu nevadilo — jenom kdybyste drželi zobáky a nechrchlali kolem sebe FUD o moderních filesystémech.

Upřímnou soustrast zaměstnavatelům takových lidí.

[Petr Fiedler]

Když si tak Andreji čtu ty tvoje dnešní arogantní a vulgární reakce a koukám na čas jejich odeslání. To jsi je jako psal po návratu z baru? Jestli ano, tak už to prosím tě nedělej. Btrfs se mi líbí a do budoucna jej určitě nasadím. Bylo velmi zajímavé sledovat celé vlákno. Ale číst tvoje urážky, to už nikoho moc neposune. Psal si přece, že to děláš kvůli druhým, ne? Jdi do sebe a místo urážek piš raději argumenty.

[trekker.dk]

Pokud někdo nechápe, proč AID 5 (nebo AID 6), na rozdíl od RAID5 nebo RAID6, pokaždé zničí všechna data kvůli selhání jednoho disku

Ne, nezničí. Zrovna nedávno jsem si to vyzkoušel, když jsem měnil disk. Data stále mám.

Jakákoliv hypotetická chyba v Btrfs je pořád čajíček vůči data žeroucí sračce typu mdadm/dmraid + Ext4.

Bez ohledu na to, kolikrát to budete opakovat, Ext4 data nežere.

btrfs raid5 is quantitatively more robust against data corruption than ext4+mdadm

Taky mám jednu citaci, je z letošního července:

RAID 5 and 6 have "lots of edge cases", though, and have been famously unreliable.

FUDisti všech zemí, jděte už konečně do prdele. Víte prd o světě. Víte prd o filesystémech.

Nesouhlas s vašimi názory neříká nic o tom, co ostatní ví o světě či filesystémech.

[Jendа]

Na zjišťování problémů a automatickou opravu je scrub.

To je jak do dubu. scrub nekontroluje validitu datových struktur, jen že se přečetlo to, co se zapsalo. #39. Další diskuze myslím nemá cenu, protože zjevně nevíš, jak btrfs funguje, a to ani po té, co to tu popíšu.

zatímco s Btrfs to třeba najednou začne odlétat na některý z checksumů

V případě 1 je scrub irelevantní, v případech 2-4 jsem ho udělal a prošel bez chyby. Checksumy tedy seděly.

Celkově to rozhodně nebyla příjemná zkušenost, to ani náhodou

Mně se to stalo s kernelem 4.9, takže někdy v roce 2017-2018. A problém není ani tak v tom, že se něco takového stane (kdyby se to jenom stalo, tak bych to považoval za chybu HW (desktop, non-ECC poměti), a ne za chybu btrfs!), problém je v tom, že se něco takového stane, a všechny dostupné nástroje na kontrolu filesystému (což je v případě btrfs bohužel jen ten scrub) potvrdí, že je ten filesystém v pořádku a ani při používání to nepíše do dmesg žádné chyby, umount korektně proběhne, a po rebootu se to stane znova. Kolik dalších skrytých chyb si neseme ve svých filesystémech, když jsem ten FS přistihl hned v několika případech, že o sobě tvrdí, že je OK, i když zjevně není?

[Andrej]

scrub nekontroluje validitu datových struktur

Teď mi přijde, že si jen tak tropíš žerty. Tohle myslíš vážně?

Drobný hint: Jakpak se scrub dozví, kde jsou data? Z jakých struktur asi? Nemusí si náhodou přečíst příslušná metadata? A nemusí je náhodou u toho taky zkontrolovat, jako ostatně při každé jiné diskové operaci?

scrub

An online filesystem checking tool. Reads all the data and metadata on the filesystem, and uses checksums and the duplicate copies from RAID storage to identify and repair any corrupt data.

Další diskuze myslím nemá cenu, protože zjevně nevíš, jak btrfs funguje, a to ani po té, co to tu popíšu.

Nápodobně. Zjevně netušíš, která bije. V každé diskusi o Btrfs přijdeš s mixem předsudků, anekdot z doby před pár lety a jednotvárným portfoliem stokrát vyvrácených pseudoargumentů. Cui prodest? Jak už jsem odpovídal někomu jinému ve vedlejším vlákně: Klidně používej FAT12, pokud ti to vyhovuje. Jenom mi nepřijde rozumné doporučovat podobné volby ostatním a šířit FUD o Btrfs.

Mně se to stalo s kernelem 4.9, takže někdy v roce 2017-2018. A problém není ani tak v tom, že se něco takového stane (kdyby se to jenom stalo, tak bych to považoval za chybu HW (desktop, non-ECC poměti), a ne za chybu btrfs!), problém je v tom, že se něco takového stane, a všechny dostupné nástroje na kontrolu filesystému (což je v případě btrfs bohužel jen ten scrub) potvrdí, že je ten filesystém v pořádku a ani při používání to nepíše do dmesg žádné chyby, umount korektně proběhne, a po rebootu se to stane znova.

Na tom samém hardwaru, kde předtím ta chyba vznikla? Jak překvapivé.

Kolik dalších skrytých chyb si neseme ve svých filesystémech, když jsem ten FS přistihl hned v několika případech, že o sobě tvrdí, že je OK, i když zjevně není?

Btrfs nemá křišťálovou kouli, aby mohl předvídat nečekané chování hardwaru a diagnostikovat původ každého kousku dat, který nesedí.

Nemůže to být třeba tak, že před bitflipem v RAM mu checksum sedí a po bitflipu ne? (Celou škálu jiných podobných chyb v řadičích, discích a kdovíčem všem si jistě dovedeš představit.) Pokud tam je takový problém, opravdu za něj může Btrfs?

Já bych v takové situaci Btrfs spíš poděkoval, že mě upozornil na problém s hardwarem, byť bohužel v křišťálové kouli nenašel odpověď, kde přesně problém je.

[Heron]

A jak tedy zjistíte, že datové struktury FS přestaly být validní?

Tím, že mají checksumy a jsou duplikované?

A ještě lépe, jak je opravíte?

Z těch kopií?

pak je samozřejmě k diskuzi, jestli by se při jakémkoli poškození neměl celý FS zrušit a udělat znova

Tohle je můj default mnoho let. Já nikdy netrávím večery nad fsck.xfs (ten má ale docela pěkný výstup) nebo u fsck.ext4. Pokud je to poškození závažné (tj jednak se to neopraví při mountu ani na jeden průchod fsck), tak automaticky jdou zálohy.

degradovaný „RAID1“ lze rw připojit pouze jednou

Stačí přidat disk. Je to jen nepříjemnost.

corrupt leaf a následně fsck rekurzivně smazal /

To naštve.

vyrobil jsem soubor, jehož čtení vrátí I/O error

Mě se na ZFS podařilo vyrobit několik souborů, které odmítal cachovat (ARC). Nevím jak, možná konkrétní verze FreeBSD. Po překopírování OK.

Jinak já jsem se s vadným BTRFS setkal pouze na nestandardním HW, který bych si sám nikdy nekoupil. A to na SSHD a potom na SSD s chybou NCQ TRIM. Na normálním obyč disku, který si na nic nehraje, to funguje ok.

Mám pocit, že tohle se u mě děje jenom když si chci něco zkusit s nějakým velkým souborem, kde by bylo vhodnější vytvořit snapshot než ho celý kopírovat.

Tohle fakt záleží na tom, co člověk dělá, ale já btrfs používám jako systém správy verzí pro velká data. Mám tady stovky GB velké balíky dat s několika desítkami verzí (snapshotů) a to bych na klasickém fs fakt dělat nechtěl (bylo by to prakticky nemožné).

[Jendа]

Tím, že mají checksumy a jsou duplikované?

Vzhledem k tomu, že nejsem sám, kdo narazil na chybu uvnitř bloku, kterému vyšel checksum, a mají o tom stránku na wiki, tak asi ne.

Já nikdy netrávím večery nad fsck.xfs (ten má ale docela pěkný výstup) nebo u fsck.ext4.

To není o trávení večerů, to je o takovém tom „inode blabla fix blabla OK“ co problikne při bootu, ani to nestačíš přečíst.

A to na SSHD a potom na SSD s chybou NCQ TRIM.

No ale tohle přesně přece má řešit ta posvátná kráva že ti to napíše „nesedí ti checksum, disk corruptí data, vyhoď to“, ne že se to náhodně rozbije.

[Heron]

To není o trávení večerů, to je o takovém tom „inode blabla fix blabla OK“ co problikne při bootu, ani to nestačíš přečíst.

Ehm. Prošel jsem si logy dva roky zpětně (ano, journald....) a žádné takové hlášky nikde nejsou. Hw, kde je potřeba fsck při bootu bych raději vyhodil.

ne že se to náhodně rozbije.

Tady se pohybujeme daleko za hranou toho, co by měl FS zvládat. Pokud mu disk lže o zápisu, náhodně nuluje bloky apod. tak se to může chovat fakt různě. Od oznámení chybného checksumu (pokud se to náhodou trefí do datového bloku) až po celkově divné chování. Jako tady bych od FS mnoho neočekával a naopak sypání náhodných chyb do logu by mělo admina vést k podezření na vadný HW.

[pavele]

Možná proto, že já mám na několika PC - měřících ústřednách - ext4. Před 15 lety jsem to spustil a od té doby to měří a funguje, přes různé tvrdé výpadky v síti. Jen proběhne fsck a jede to dál.

Nemám důvěru ke stabilnímu fs, který má velice zákeřné vlastnosti. Nechci testovat, chci používat.

Nemohu si dovolit používat včera zkompilovaný kernel a distribuci měnící se mi pod rukama kvůli fs. PC je pro mne pracovní nástroj. Před lety mi někdo nabídl KVM postavený na Fedoře na server - jenomže server má běžet mnoho let, pokud možno aktualizovaný a bez zásahu. Už i Debian to pochopil. Proto je u firem více podporováno Ubuntu, kvůli dlouhodobé podpoře. To samé se týká btrfs...

Když jsem před dvěma lety testoval btrfs na KVM, tak se mi to celé rozsypalo. Rada byla nepoužívat cow - jenomže kvůli tomu jsem to chtěl nasadit...Mě osobně nezajímají features, potřebuji stabilní a předvídatelný fs, který se mi nemění pod rukama v závislosti na čase.

Stejně jsem dopadl při testování opěvovaného glusterfs. Taky občas funguje...

[Jendа]

FYI před 15 lety jsi nemohl mít ext4.

přes různé tvrdé výpadky v síti. Jen proběhne fsck a jede to dál

Tak teda tohle by bylo fakt smutné kdyby nějaký FS neustál.

[Andrej]

Máš to rozbité a (zase) šíříš FUD.

Alebo som snáď urobil niekde chybu? Skús ma vyviesť z omylu, a ukázať ako BTRFS pole prežije výpadok disku…

Těžko říct. Problém je celkem jistě v detailech, které neuvádíš (například jak přesně jsi pole vytvořil atd.) Mně to funguje. Tady je to 100% kompletní:

set -e

# Připravíme to.
cd
mkdir btrfs
cd btrfs
for i in {0..3}; do truncate -s 10G "$i"; done
for i in {0..3}; do sudo losetup -f "$i"; done
DEVICES=($(for i in {0..3}; do losetup -j "$i" | cut -d: -f1; done))
sudo mkfs.btrfs -m raid1c3 -d raid1c3 "${DEVICES[@]}"
UUID="$(sudo btrfs fi show "${DEVICES[0]}" | awk '/^Label:/ {print $4}')"
sudo mkdir -p /mnt

# Zkontrolujeme, jestli to funguje.
sudo mount -t btrfs UUID="$UUID" /mnt
sudo chown -R "$USER" /mnt
cp -a ~/.config /mnt/  # ~2+ GB všeho možného
tar -c /mnt | sha512sum

# Posereme to.
sudo umount /mnt
sudo losetup -d "${DEVICES[1]}"
sudo losetup -d "${DEVICES[2]}"
rm 1 2  # aby se neřeklo; 0 a 3 zůstanou.

# Zkontrolujeme, jestli to funguje.
sudo mount -t btrfs -o ro,degraded UUID="$UUID" /mnt
tar -c /mnt | sha512sum

# Uklidíme zbytek toho nepořádku.
sudo umount /mnt
sudo losetup -d "${DEVICES[0]}"
sudo losetup -d "${DEVICES[3]}"
rm 0 3
cd
rmdir btrfs

Jsou tam po zmizení dvou zařízení moje data? Jsou. Takže fakt nevím, o co tady jde. Ta ješitnost, s jakou si představuješ, že se něco dostalo do kernelu bez důkladného testování, zatímco ty jediný jsi to fakt otestoval, je fakt vtipná. Záměrně nekompletní filesystém je normálně k nalezení, včetně seznamu chybějících zařízení:

$ sudo btrfs fi show "${DEVICES[0]}"
warning, device 2 is missing
warning, device 3 is missing
Label: none  uuid: e721f69b-da0f-4330-93c3-1c61882037ef
        Total devices 4 FS bytes used 2.69GiB
        devid    1 size 10.00GiB used 2.00GiB path /dev/loop13
        devid    4 size 10.00GiB used 2.26GiB path /dev/loop17
        *** Some devices missing

…aj s viacnásobným reštartom.…

Vícenásobný restart, ať už se tím myslí cokoliv, může být úplně jiná kategorie rizikových situací, že? (A trochu off-topic.) Je to právě ten typ situace, kvůli kterému některé hardwarové AID řadiče měly/mají na sobě dokonce i akumulátory. Obecně platí, že vícenásobný restart při / po / během selhávání disků není dobrý nápad. (To snad nemusím připomínat.)

Oproti desaťročia overenej kombinácii (EXT FS a SW RAID) to naozaj a stále nefunguje.

V jakém smyslu je ta kombinace prověřená? Je 100% prověřená jedině v tom smyslu, že nefunguje a ztrácí data. A davy mamlasů žijí v iluzi, že svá data ještě mají. Ach jo.

Ja chápem že si si nevšimol o čo sa jedná, tak ti to pripomeniem:

Jedná sa o prístup k dátam po výpadku jedného z redundantných diskov. Schválne som obetoval asi 10 minút z môjho života aby som si overil že tú funkcionalitu BTRFS nik netestoval.

Já chápu, že neumíš používat Btrfs a pak se mylně domníváš, že ho nikdo netestoval. No tak používej třeba FAT12.

[Peter Golis]

Ja chápem že je ťažké pochopiť že som písal o strate redundancie po pripísaní na úspešne pripojené pole, ktoré ale stále má podmienky na splnenie redundancie.

Pole som vytvíral klasicky:

mkfs.btrfs --label "BtrFS-Test" --data RAID1C3 --metadata RAID1C3 --checksum sha256 /dev/loop20 /dev/loop21 /dev/loop22 /dev/loop23

Následne som mu dva disky zobral (resp. nechal 2 disky na mirroring). Potom som to pripojil to na zápis, a vykonal zápis:

root@Ubuntu-2010:~# btrfs filesystem df /mnt/BTRFS
Data, single: total=208.00MiB, used=0.00B
Data, RAID1C3: total=965.50MiB, used=965.19MiB
System, RAID1C3: total=8.00MiB, used=16.00KiB
Metadata, RAID1C3: total=256.00MiB, used=7.89MiB
GlobalReserve, single: total=7.81MiB, used=16.00KiB
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1c3

Ako som spomínal, tak pripisoval v profile Single. Ja chápem že takéto chovanie je dostatočné pre niektorých ľudí. Ale taký single režim je jak používať spomínaný FAT FS.

Je pravda že v tomto prípade ten BTRFS nemal plnú redundanciu. Ale takáto drobnosť nastane vždy, keď vypadne disk z poľa ktoré už nemá rezervný disk.

Môj osobný názor nie je o tom, či je redundancia podmienená rezervným diskom. Môj názor je o tom, prečo sa redundancia zahodí pri výpadku.

[k3dAR]

ale dlouho ta moznost nebyla a pro me to byla odstracujici vlastnost, tohle prislo az s jadrem 5.5

[k3dAR]

stacilo tomu nerikat RAID ale treba BRAID ;)

[Peter Golis]

Navrhujem aby sa tento názov BRAID jednotne používal jak pre Block Device RAID, tak aj pre BTRFS RAID.

[...]

RAID == Redundant Array of Inexpensive Disks

BTRFS ... to je něco jako Redundant Filesystem over Array of Inexpensive Disks

[pavele]

Už je vyřešený problém nemožnosti smazání souborů při zaplnění celého disku?

Nebo se to musí pořád řešit přidáním dalšího disku do pole a následně je možné provést smazání?

[Andrej]

Už je vyřešený problém uživatelů, kteří nemají rozumně nastavené kvóty, takže neprivilegovaný uživatel dokáže zaplnit disk?

Oni byli v otázce nějak zmíněni nepriviligovaní uživatelé?

[Andrej]

On někdo počítá s uživateli s právy roota, kteří si nikde nenastaví žádné kvóty a zaplní disk? No nevím, já asi ani ne.

Mimochodem č. 1: Filesystémy, které se zmohly jen na jeden jediný disk, ale zaplnění je zbořilo (tak, že ani přidání (ram)disku nemohlo pomoct, protože víc než jeden disk neuměly), už tu byly (a nejspíš i jsou). ReiserFS i Reiser4 (jo, to už je dávno) by mohly barvitě vyprávět.

Mimochodem č. 2: Filesystému s takovou flexibilitou, že umožňuje bez umountu/mountu přidávat/odebírat disky, bych celkem směle jakýsi drobný problém odpustil.

Mimochodem č. 3: Disky a pole dnes na 100% zaplňuje … kdo přesně? V době, kdy byl 1 GB za 10 klacků, se to asi mohlo stát, ale to není tahle doba.

[LarryL]

Jako běžný uživatel jehož další FS bude BTRFS se chci zeptat vo co gou. Když zaplním jediný HDD s EXT4 až po okraj tak mohu něco smazat a když zaplním BTRFS, tak to nejde a musím preventivně nastavit kvóty?

[Andrej]

Podle mě ne. (Není náhodou, že se o tom píše v kapitole "I've heard that…".)

(Ne že by nebylo dobré si nastavit kvóty, ale celý problém je spíš v tom, že někteří věci neznalí jedinci mechanicky opakují zkazky z dob kernelů 3.x.)

[lertimir]

Určitě ne. Používám BTRFS na pracovní stanici i na noteboocích. Na pracovní stanici mám btrfs disky s filmy a comixy, které jsou zaplněné nadoraz. Write provoz na nich je jen ten, když tam dávám nový soubory, žádné použití jako systémový disk nebo pracovní, takže to když na 3TB disky je fakticky volno 2MB mi nevadí a mnohokrát se mi stalo, že jsem na ně zapisoval něco tak operace havarovala, že není místo. Vždy odmazání něčeho proběhlo bez problémů. Musíš se smířit s dvěmi vlastnostmi.

1. Samotná operace mazání trvá delší dobu než u EXTn nebo Reiser.
2. Fakticky po smazání se ti ještě ihned neobjeví volné místo. Protože b-tree stromy na kterých je postaven FS potřebují nějaký čas a background operace než zařadí uvolněné struktury do volného místa. Např při smazání cca 100GB v cca 500 souborech z 3TB disku můžeš vidět v df jak ji postupně přibývá volné místo (obsazené ti spadne hned). A třeba to trvá i několik minut.

Beru to jako přijatelnou cenu za CoW, snapshoty a kontrolu parity. Podle mne je celá tahle diskuse mimořádně hloupá. Primární otázka je jestli chceš/potřebuješ kontrolu dat na správnost až v operační paměti, CoW fs a z toho plynoucí atomické snapshoty. Ta argumentace odpůrců je primárně v tom, že to je něco co nepotřebují. Jejich volba.

[GeorgeWH]

Cisto technicka otazka k bodu 2: Pocas tych par minut je disk v akom stave? Su na nom vykonavane nejake I/O operacie, alebo je v klude? A ak sa na nom nieco deje, tak ako velmi je vytazeny? A co ak zmazem napr. 20GB mailov? Alebo 100G disk nejakej VM? Ako to bude vyzerat potom?

[Josef Kufner]

Typicky to vypadá tak, že se spustí nějaké jaderné vlákno/proces s nízkou prioritou a uklízí. Takže disk maká a maže se, ale na výkon to nemá nějak zásadní vliv, neboť běžný provoz má přednost. Totéž když se mažou snapshoty. Adresář snapshotu zmizí okamžitě a mazací operace běží na pozadí. Pokud se počítač restartuje, či disk odpojí, tak po mountu nedokončené operace pokračují, dokud není vše hotovo.

[j]

Ze to nema vliv bych teda netvrdil, odmazaval sem par stovek (mozna i nejakou tu tisicovku) snapu, a nez to dobehlo sel vykon o dobrych 30-50% dolu. To je samo ponekud slozitejsi operace nez prosty mazani souboru, ale chova se to stejne.

Pokud ale nekdo chce btrfs dostat do kolen, tak doporucuju zapnou prave quotas, to ve spolecnosti stovek (a vice) snapu sezere veskery dostupny IOps. Legracni na tom je prave to, ze tohle je jedinej oficielni postup jak zjistit, kolik snapy (anobrz subvolumy) zabiraj mista.

---

Dete s tim guuglem dopice!

[LarryL]

Díky za praktické info.

[Jendа]

Před mnoha lety to tak bylo, teď už je to dlouho vyřešené. Osobně bohužel několikrát vyzkoušeno (od kernelu 4.19, zaplněno do plna, smazáno, všechno proběhlo bez problému).

[lertimir]

kecy asi 5 let staré. viz

[Jendа]

O tom teda dost pochybuju.

Prostě to tak bylo, fakt.

a pro svůj účel taky otestovat

Ano, to udělali, ale ono to mount povolilo jednou/dvakrát (podle toho jak k výpadku došlo), takže je to skvěle napálilo.

[kol-ouch]

Díky moc za rady a náměty na další varianty - zatím nechám ext4 a uvidím

Asi jsem “vyřešil” i tu sambu:

1) stáhnul jsem z https://www.armbian.com/odroid-hc1/ Buster s jádrem 4.14

2) přes armibian-config jsem nainstalovat ovladače a nahrál “optimalizaci” pro HC2 a sambu (smb.conf jsem nechal default)

3) zkusil jsem připojení v KDE, GNOME a nic - rychlost mezi 20-60 MB/s

4) zkusil jsem namountovat sdílený adresář přes mount -t cifs //SAMBA_SERVER_ADDRESS/SHARE -o username=USERNAME /media/samba/ a kopírovat přes MC a hop - rychlosti kolem 100/115 (r/w)

Pod win 10 lítají rychlosti mezi 50-100 MB/s, v MC stabilně kolem té 100

Zatím beru jako vyřešené - než mě to zase napadne roz****t...

Díky moc

[kol-ouch]

Ale asi v tom nejsem sám: https://forum.armbian.com/topic/13243-hc1-buster_current_5419-poor-samba-speed-vs-stretch_legacy_414170/

[H@nz]

Taková kacířská otázka, co je špatného na kombinaci mdadm + btrfs? Ostatně takovýto design Synology prodává.

[Heron]

Jen to, že mdadm nedělá checksumy bloků a tedy neví, který blok ze kterého disku (pokud se liší) je ten správný. Tohle potom vede k tomu, že si sem tam vybere špatný blok, zmirruje ho na druhý disk a silent data corruption je na světě. Což se mi stalo několikrát. A v kombinaci s fs, který nedělá checksumy, tak se ani nedozvíte, že máte vadná data. btrfs by alespoň zařval chybu csum.

Jinak v zásadě nic.

Výše zmíněný problém lze odstranit další md vrstvou (md-integrity), která přidává checksumy. To používá třeba FS Stratis od RH, jedna z těch 20 vrstev je právě md-integrity.

[LarryL]

A jak si stojí FS Stratis vs. BTRFS? Když píšeš o 20 vrstvách tak předpokládám, že FS Stratis je mnohem větší moloch určený pro enterprise. V roce 2018 RH skončil s BTRFS a nyní přichází BTRFS do Fedory. Tak si říkám, že když mám v úmyslu opustit ext4, tak jestli zrovna nezkusit Stratis.

[Heron]

Stratis neumí ani z poolu odstranit device a nenabízí žádné raid funkce. Aktuálně je to jen helper nad lvm thin provisioning, umí to dělat "subvolume", což je thin lv s xfs, jejich snapshoty (xfs umí dělat cow kopii jednoho souboru, na tom je to postaveno) a rollbacky.

Takže zatím to neumí skoro nic.

Neříkám, že je to k ničemu, to fakt ne, je určo lepší použít stratis než ručně konfigurovat lvm thin a manuálně zvětšovat XFS, ale přímé porovnání s btrfs to fakt nesnese.

Když se podíváte na design document, tak skoro všechny funkce (třeba ten raid i dm-integrity) jsou označeny "In future version".

Asi bych k tomu neměl psát svůj osobní postoj, ale "fs" postavený kolem dbus není můj šálek kávy a dále bych čekal trochu nějaké killer features a trochu svižnější vývoj. Jako na to, že je to v podstatě jen slepení již existujících vrstev (čímž se chlubí RH), tak toho jednak umí dost málo a taky ten vývoj nějak dlouho trvá. (BTRFS spíchnul jeden doktorand v podstatě za rok na základě své diplomky - spojení b-tree a cow a od verze nula to mělo multidevice, raid, subvolume a snapshoty.) A takto se podle mě pozná skutečná inovace. Prostě někdo najde spojení dříve nekompatibilních věcí (COW se používalo od pradávna na ušetření paměti a všechny moderní fs jsou založené na b-tree) a náhle z toho vznikne nová kvalita.

Stratis mi z tohoto pohledu přijde trochu jako truc projekt, prostě to uděláme se stávajícími prostředky, i kdybychom ty vrstvy měli k sobě slepit lepidlem. Tento koncept mi přijde velmi křehký, protože potom stačí, když jedna z vrstev spadne (třeba ten dbus, že) a už to nefunguje. Ale jako třeba z toho za pár let udělají skutečně enterprise storage řešení. Za největší nevýhodu btrfs považuju nemožnost přímo exportovat blockdevice (to třeba umí zfs) a musí se to dělat přes loop, tak snad v oblasti multidevice raid integrity block device stratis jednou zazáří. Moc bych si to přál.

[pavele]

Tomu nevěřím. Myslím si, že stratis je slepá vývojová větev a všechno to skončí, je to příliš složité, "vachrlaté", a to i ve srovnání s btrfs.

Lepší by bylo se zaměřit na zlepšení xfs, btrfs nebo ext4.

Třeba ext4 s kernel modulem se může chovat jako ntfs s "shadow copy" nebo lvm - viz "hcp".

Ten nápad se stratis si myslím vznikl nějak takto:

Btrfs nemůžeme podporovat, nemáme na to lidi, je to náročné pro dlouhodobou podporu -> slepíme něco z toho, co už je - bude to spolehlivé - nebude problém s dlouhodobou podporou - s vývojem, s lidmi.

Podle mne to zanikne a všichni se konečně budou věnovat opravám chyb a zdokonalováním btrfs.

Nebo, jak už to tak bývá, vznikne něco úplně nového, jednodušší koncept vhodný pro SSD/NVMe/RAM.

Zkuste to bez fs, Marconi...

[LarryL]

Díky za názor. Zůstanu teda realista a zaměřím se na BTRFS.

[trekker.dk]

Čistě teoreticky je Stratis lepší nápad než Btrfs. Místo toho, aby se všechno nacpalo do jednoho filesystému, který si hraje na vlastním písečku, máte mnoho vrstev, kde každá dělá to, co dělat má - a právě to. Takový ten základní unixový princip, že jeden nástroj dělá jednu věc a dělá ji dobře. Výhodou je, že tu vrstvu může pak použít i něco jiného, takže zlepšujete jádro jako celek.

Čistě prakticky je potřeba, aby si ty vrstvy mohly vyměňovat mnohem více informací, než umí teď, a uměly s nimi pracovat. (Příklad bude mimo Stratis, ale třeba takový MD RAID neumí zpracovat TRIM jinak, než že jej přepošle zařízením pod sebou - sám není schopen si zaznamenat, že příslušná oblast se nevyužívá a při synchronizaci pole je možné ji vynechat.) Aby tohle fungovalo, bylo by potřeba práce jako na kostele - Btrfs se přece jenom vyvíjí jak dlouho, přes deset let? A tuhle práci by musel někdo zaplatit.

Vzhledem k tomu, že u LWN - u kterých předpokládám, že by nějaký větší vývoj nenechali bez povšimnutí - je o tomhle tématu ticho po pěšině, tak bych řekl, že se do toho Red Hat zas tak moc nežene.

[LarryL]

Stratis je nyní ve verzi 2.1.1 a co jsem vyčetl, tak až u verze 3 by měl mít vlastnosti srovnatelné s BTRFS nebo ZFS. Takže čas ukáže, ale začal jsem z toho mít pocit, že to bude opravdu velký enterprise systém, který bude nad rámec znalostí běžných administrátorů malých a středních firem nebo dokonce běžných uživatelů Fedory.

Jelikož i ty píšeš o spoustě práce, která na Stratisu bude, tak mně z toho logicky vychází, že nejmodernějšími FS budou v následujících letech Btrfs a ZFS.

[trekker.dk]

Já bych je nazval spíš úložnými systémy než filesystémy, ale ano, pokud chcete něco teď nebo v nejbližších jednotkách let, Stratis to IMO nebude.

[Heron]

Čistě prakticky je potřeba, aby si ty vrstvy mohly vyměňovat mnohem více informací, než umí teď, a uměly s nimi pracovat.

Potom to nejsou vrstvy. Můžete se tvářit, že to jsou vrstvy, ale pokud vrstvy musí vzájemně intenzivně komunikovat, tak už to nejsou vrstvy.

Můžeme tomu říkal klidně komponenty, nebo knihovní funkce, ale nejsou to vrstvy. (A netuším, jak moc btrfs používá stávající knihovní jaderný kód, určitě pro kompresi a pro hashe, ale jak moc je pro něj využitelný kód z těch vrstev, tipuju, že spíš ne.)

Aby tohle fungovalo, bylo by potřeba práce jako na kostele

Nebo se na to úplně vykašlat a přejít na jiný způsob uvažování. O ničem jiném to už není. Právě to, že stávající systém by se musel brutálně přestavět, aby dosáhl něčeho, co v jiném konceptu jde levou zadní (a prakticky je to jen vedlejší produkt) je nejlepší ukázka zastaralosti tohoto přístupu.

Ano, stávající "vrstvy" jsou produktem uvažování z doby, kdy disk, redundance, systém rozdělení na oddíly, fs byly skutečně oddělené vrstvy. Ale je jasné, že v tomto uspořádání není možné ani distribuovat volné místo přes různé oddíly. Nehledě na zmíněný resync pouze plných bloků. A další milion věcí.

Ale jak jsem psal, za Stratis jsem rád, i když je to prostě jen truc projekt. Každé další storage řešení je lepší než nic.

[trekker.dk]

Můžete se tvářit, že to jsou vrstvy, ale pokud vrstvy musí vzájemně intenzivně komunikovat, tak už to nejsou vrstvy.

To je akorát ptákovina, kterou jste si vymyslel, abyste mohl nesouhlasit. Kde je rozhodující hranice pro intenzivnost komunikování, aby to už nebyly vrstvy? Je předávání dat k zápisu na disk příliš intenzivní, nebo ještě ok? Nebo chcete tvrdit, že filesystém (a VFS) a device mapper a MD RAID nejsou vrstvy, protože spolu intezivně komunikují, když filesystém pošle TRIM?

Nebo se na to úplně vykašlat a přejít na jiný způsob uvažování.

To pro vás nebude problém a přecházejte si klidně, kam chcete. Já nevidím důvod, proč by např. checksumy dat měly být exkluzivní funkcí Btrfs a nemohla to dělat nižší vrstva pro kterýkoliv filesystém nebo cokoliv jiného, co využívá blokové zařízení.

[Heron]

Vrstvy, které musejí intenzivně komunikovat oběma směry a ještě i přes sebe, nejsou vrstvy. V tom Stratisu aktuálně nefunguje ani správné reportování místa na disku. FS je vytvářen na 1TB thin provision LVčku a v du uživatel vidí 1TB, i když to má na menším disku. Někde (v přednášce o vylepšení xfs), jsem zaslech informaci, že bude potřeba du přepsat. Tohle už není ani unixové, tohle je jednoduše chaos, kdy se kvůli nějakému konceptu musí všechno přepsat, předávat si info (oklikou mimo vrstvy) ještě přes dbus. Ano, v stratis filesystem list člověk vidí správné údaje, ale ve standardním nástroji nikoliv. A už vidím, jak nějaký magor typu Poettering bude prosazovat jediné správné předávání systémových informací přes dbus, na který se bude napojovat provider informací o fs.

Tak to asi tolik k těm vrstvám. Prostě ve stávajícím konceptu je to nemožné udělat.

checksumy dat měly být exkluzivní funkcí Btrfs

Nic takového jsem nikde nepsal. Jestli to někdo naimplementuje pro obecný blockdevice, tak to bude super (ve skutečnosti ano, md-integrity a dá se to použít v luks).

[trekker.dk]

Vrstvy, které musejí intenzivně komunikovat oběma směry a ještě i přes sebe, nejsou vrstvy.

To jste podruhé zopakoval to samé, ale argument stále žádný.

[Heron]

To není o argumentech, to je o definicích. Pokud za koncept vrstev považujete cokoliv, co vesele komunikuje mezi sebou bez ohledu na hierarchii oněch vrstev (která tam třeba kdysi byla), tak snadno pojmem vrstvev pojmenujete věc, kterou někdo jiný nazývá monolit.

[trekker.dk]

Pokud ty vrstvy nemají existovat ve vakuu, tak mezi sebou vesele komunikovat musí, to tak nějak z principu, jinak by neměly práci. Zakládat na tom tvrzení, že to už pak nejsou vrstvy, je nesmysl, to by byl monolit všechno

[Pavel 'TIGER' Růžička]

Tak jsem to celé přelouskal. Myslím si že s FS je to jako se ženskou, který ti padne do ruky, s takovým zůstaneš (nikde není psáno, že po celý život) Já osobně bych ext4 za btrfs neměnil. Ale též poslouchám oldies a ne Ztracenou Hrůzu.

[Heron]

Zrovna vyšla docela pěkná přednáška. Je celkem fascinující, že i v roce 2020 (resp on tam odkazuje na papery z roku 2014 a 2017) se storage systémy spoléhají na data vrácená z disku a některé jsou ještě ochotné vadné bloky distribuovat na další node. Tím získává pojem silent data corruption ještě o něco děsivější nádech. (Jako vážně, napadlo by vás, že někdo napíše distributed storage systém a ani nekontroluje, jestli jsou ta data v pořádku? A spoléhá se na FS, které nemají checksuming dat?)

Aneb někdo v roce 2020 objevil crc32... My paranoici odjakživa používáme rovnou sha512 (protože nic většího není).

[PetebLazar]

Co se stane s pokročilým FS, který si do svých struktur uloží checksum(y) spočítaný(é) s chybou díky nahodilé chybě CPU? Nebo je vždy počítá dvakrát(či dvěma způsoby) a výsledek před uložením srovnává?

[Heron]

Netuším, to bude záležet na konkrétní implementaci. Ale vede to k zajímavým otázkám. Jako určitě to pozná při čtení toho bloku a nebude sedět ani jedna kopie. Tj potom vypnout kontrolu csum a ten soubor přečíst takto.

Taky je otázkou, jak často takto CPU chybuje (a to by těch rozbitých dat bylo daleko více). Chybu ECC (opravitelnou) cache CPU jsem viděl jen jednou.

[PetebLazar]

Jak často navzdory ECC u dat HDD sektoru ... 50B(512B),100B(4K) jsou chybně přečtená data prohlášená za správná (s opačným případem, kdy jsou správna data označena za špatná se nám bez dopadů vypořádá redundance na vyšším levelu .. >=RAID1, obsah se přečte z jiného členu/dopočítá z parity)?