Další výkonnostní vylepšení v BTRFS (diskuse)

[Aleš Kapica]

Pěkné.

[Max]

Pozoruji vývoj btrfs a musím říci, že v rámci kernelu 6 toho opticky přibylo docela dost. Myslím těch kruciálních věcí, co mají vliv na výkon a funkce.
Je tedy docela lákavé jet poslední verze kernelů už jen kvůli btrfs (pokud ho člověk používá).
Zdar Max

[hm]

kamarade reknu ti jen nom tolik delej si zalohy ucarovani strida triskani po stole nedekovat

[________]

Musím s ním souhlasit. Struktura dat nejsou sranda. Jen to otestujte, přidám se za pár let.

[Want]

Další, co poslouchá jak v dáli utichá houkání vlaku, do kterého měl nastoupit, ale chyběl vagón s jeho číslem.

[J]

Ale prd. Btrfs je dobre leda tak pro male linuxove nasazeni, zkus ho nekde nasadit treba na stovky TB a pak se muzeme bavit. ZFS.

[Want]

Mám nasazený Brtfs na stovkák petabytů. Kdyby sis přečetl můj blog, tak se tu takhle nemusíš ztrapňovat, kryso špinavá anonymní.

[PetebLazar]

Šlo by sem dát odkaz na to petabytové BTRFS řešení, mě se to v blogu najít nepodařilo (možná za to může moje současná zvýšená teplota )?

Ani jsem netušil, že tolik dat v ČR máme. Pro srovnání, genetický kód všech obyvatel ČR by se vešel pohodlně do cca 50 petabyte.

[Want]

Kdybys hledal pořádně a nevymlouval se na nemoc, tak dávno víš, že provozuji virtualizovaný cluster u nás na fakultě. Nevím na co přesně chceš odkaz.

[PetebLazar]

Na libovolný článek, který dané řešení popisuje.

Kapacita stovek petabyte (tj. řád 10^17 byte) představuje při dejme tomu využití 10TB HDD (řád 10^13 byte) tj. i bez započítání nezbytné redundance řádově desítky tisíc HDD.

[Want]

Proč bych ti hledal články? Možná o tom napíši blog, ale to záleží jak se budete chovat.

[PetebLazar]

Mám nasazený Brtfs na stovkák petabytů. Kdyby sis přečetl můj blog, ...

Pochopil jsem Vaše věty výše tak, že k tomu (x00 PetaByte BRTFS) něco relevantního bylo sepsáno. Beru to tak, že ve skutečnosti nikoli a kvůli mě se s tím rozhodně neobtěžujte.

[J]

Stovkach petabyjtu? Jedno pole nebo na kazdem pocitaci mas nekde 1 disk s btrfs? Kde ty stovky petabajtu jsou? Takovy backblaze ma stovky petabajtu je jiz v zetabajtech), ale nevim o nicem stejne velkem v CR.

[PetebLazar]

Možná jde o pouhou záměnu stovek petabyte za stovky terabyte, náklady v řádu stovek tisíc Kč za HDD asi více odpovídají místním finančním možnostem (než stovky miliónů Kč jen za samotné HDD u kapacit v řádu stovek petabyte).

Jak říkaval údajně jeden z vyučujících Konstrukce spalovacích motorů: "Pokud Vám při návrhu vyjde obsah válce v jednotách mm3 či jednotkách m3 je třeba se zamyslit, zda nedošlo při výpočtu k chybě při převodu jednotek."

[________]

Jen poslouchám hlas rozumu. Nevidím důvod používat něco, co se snadno rozsype, nástroj na opravu nesouhlasí s verzí FS apod. Bohužel stále tam probíhá překotný vývoj. Už jsem se s tím několikrát babral, když se to rozsypalo. Nejsem puboš ani developer, abych to používal. Není důvod když jsou tu ověřené FS. Sna jen ve vyjímečných případech.

Co tam máš dál?

[Max]

Zálohy snad dělá každý normální člověk, ne? Jinak btrfs mi běží stable hafec let na hafec zařízeních. Jen jestli to nebude problém spíše v tom, že tu pár lidí řešilo rozbitý btrfs a shodou okolností měli Samsung 860/870, který je totálně zabugovaný v TRIM, NCQ a potencionální ztrátě dat. Tj., zda se nesvádí vadný hw na software? .
Zdar Max

[plostenka]

Neni se ceho bat, btrfs je neomylne.

fsck.btrfs - do nothing, successfully

[Max]

Takže když ti hw poškodí fs, tak by jsi rád, aby ti s tím ještě nějaký sw náhodně zamíchal, jako to třeba dělal fsck u ext4? :)
Zdar Max

[plostenka]

Kdyz mi hw poskodi data, tak hlavne vyhodim hw :) Ale RAID 5 + hotspares je i na tohle celkem odolny...

[Jendа]

IMHO se bavíme především o poškození struktur FS při manipulaci v paměti - vadná RAM, SW bug v driveru FS (race condition…), SW bug v jiné komponentě OS (nekompatibilní uzavřený ovladač…), který poškodí nesouvisející cizí data. Tam ti RAID (scrub, …) nepomůže, data už se chybná zapsala.

Max: byl bych rád aby nástroj uvedl FS do konzistentního stavu a nahlásil mi jména souborů, které je nutné obnovit ze zálohy. Smazat celý FS a nahrát data zpátky zvenku pokaždé když se objeví chyba konzistence je neúnosné.

[PetebLazar]

Jak se zachová ZFS/BTRFS scrub když se kvůli chybě v paměti na FS uloží chybný checksum?

[Jendа]

Řekne že našel chybný checksum, pokud máš RAID tak ho možná dokonce sám přepíše správnou verzí z ostatních disků, jinak ti řekne které soubory se poškodily (nevím jestli nějak přes čísla), pak nevím co se s tím dál dělá. Nikdy se mi to nestalo, ostatní třeba poradí.

[PetebLazar]

Data byly ulozeny spravne, pouze v ZFS checksumu byla chyba. Pokud bude nasledovat ZFS checksum,opravi spravna data na chybna?

[Max]

Pokud máš redundanci, tak to opraví z ní, pokud nemáš, tak těžko může něco opravit.
V případě btrfs i zfs se lze dozvědět, kterých dat se to dotknulo.
Zdar Max

[PetebLazar]

O jaké redundanci je řeč, pokud byl checksum vypočítán chybně (či pozměněn v RAM) jejich případné redundantní uložení na tom asi nic nezmění?

[J]

Redundance na urovni fs. Trwba u zfs mam u dulezitych dat pocet kopii 3, takze kdyz se i nejaky soubor dosere tak se obnovi z dalsi kopie v ramci toho sameho poolu.

[PetebLazar]

Bavím se o případu kdy samotná data jsou OK a více kopií corrupted metadat patrně ničemu nepomůže.

Měl jsem za to, že integrita dat je u BTRFS/ZFS garantována díky checksumům datových bloků na úrovni FS. Když se chybný uložený checksum bude lišit vůči správnému checksumu vypočtenému z odpovídajících bezchybných datových bloků, jak se filesystém rozhodne že nejde o případ rot bitů v datových blocích?

[J]

Jakoze by byli poskozene 3 kopie metadat zatimco 3 kopie dat samotnych by byli vporadku? To je hodne teoreticka situace, spis mi doma u altanku pristanou ufoni aby mi sdelili ze jsem vyhral ve vsech loteriich na svete prvni cenu. Pokud jsou metadata corrupted a mas vicero kopii v ramci zfs tak si to opravi ty metadata u te jedne nespravne verze.

[PetebLazar]

Pokud se metadata (checksumy) spocitaji v CPU chybne (ci jsou ex-post modifikovany v RAM pred jejich ulozenim) budou logicky vsechny jejich ulozene kopie na discích obsahovat tyto chyby.

Filesystemy by se tomu mohly branit redundantnim vypoctem/ulozenim checksumů v RAM (idealne spočtené jinymi vykonnymi prostredky CPU core/SSE) a jejich vzajemnym porovnanim a ex post kontrolou (ze nedoslo k jejich zmene v mezidobi). To bych očekával od filesystému, který se deklaruje jako robustní. A když ne v defaultu, tak minimálně jako volitelnou možnost (ideálně i moznosti verify zápisu).

Pokud dojde ke korupci užitečných dat v paměti s jejich následným uložením, není to problém nedokonalosti filesystému (ten pouze uložil data, která měl svěřeny). Minimalizovat riziko vzájemné nekonzistence metadat a dat v případě možných chyb je v jeho silách, pokud se na to v implementaci nevykašle.

Statiticky bude vzájemná pravděpodobnost vzniku nahodilé chyby patrně dána poměrem velikosti metadat a dat, což nebude zase tak vysoké číslo.

[Max]

Od toho je ale redundance. Všechny případy nevratně nabořenýho fs byla one man show jednoho ssd disku. Kdo měl dva, třeba i ty dementní Samsungy 860/870, tak problém neměl. Jinak si nejsem jist, ale ke ztrátě dat nedošlo i s jedním diskem, jen fs vykazoval neznámé chyby v kernel logu, ale data byla přístupná.
Jinak ono se asi jednoduše řekne "vrátil do konzistentního stavu", ale pokud ti vadný ssd disk zamíchá s daty a nemáš redundanci, tak jak má ten nástroj poznat, co je v cajku a co v cajku není? Např. nesedí checksum, takže je v háji checksum, nebo data, nebo oboje? Jak to má poznat? Podle čeho? Podle ničeho. A takových případů existuje podle mě více. Přecijen fs je celkem složitá záležitost. Myslím si, že to spousta lidí mylně vidí velmi jednoduše.
Zdar Max

[trekker.dk]

Máte pěkný Stockholmský syndrom. Btrfs nemá použitelný fsck, takže kompletní obnova ze zálohy jako jediné řešení nabořeného filesystému je vlastně úplně v pohodě. Sice ještě donedávna šly věci řešit tak, že se pomocí fsck filesystém uvedl do konzistentního stavu a ze zálohy stačilo obnovit to, co bylo ztraceno, ale holt časy se mění, když vás nové a lepší drží jako rukojmí.

[Max]

Já to tak nevnímám, protože si nepamatuji, že bych to někdy v posledních 10 letech musel řešit. Mé dlouholeté zkušenosti mně prostě dovedly do stavu, kdy je mi nějaký fsck u zádele a v případě nějak nabořeného fs mám jiný problém k řešení (= proč to nastalo a jak se tomu vyhnout), pokud chci data, tak sahám prostě do zálohy, nebo rollback storage snapshotu, což vlastně asi nikdy nenastalo. Tím chci tedy říci, že s filozofií vývojářů nemám problém.
Zdar Max

[Jendа]

Všechny případy nevratně nabořenýho fs

Já jsem mluvil o takové té běžné situaci, kdy si při bootu fsck buď stěžuje ale opraví to, nebo failne a musí se pustit manuálně, vypíše to nějaké náhodné věci a pak to zase všechno funguje. A to se mi bohužel děje na všelijakých počítačích, i před érou SSD.

[Max]

Nikdy jsem nezažil, a to btrfs používám už sakra dlouho. Kupodivu jsem začínal na serveru a pak postupně nasazoval i na desktopy.
Kdyby se mi něco takového stalo, řešil bych příčinu, né důsledek. Ani nevím, zda bych věřil nějaké opravě od fsck, aspoň tedy podle toho, jak se podobné nástroje dřív chovaly na ext4.
Zdar Max

[Jendа]

Ani nevím, zda bych věřil nějaké opravě od fsck, aspoň tedy podle toho, jak se podobné nástroje dřív chovaly na ext4.

Takže na ext4 se ti to dělo? (mně taky, ale děje se mi to i na btrfs, kde to ale na rozdíl od ext4 nejde opravit)

[Max]

Ne, jen z doslechu na netu. Já zažil jen ty doporučené fsck při startu, kdy nad x TB to trvalo dlouho.
Zdar Max

[plostenka]

No ano - na SW bug pomuze fsck, na hw bug RAID5/6. Pokud mas fsck i raid implementovany v jedne komponente, tak bug te jedne komponenty ma dalekosahle dusledky.

Souhlas s tim, ze reportovat jmena poskozenych/opravenych souboru by bylo uzitecne. Ext-x reportuje jenom inody, coz je pri aplikaci zaloh k nicemu.

[Max]

Tak on RAID5 a celkové řešení hotspare je docela přežitek. Každopádně bavíme se tu o případu jednoho ssd disku, který zamíchá s datama. Pokud máme aspoň nějakou redundanci, i v případě, kdy používáme debilní Samsung 870, tak problém nenastane, nebo když nastane, tak zafungují automatické techniky na opravu.
Zdar Max

[plostenka]

Jo, je to architektonicky/navrhove prezitek, ale vicemene stabilni prezitek. Dokud bude vyvoj btrfs/zfs tak bourlivy jako je dosud, tak na te boomeri technologii jeste zustanu :)

Jakmile jsi na jednom jedinem disku (SPOF) tak te pri "spravne" konstelaci bitflipu nezachrani nic.

[Max]

Bouřlivý? :D ZFS je s námi od roku 2004, btrfs od roku 2007. ext4 je nepoužitelný, reiserfs je bez vývoje / unsupported. Zbývá tedy XFS, který ale zažívá právě onen bouřlivý vývoj, aby se trochu přiblížil k btrfs.
Zdar Max

[plostenka]

Lol, vis pod jakou zpravickou ted diskutujeme?

[Max]

Pokud narážíš na to, že přišly výkonnostní patche, tak se podívej do changelogů ostatních fs. Reálně máš dnes na Linuxu použitelný btrfs, xfs a omezeně ext4 (přestal jsem ho mít rád, doporučené pravidelné fsck trvají dlouho, statický počet inode je velký zlo atd.). Pokud tedy nechceš patchovat a používat ZFS. Pokud narážíš na stav RAID56 u btrfs, tak tady mám bohužel jiný názor. Pokud bych k tomu byl donucen, tak bych se toho nebál, ale reálně se RAID56 vyhýbám všude možně. Nikde už ho nepoužívám hafec let, protože je to prostě nerentabilní z hlediska výkonu a u dnešních kapacit i z hlediska sakra dlouhého resyncu. Doba, kdy člověk musel šetřit, protože disky byly ukrutně drahá věc, je podle mně tatam.
Zdar Max

[plostenka]

Resync time je v podstate nedulezity, na read-write nema vliv. A mdraid nedela resync celeho storage, ale jenom bloku z vadneho disku (proto je lepsi mit vic maloobjemovych nez par velkych). Predpokladam ze i btrfs musi nejak checksumy pocitat a uplne nevim jakym trikem to lze udelat vyrazne lepe a bezpecneji a rychleji.

[Max]

Když ti vypadne jeden disk z RAID5, musí se dopočítat ze zbylých disků. To sežere nějaký čas. Během toho času ti může odejít další disk a je to v háji. Během toho času máš snížený výkon pole. Je to samozřejmě super rada, nepoužívat v dnešní době 8TB a víc kapacitní disky, které jsou rentabilnější a mají lepší výdrž / menší poruchovost (protože helium). U mdadm lze v určitých případech urychlit resync tak, že si definuješ bitmapu.
Zdar Max

[hm]

ja nemusim delat zalohy protoze mam ntfs

[X]

loool

[hm]

na smich je takovej system co ti rika hele nic ti nezarucujeme vsechno je na vasi zodpovednost a proto jsi delaj zalohy :D :D dekuji nechci

[ok1dtm]

Moje zkušenosti s disky Samsung EVO 860/870 a BRTFS jsou velice dobré. Nevím jak starý firmware ale s posledními verzemi jsem žádné problémy s TRIM a NCQ nezjistil

[Max]

Co vím, tak poslední patche v Linuxu vypínaly TRIM a NCQ pro tyto modely. Jak je to v kombinaci s novým fw, to nevím. Jen jsem poznamenal, že s těmito disky byl dlouhodobý problém až někam ke konci 2021 (u mnohých lidí, co nejeli aktuální kernel, tak to bylo asi ještě déle). A to byla doba, kdy se objevovali lidi v diskusích s nekonzistencí dat u těchto disků. Svádělo se to na FS, ale zřejmě to byla záležitost hw. Ale Linux není jediný, v MACOS byl se Samsungem také problém.
Zdar Max

[sid]

Povedal by som, ze ide hlavne o trolling. Kazdy z nich samozrejme uklada minimalne 100TB dat :).

[hm]

ty radeji nic nerikej mam zbirku her o kerych jsi muzes jennom zdat jo

[J]

Nepovazuji se za nejakeho pocitacovejo geeka, ale rad fotim, filmuji, del ruzne analyzy a mam neco malo pres 1PB storage (cista kapacita). Disky jsou relativne levne, vydelavam dost na to abych si to mohl dovolit. A ne, btrfs tam opravdu nemam.

[lertimir]

Vypadá to super. co se týká aktuálních jader, nepotkal jsi při své práci CachyOS?

[Max]

Ne, jedu jen klasiku jako Debian, AlmaLinux, Arch, Alpine, Raspbian...
Zdar Max

[lertimir]

Zaujalo mne, že jsou z Archu, mají velmi aktuální jádra (6.3 už mají) a mají shedulery, které by měly být responsivnější v desktopu. až budu mít čas tak zkusím ve virtuálu.

[Want]

Nesmysl.

[Zum]

Konkrétně je až 4x rychlejší

X x 4 =