Linus Torvalds nedoporučuje používat ZFS na Linuxu

Linus Torvalds nedoporučuje používat souborový systém ZFS na Linuxu. Do Linuxu jej nezačlení, dokud nedostane oficiální dopis od společnosti Oracle podepsaný jejich hlavním právním zástupcem nebo nejlépe samotným Larry Ellisonem, že jej začlenit může a výsledný kód může být GPL [Hacker News].

10.1.2020 01:00 | Ladislav Hagara | Komunita

Komentáře

[Tyler]

A systemd mozeme dalej pouzivat bez starosti ?

[haters gonna hate]

systemd je userspace, do toho linus zase tak moc nekeca...

[jdsulin2]

Hlavne tady se resi licence ZFS a on tu do toho taha systemd, ktery za a) neni soucasti jadra a za b) nema nekompatibilni licenci (i kdyz jak pises ty, v userspace je to uplne jedno)

[_]

Já to nedoporučuju už celou věčnost.

[cezz]

And as far as I can tell, it has no real maintenance behind it either any more

Myslim, ze to dostatocne ukazuje ze konkretne tento Linusov rant treba brat s velkym odstupom.

And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.

Neviem preco vobec zacal riesit to ci ten kod zacleni do jadra alebo nie, pretoze to nikto predtym neriesil a myslim ze kazdemu je jasne ze to sa nestane. (a pokial viem diskusia je len o tom ci s tym ma problem GPL, CCDL pokial viem pridanie dalsej licencie umoznuje pokial bude zachovana aj CCDL) cize Oracle s tym zrejme problem nema uz davno a ten podpisany papier by skor potreboval od FSF.

Kazdopadne to bol rant dost mimo temu ktorou bol fakt, ze niekolko exportov prepli z EXPORT na EXPORT_GPL, cim rozbili (okrem ineho aj) ZFS. (uz je to fixed)

[_]

Ty pracuješ pro Oracle nebo proč tyhle kecy?

[cezz]

Co konkretne myslis?

[Peter Golis]

Mňa by skôr zaujímalo či Linus myslel to ZFS pre Linux od firmy Oracle, alebo od firmy Nexenta.

[Max]

Co má co Linus společného se ZFS od Nexenty? Nexenta je Solaris like a jeho ZFS má jako closed source (pokud si to dobře pamatuji).
Zdar Max

[Max]

Jinak nevím, jak Oracle, ale všichni vesměs vycházejí z OpenZFS, i snad Nexenta, která na to balí ještě své věci (jako HA Active-Active apod.).
Zdar Max

[Peter Golis]

Oracle kúpilo SUN Microsystems aj s HW a SW, a to vrátane ZFS ktorý im beží nielen na Solarise, ale aj na Linuxe.

Nexenta ako taká robila prvé portácie ZFS pre Linux, a už pred desiatimi rokmi im fungoval napríklad TRIM. Ten pri ZoL edícii stále blbne. Mne napríklad pri odmazaní 30G dát nechal obsadených cez 6G ktoré ale neboli ničím otvorené. A neuvolnil to pokiaľ som nedal ZPOOL do offline (reboot alebo export/import). Týmto pozdravujem Snajpu aj s jeho narážkou na fungujúci autotrim v ZoL. Presne takto sa ten autotrim prejavoval na ZoL.

PS: Ja osobne zatiaľ neodporúčam ZoL na Linuxe vôbec. Práve sa s tým hrám, a lezú z toho dinvné veci.

[Max]

Můžeš dodat nějaký zdroj k těm tvrzením? Konkrétně to, že má Oracle Linux s podporou ZFS (jednak by tím porušili licenci, nebo kdyby přelicencovali, tak by to potencionálním zákazníkům museli na žádost dát včetně zdrojáků se správnou licencí a kdyby to chtěli obejít, tak do userspace by asi ZFS neimplementovali)? A také to s Nexentou a Linuxem? Co vím, tak Nexenta jela vždy Solaris, jediné, co z Linuxu(resp. z Ubuntu/Debianu) používala byl userspace, čemuž říkali Nexenta Core Platform.
Pro mně jsou obě tvá tvrzení trochu novinkou, nevím o nich, tak proto, ať se přiučím.
Díky
Zdar Max

[Peter Golis]

O porušenie licencie by sa jednalo, keby ktokoľvek prilinkoval ZFS priamo do jadra. To však nikto neurobil, ale haló je z toho veľké. Až moc.

A nejako sa mi nezdá že by Nexenta robila ZFS pre Solaris ak ZFS pre Solaris robil priamo SUN Microsystems a neskôr Oracle. Nexenta robila svjho času ZFS pre OpenSolaris/Ilumos. A stále robí kadejaké deduplikačné krabičky, do ktorých asi nedávala niečo iné.

[Max]

Když píšu Solaris, myslím Solaris like systémy (ano, nevyjádřil jsem se jasně, pardon). Každopádně ty zdroje toho tvého tvrzení ohledně Linuxu a ZFS (jak u Oracle, tak Nexenty)?
Díky
Zdar Max

[Peter Golis]

Nexenta robila ZFS Fuse, a potom sa stratila z portálov. Udržiava si svoje know how pekne uzavreté. Občas ešte prispejú do ZoL, napríklad posledná implementácia TRIM bola od nich. Bola to tá, ktorá konečne v tom projekte fungovala.

Mimochodom, to s tým OpenSolaris/OpenIndiana/Ilumos a ZFS u Nexenty ma zaujíma. Ale nie je divné že ak Nexenta má Storrage Produkty s deduplikáciou a flash storrage, a robí do OpenSolarisu? Ak by robili priamo do OpenSolarisu, tak by ten TRIM mal v OpenSolarise fungovať dlhšie ako od poslednej jari.

[Max]

Ty tvé úvahy ohledně OpenSolarisu nechápu. OpenSolaris vydal Sun v roce 2004 (což otevřelo dveře všem a otevřelo to dveře k ZFS) a Nexenta na něj skočila a začala dělat storage. Poté, co Oracle OpenSolaris zaříz (ano, OpenSolaris už není, asi tak od roku 2010) přešla Nexenta na Illumian (Illumos + GNU userspace z Debianu/Ubuntu) a aktuálně myslím staví přímo nad Illumosem.
Každopádně to, že něco Nexenta nebackportuje zpět není nic divného, přeci všichni víme, že má své vlastní propri patche pro ZFS a celkově pro jejich storage řešení.

Každopádně do třetice všeho dobrého, dodej zdroje pro ty svá tvrzení, který jsi na začátku suveréně napsal a posledních x komentářů ignoruješ mé dotazy na uvedení nějakých zdrojů.
Zdar Max

[Peter Golis]

Ktoré tvrdenie, môžeš byť presnejší?

Mám doložiť moje tvrdenie že pri zapnutom autotrim mi ZoL neuvoľnil vymazané miesto, ale ho aj čiastočne zobrazoval ako obsadené aj keď nebolo uzamknuté?

Alebo to tvrdenie že Nexente fungoval TRIM desať rokov pred tým ako ho dali do ZoL?

[Max]

Ne, od začátku se pořád ptám na to samé a ty se tomu stále vyhýbáš. Nejdřív něco tvrdíš, pak se to snažíš nějak obhajovat a vymýšlet si další věci a nakonec děláš, že nevíš, o čem je řeč. Tak po čtvrté a naposledy :
1) Zdroje pro tvrzení, že má Oracle Linux s podporou ZFS
2) Tvrzení, že Nexenta měla/má Linux se ZFS, nebo port ZFS na Linux (a naposledy jsi tvrdil, že udělali jako první port ZFS pro Linux přes FUSE)

Ptám se tě na doložení zdrojů k těmto tvým tvrzením už počtvrté.
Zdar Max

[Peter Golis]

Som rád za to, že si sa konečne vyjadril.

To prvé mi vravel bývalý kolega, keď videl štartovať Oracle Exadata Appliance. Vravel niečo o Linuxe na x86/64. Nepredpokladám že by mal problém vnímania, i keď v korporáte by som to nevylúčil.

To druhé má dve časti. Jednu mi potvrdil CTO istého nemenovaného webhostingu, keď mi vravel že bežia Ubuntu 16.04 od Nexenty a s ZFS. Tá druhá časť zodpovedá projektu http://zfs-fuse.net/ ktorý pred pár rokmi zanikol.

PS: Štvrtý krát, ale až teraz zrozumiteľne. Nechceš na tom zapracovať?

[Max]

Aha, takže opět žádné zdroje, jen jedna bába povídala a nic z toho není pravda.
Ten CTO je mimo, Nexenta jen na OpenSolaris nabalila userspace z Ubuntu, nic víc. Žádnej Linux.
A za ZFS-Fuse stojí zase google summer of code.
Evidentně tedy o ZFS moc nevíš, ale nutkání šířit bludy zjevně máš, opět :-/.
Zdar Max

[Peter Golis]

Všetko, čo počujeme, je len názor, nie fakt. Všetko, čo vidíme, je len perspektíva, nie pravda.

Marcus Aurelius

[Max]

Jistě vaše ignorantstvo.
Zdar Max

[Bedňa]

Je to blázen čo tvrdí, že už nepoužíva alkohol, ale nahradil ho fetom. Nie nechcem sa vysmievať jemu a ani jemu podobným, je to dosť ťažké žiť s takou diagnózou. To len na objasnenie.

Nepoznám ho priamo, len cez svojho kámoša.

[Peter Golis]

Tak pozdravuj tvojho kamoša. A odkáž mu, že sa ho pýtam: Kedy som podľa teba tvrdil že som nahradil alkohol fetom?

[karel]

S ZFS se to má ještě maličko jinak.... SUN uvolnil zdrojové kódy Solarisu a fs ZFS pod svobodnou licencí... Na základě toho, za veliké pomoci vývojářů Solarisu, vznikl OpenSolaris (ten jsem dlouho používal).Potom bohužel SUN koupilo ORACLE, a další vývoj ZFS a Solarisu opět uzavřela... Nicméně verze ZFS, která byla uvolněna že strany SUN zůstala svobodná, a od té doby se vyvíjí jako samostatná větev, je bohužel nekompatibilní, takže tu máme dvě různé odnože ZFS!!! Jednu uzavřenou, jednu svobodnou, ale vzájemně nekompatibilní.. Verze ZFS, o které hovořil Linus, je svobodná, a nevím, proč má takové výhrady.. Dalším bodem zdejší diskuze je NEXENTA... Tato firma a stejně se jmenující OS vznikl po uvolnění zdrojových kódů Solarisu. Tento OS vycházel z kódu OpenSolarisu, ke kterému přidal další věci,které již byly placené.. Po uzavření OpenSolarisu vznikl projekt Illumos, který přepsal jádro OpenSolarisu pod svobodnou licencí. Na jeho základě vzniklo spousta systémů, např. OpenIndiana, a rovněž i Nexenta přešla na toto jádro. NEXENTA, stejně, jako ostatní, kteří vycházeli z nového jádra Illumos, začali používat ZFS jako výchozí FS, a NEXENTA do tohoto kódu rovněž přispěla...Ale rozhodně není pravdou, že by byla ho hlavním tahounem.... To jen tak ve zkratce k historii....

[Peter Golis]

Otvorene implementácie ZFS pre Linux boli dve: ZFS-Fuse a ZoL. Toľko na doplnenie.

[trekker.dk]

Verze ZFS, o které hovořil Linus, je svobodná, a nevím, proč má takové výhrady

Protože dle většinového výkladu (významnější výjimkou je pouze Canonical - Ubuntu) je licence CDDL nekompatibilní s GPL a začlenění tudíž není možné z právních důvodů (a případné problémy by se pak přenesly na všechny uživatele Linuxu, protože by používali kód v rozporu s licencí.)

Druhým problémem je, že si v některých ohledech si ZFS hraje na vlastním písečku, přičemž v linuxovém jádře dlouhodobě platí, že pokud má někdo lepší implementaci pro nějakou oblast, tak ji má do jádra dát jako obecnou funkcionalitu pro všechny, ne si ji sušit jen pro sebe. To je nicméně podružné a hlavním problémem je odstavec výše.

[trekker.dk]

Kdyby to chtěli obejít, tak to můžou udělat jako všichni ostatní - dotáhnout to jako zdrojáky a přeložit přímo na systému zákazníka.

[Michal]

Ma dneska vlastne jeste TRIM prakticjky vyznam? Dnesni (nebudgetove) SSD maji SLC cache takze zapisy (pokud jich neni prilis mnoho v kratke dobe) stejne konci na "interne trimovane" SLC casti.

[Nikola Ciprich]

thin provisioning?

[Peter Golis]

Skôr to má význam keď si človek potrebuje naplánovať výkon, a nechce aby mu bol ten disk spomalený nevhodne načasovaným TRIMom.

Akurát som s tým Thin Provisioningom fajnovo zaseknutý pri testovaní výkonu medzi zatmením mesiaca, filmom a večerou.

[Peter Golis]

Pokiaľ si chceš na SSD naliať napríklad zálohu ktorá má ~64G, tak sa to spomalenie prejaví. A kľudne sa to spomalí aj 5x.

[snajpa]

Ja bych radil lidem obracene - nepouzivat Linux. Jenze to se ve svete linych dockeristu dost blbe nekomu vysvetluje.

V projektu neexistuji bezpecnostni chyby, bezpecnostni chyba je proste "chyba", kterou mozna nekdo nekdy opravi.

Navrh featur, ktere Linux dostava, se podrizuje tomu, co se tihle chytri panove uraci prijmout, i kdyz se casto nabizi lepe promyslene alternativy a lepsi napady na dany pristup, workflow celeho projektu zahazuje a pali uzitecnou praci tech, co by mohli prinest neco noveho a jen vyzdvihuje ty, kteri tupe nasleduji a nesnazi se toho prilis menit.

A ten GPL fasismus je pak uz jenom tresnicka. CDDL je svobodna licence, at si strejda Linus mysli, co chce.

A jak rikam, jeste chvili mne bude srat a setupnu proste mirror Linuxu, kteremu bude automaticky cela GPL-only sarada proste stripnuta a bude mi to jedno.

Kdyz patch, co odstranuje hlidani GPL licenci, bude tez pod GPL licenci a cely vysledek bude ven pod GPL licenci (a nebude se jmenovat Linux), muzou mi tak akorat vycadit pr...

[snajpa]

The benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?

To je uplne stejna liga jako bezna demagogie od trollu tady na Abicku

To se teda blejsknul

[trekker.dk]

Ja bych radil lidem obracene - nepouzivat Linux. Jenze to se ve svete linych dockeristu dost blbe nekomu vysvetluje.

Alternativy? Požaduji binární distribuci software a dostatečně aktuální vývoj, ne čekat třeba na podporu hardwarové virtualizace několik let jako to bylo u FreeBSD

V projektu neexistuji bezpecnostni chyby, bezpecnostni chyba je proste "chyba", kterou mozna nekdo nekdy opravi.

Úmyslně dezinterpretujete...

Navrh featur, ktere Linux dostava, se podrizuje tomu, co se tihle chytri panove uraci prijmout, i kdyz se casto nabizi lepe promyslene alternativy a lepsi napady na dany pristup

Protože snajpa ví víc, než desítky lidí, kteří se v oboru pohybují desítky let a mají trochu víc rozhledu, než je provozování vpsfree. Btw. jakpak jste vyřešili to, že sync() zavolaný z jedné virtuálky synchronizuje celý filesystém hostitele? Trefím se, když budu hádat, že patch v jádře je, že sync() teď nedělá nic?

A ten GPL fasismus je pak uz jenom tresnicka. CDDL je svobodna licence, at si strejda Linus mysli, co chce.

Citujte strejdu Linuse, kde tvrdí, že CDDL svobodná není. Podstatné je, že je GPL nekompatibilní, tj. začlenění kódu by přineslo problémy.

Kdyz patch, co odstranuje hlidani GPL licenci, bude tez pod GPL licenci a cely vysledek bude ven pod GPL licenci (a nebude se jmenovat Linux), muzou mi tak akorat vycadit pr...

Jste jak vzteklé děcko, respektovat práci a vůli jiných lidí je tak nějak základní slušnost.

[snajpa]

No, treba treba pokud pouziju ZFS v NixOSu, patchne se mi kernel a par GPL-only exportu uz najednou neni GPL only

Co ted s tim, kdybychom meli respektovat kazdeho do posledni tecky, co si kdy vymysli, uz by se to v te chvili ani v tech distribucich, co na to jdou takhle od lesa, nemohlo jmenovat Linux.

Snajpa ty veci vidi uplne podobne, jako treba takovy Canonical, akorat pro vetsinu lidi naokolo je to proste byznys, radsi jdou a prodaji podporu jejich Ubuntu se ZFS nekolika firmam, nez aby se ti, co tenhle nazor nosi, zdrzovali nejakym spamovanim Abclinuxu.

A jinak jo, sync(2) v non-init user-ns proste nedela nic, protoze zase, detto, to same - nekdo jde po meritu veci a nekdo se rad toci na technikaliich, jako je videt v celem tomhle komentu, Trekkere ;)

Realita je takova, ze sync(2) pouzivaji jen stare init systemy pri vypinani stroje, vsechen ostatni software davno pouziva syncfs() nebo fsync(). Dalsi realita, se ZFS, je, ze FS je vzdy v konzistentnim stavu a sync provadime jednou za 5s, v nasem prostredi by byl "korektni" fix pockat takovou dobu * safety_margin, ale vzhledem k tomu, ze jedine dve veci, co volaji kdy sync, jsou init systemy Void a Alpine Linuxu, je to jedno a staci patch na 2 radky s nulovou rezii okolo.

A jako, mit po ruce par vyvojaru, aby bylo cas tyhle veci delat uplne-el-correcto-poradne, skoncime nejspis opravdu s dlouhodobym forkem Linuxu, ne ze o nem jenom sem tam zatouzim v diskuzich na Abicku...

[trekker.dk]

kdybychom meli respektovat kazdeho do posledni tecky, co si kdy vymysli, uz by se to v te chvili ani v tech distribucich, co na to jdou takhle od lesa, nemohlo jmenovat Linux.

Ale mohlo. Ono asi nikdo - a určitě ne autoři GPL kódu - nechce, aby si distribuce nemohly upravovat jádro dle svých potřeb. Ale někteří z těch, co píšou GPL kód, si přejí, aby ostatní buď přispívali stejným způsobem, nebo jejich kód nepoužívali, ale napsali si vlastní. Pak ovšem přijdou ukřičená děcka s tím, že mají nárok si cizí práci přivlastnit za svých vlastních podmínek. A ještě se plácají po zádech, jak to tím patchem krásně vyřešili.

[wolf]

> sync provadime jednou za 5s

Pockej, proc potom shutdown alpine vps trval pres 20 minut pokud to bylo tim ze cekal na sync? Co mi unika?

[snajpa]

Protoze sync(2) znamena syncnout vsechny mounted filesystemy, jenze na vetsine vpsAdminOS nod je tolik mountu overlayfs, ze proiterovat je vsechny a vsechny nad nima otevrene inody, aby 'se ve finalne nic nestalo', trva i tech 20 minut. OverlayFS nad ZFS v nasem setupu totiz znamena, ze se vsechny zmeny dostanou k ZFS tak, aby je syncnulo normalne v ramci asynchronnicho syncu rozdelanych transakci (jednou za 5s). Bezna semantika je zachovana, ale ze sync(2) z kontejneru jsme udelali noop.

Jak rikam, spravnejsi by bylo pockat tech 5 a neco sekund pri sync(2) callu - v dalsi verzi toho patche to asi dopadne, ja s tim mam dalsi plany a tohle bylo jen hotfix reseni - a takove budeme delat vcelku casto, obzvlast, jakmile rozchodime live patching s nasi buildovaci masinerii, to se pak takovehle veci budou dat resit za behu. To z toho Trekkerovi asi rupne prava koule

Ale jinak je to bezna praxe. Doporucuju se podivat treba na kernel Canonicalu a TODOs v jejich patchich :D

[trekker.dk]

Dokud mi nerupne v bedně jako vám, tak jsem v pohodě.

Ale to, že budete věci řešit, bude určitě příjemné překvapení... oproti současnému stavu, kdy se známá chyba jádra, u které je jasné, že dřív či později sestřelí produkční server v náhodnou denní dobu, řeší tak, že se prostě počká, až se to stane, a pak se ten server resne. Přece se nebudeme obtěžovat s noční odstávkou, že...

[Trach86]

Hmm. Unikátní vlastnosti ZFS, pro které nemám ve Windows náhradu (RAIDZ2 + send/receive na NAS pro velmi efektivní zálohování velkých souborů, které se relativně pomalu mění), mě na desktopu držely u Linuxu. No ale když Linus říká, že to nemám používat, tak jdu teda do těch Windows. Když se zakážou updaty a potuní se pár věcí, tak nejsou na desktopu zas tak špatné. A jako velký bonus - není tam systemd

[snajpa]

OpenZFS on Windows

[Max]

Jo, před nějakou dobou jsem na to koukal, že se toho někdo ujal :). Zatím to vypadá, že je to ve stavu : "mám štěstí, že jsem se střelil jen do nohy a né do hlavy." :D.
Zdar Max

[Max]

Myslím, že ti to nikdo rozmlouvat nebude :).
Zdar Max

[Milan_M]

Proto mam Windows v KVM, s vlastni GK, 2x mirrorem(hdd a ssd) a nejake zaskobtnuti Windows vyresim vracenim snapshotu.

[Trach86]

Přežije tenhle setup (host i guest) uspání/probuzení (suspend to ram) hosta?

[Milan_M]

Hm, ne, AMD-Vi začně nadávat, možná to bude kvůli huge-pages, kdo-ví.

[Odin]

Kdyste používali reiserfs, nemusíte řešit tyhle problémy s korporátníma sračkama.

[Max]

Kdyby si Reiserfs uměl ohlídat konzistenci dat a btrfs uměl rozumně dělat pooly, tak by ZFS na Linuxu nebylo tak řešívané.
Zdar Max

[Odin]

Kdyby se do toho nezapletla ruská štětka, mohlo být dávno hotovo.

[Michal]

Co s tim ma spolecneho Putin?

[Max]

Zřejmě předřečník narážel na to, že Hans Reiser zabil svojí manželku a musel jít bručet. A jeho manželka byla Ruska.
Zdar Max

[_]

Ruská prostitutka. Koupil si ji na eshopu.

[Aleš Kapica]

A nejspíš mu nevyšel pokus o reklamaci.

[David Heidelberg]

ReiserFS jsem zkoušel už dost dávno, jenže jednoho dne mi spadnul Linux a přišel jsem o všechno (v patnácti jsem nezálohoval). fsck nepomohl. Fakt jsem tenkrát měl chuť vraždit. No pun intended.

[Max]

Mně se snad nikdy nestalo, že by se mi FS rozpadl sám od sebe takovým způsobem, že by z něj nešly vytáhnout ani data. A celý roky jsem jel vesměs jen na Reiserfs. Celou éru ext3 i ext4. Pak jsem přešel na btrfs. Jediné místo, kde používám ext4 je ve VM případně na systémech jako oracle apod., kde je pár GiB programů a data to mám na svém vlastním FS.
Jediný případ, kdy jsem přišel o všechny data bylo, když mi spolubydla nastavil sw raid přes všechny disky. Toto menu nešlo při bootu pc zaheslovoat (blbá deska).
Prý to udělal omylem, byl to i PC analfabet, takže tomu i věřím, ale dodnes netuším, jak to dokázal.
Zdar Max

[trekker.dk]

Jako benchmark spolehlivosti filesystémů používám naše zálohovací servery. Jediný filesystém z trojice Reiser - XFS - ext, který se na nich ještě samovolně nerozbil do takové míry, že bylo jednodušší ty zálohy zahodit a začít znovu, je ext4.

[Majkls]

Docela by mě zajímalo, kolik lidí skutečně to vlákno četlo. Docela Linusovy argumenty chápu. On Oracle umí docela trollit, když de o licence, takže celkem chápu, proč od toho dává Torvalds ruce pryč. Druhá věc, jak se k tomu staví maintaineři toho kterého distra. V té chvíli je to ale jejich odpovědnost.

A pakliže je mimo hlavní strom, je na maintainerech balíku to udržovat a není to odpovědnost vývojářů kernelu.

Je škoda, že teda není po tom čase dotažený btrfs, že by nebyl vůbec důvod používat ZFS na Linuxu. Protože to tam někteří lidi uvádějí jako důvod, proč jej používají.

[Max]

Já to četl a Linuse chápu a souhlasím s ním. Na druhou stranu i Linus ukázal, že nechápe, proč lidi ZFS v Linuxu chtějí. Vyslovil tam něco s benchmarkama, kde ZFS nemá moc oslnivé výsledky, přitom o tom to vůbec není. Je to o tom, že Linux zatím nemá pro ZFS žádnou alternativu. Prostě nic, na čem by se dal postavit storage ve stovkách TiB, resp. daleko přes PiB s plně ošetřenou konzistencí dat, rozumným výkonem a redundancí disků.
BTRFS dobrý, do produkce bych se s ním nebál jít (a už před hafec lety jsem s ním do produkce šel), ale jak mám s btrfs poskládat třeba 100TiB pole z 33ks 4TB disků? U ZFS udělám 4x8 RAIDZ2, to celé dám do jednoho poolu a mám 100TiB pole s možností výpadků 2-8 disků + 1x spare. Můžu něco podobného udělat s btrfs? I když budu věřit RAID6 implementaci v BTRFS, kterou lidi používají a nemají problémy (i když simulují výpadky a další věci), tak jak na to? A pak tu máme věci jako problém s výměnou disku za běhu.
Na Linuxu tedy můžeme doufat, že se BTRFS dostane do stádia, kdy bude použitelné na něco většího, nebo můžeme začít věřit ve Stratis, kde se Redhat snaží doboostit XFS. Nicméně na produkci to ještě dlouho nevypadá.
Další možnost je vykašlat se na lokální storage a přejít na něco cloudového, něco jako Ceph apod., kde jsme ale s výkonem zase někde jinde a potřeba hw je také někde jinde.
Na storage řešení tedy stále vede FreeBSD + ZFS, případně někteří odvážlivci ZoL.
Zdar Max

[Heron]

Je to o tom, že Linux zatím nemá pro ZFS žádnou alternativu.

Je to o tom, co si kdo představí pod pojmem storage a co od toho očekává a co je ochoten akceptovat.

Na rootu včera vyšel první díl seriálu o btrfs a ačkoliv nevím, jak to bude vypadat dál, vidím v tom náznaky toho, jak se někteří lidé na storage obecně dívají. A je to pro mě trochu skličující. Uvádí tam, že BTRFS má raid. Ne BTRFS nemá raid, btrfs je multidevice fs a to je naprosto klíčové. Kdykoliv přidám disk, kdykoliv jej odeberu. To je to podstatné, ne to, jestli raid-1 znamená mirror přes dva disky nebo přes všechny. Podstatná je ta flexibilita. Stejně jako je podstatná flexibilita ve vytváření subvolume / snapshotů. To je zásadní rozdíl od starých FS typu ZFS, kde si opravdu nemůžu dropnout jakýkoliv dataset, který má clone nebo snapshot. O odebrání disku z některých typů vdevu ani nemluvě. Ta flexibilita umožňuje úplně jiné myšlení.

A pak tu máme věci jako problém s výměnou disku za běhu.

Ten článek je skoro 5 let starý. A řešení tam naznačuji: "můžu mít disky v hw nebo software raidu1 a potom mít v btrfs raid0. Btrfs nikdy výpadek disku neuvidí." Pro mě tohle prostě není téma.

A neslyšel jsem tolik nářků na neexistenci RAID-5/6 než s BTRFS. Nikdy před tím jsem neslyšel, že by lidé chtěli tak moc používat RAID-5 než až se dozvěděli, že btrfs raid-5 nezvládá. Najednou to každý strašně nutně potřeboval (a řešení mdadm raid-5 a nad tím btrfs nebylo nějak po chuti, zatímco totéž s ext3 bylo akceptovatelné). Totéž jako s IPv6. Hromada lidí mluví o 128b jako nedostatečném a dělení na 2x64b je nesmysl a raději zůstanou u IPv4 (32b), než někdo nevymyslí něco lepšího.

Pro mě je jediné storage řešení na úrovni RAID-10. V případě btrfs multidevice raid-1. Paritní raidy mě nezajímají. Totéž u ZFS, přidávat další mirror vdevy.

nebo můžeme začít věřit ve Stratis, kde se Redhat snaží doboostit XFS

Nejen XFS. Ale i dm a md. Nemám nic proti tomu projektu, ale mám hodně proti tomu se tvářit, že to jsou oddělené vrstvy u kterých je "jenom potřeba doplnit trochu víc obousměrné komunikace". Takže to vlastně už nejsou vrstvy ale monolit. Osobně si myslím, že správná cesta je se na toto vykašlat, disky brát jen jako storage pro bloky (4k, 1M. 1G, cokoliv se hodí) a nad těmito bloky vytvořit pool (podobně jako LVM VG) a až nad ním tvořit volitelnou redundanci. Něco jsem popsal v tomto textu.

a přejít na něco cloudového, něco jako Ceph

CEPH má defaultní redundanci 3 kopie a najednou raid-5 nebo 6 nechybí? Jinak CEPH je daleko náročnější projekt, než si kde kdo myslí. Nám se to podařilo na počkání kdykoliv shodit. Je možné, že se něco změnilo, rok a půl jsem to neviděl, ale před tím se nám podařilo zlikvidovat cephfs i rados block device (object api jsme nezkoušeli, to tehdy nebylo na pořadu). Někdo (trekker.dk) tvrdil, že qemu driver je OK, to jsme netestovali. Ten projekt podle mě není dobře vedený, viz jen historie backendů: měli vlastní storage, potom doporučovali ext, btrfs, xfs a opět vlastní storage. Takhle se s daty nezachází. Podobné projekty obvykle používají něco naprosto primitivního (ext2) a v případě problémů to rovnou zahodí a zreplikují znovu. Jestli se "storage cloud jánevímco" neumí za 14 let ani rozhodnout na backendu, tak je něco špatně. Nefunguje ani frontend (dva ze tří).

[Max]

BTRFS bývá hodně porovnáváno se ZFS a to bývá hodně porovnáváno s WAFL (NetApp).
NetApp má RAID-DP (což je něco jako RAID6/RAIDZ2), ale má hodně malý performance impact. Dále ještě nabízí RAID4, ale s NetAppem se asi vesměs jede hlavně RAID-DP. My to tak v produkci taktéž máme a ten výkon, co to pole podává při tak malém počtu SAS disků je opravdu docela slušný.

Ale jak už jsem psal, co pro big storage nabízí BTRFS? Nic. Jak s ním postavím 100TB storage? Nepostavím, né rozumně. multidevice RAID-1 je na nic, čím větší pole, čím více disků, tím je větší šance, že odejdou dva nevhodný a je konec. Prostě u RAID1 může odejít jen 1+n disků (ano, záleží, jak si to btrfs rozhodí, ale je to pravděpodobné), což je pro spoustu nasazení neakceptovatelné. A skládat pole z RAID1 ze třech kopií, to je ukrutně drahý a samotné RAID10 je také drahé. Se ZFS poskládám pomocí více RAIDZ2 docela slušný pole (slušný poměr kapacita a výkon v IOPS).

HW RAID, nebo mdadm je pak jen poloviční řešení, protože pole nebude na všech úrovních odolný proti silent data corruption. A u toho mýho 100TB ZFS pole mi scrub někdy opraví i 4MiB dat.

Já proti btrfs nic nemám, sám ho používám, znám jeho filosofii, ale btrfs není konkurence pro ZFS v případě velkých storage.
Představ si PiB pole. Jak by jsi ho poskládat s BTRFS, když by jsi chtěl být co nejvíce chráněn proti silent data corruption? Jeden velký pool s jednou kopií dat? To by bylo docela drahý a když by odešly nevhodné disky, tak by nastala i ztráta části dat. Podle mně prostě BTRFS nemá dobré řešení redundance dat u velkého storage.
Zdar Max

[Heron]

Jak jsem psal, já i ZFS pole skládám přidáváním vdev mirrorů. Nelíbí se mi, že raid-z už nelze nijak pohnout (ano, něco je ve vývoji) a nelíbí se mi nemožnost odstranění vdevů (ano, formálně jdou odstranit, ale ve skutečnosti se to jen převede na interní ro vdev a ten se rozprostře na zpool - nedovedu si představit, jak to bude vypadat po x desítkách odstranění). V tomto je btrfs mnohem flexibilnější.

Souhlasím s tím, že by btrfs pomohla volitelná redundance. Tedy místo aktuální redundance přes dva disky bylo možno nastavit libovolný počet kopií (až do počtu zařízení), která se mají ukládat. Na paritní raidy bych se úplně vykašlal.

Ale stejně by to bylo jen na půl cesty. O dost vyšší redundance lze dosáhnout až s více stroji. Dělat na jednom stroji 1PiB pole je blbost, to už je lepší 10x100TiB. Tak se zabrání selhání HW nejen pro případ výpadku disku, ale také i selhání dalšího HW.

[trekker.dk]

CEPH má defaultní redundanci 3 kopie a najednou raid-5 nebo 6 nechybí?

Ale no tak, takovýhle logický klam je přece jenom trochu moc průhledný... defaultní redundance neznamená, že chybí raid-5.

viz jen historie backendů: měli vlastní storage, potom doporučovali ext, btrfs, xfs a opět vlastní storage. Takhle se s daty nezachází.

Mhm... já bych teda řekl, že s daty se zachází tak, aby nebyla ztracena, nemají-li být. Historie backendů na tomto nic nezměnila, migrace je samozřejmě možná za běhu...

[Heron]

defaultní redundance neznamená, že chybí raid-5

On CEPH nabízí nějaké partitní raidy? Klidně se nechám poučit, co jsem to viděl naposledy, tak uměl jen celé kopie dat.

migrace je samozřejmě možná za běhu

No to možné je, ale to nemění nic na mém subjektivním názoru, že projekt (libovolný) jehož podstatná část se mění příliš často, není příliš dobře veden. To nesvědčí o dobré analýze problematiky a pokud se to stane po x-té, tak by to mělo někoho trknout a měl by se zrevidovat postup výběru dané technologie. Já prostě mám rád dlouhodobě stabilní projekty, kde někdo na počátku dlouho přemýšlel a není nutné podstatné komponenty radikálním způsobem měnit. Někdo to může mít jinak, CEPH umožňuje měnit typy OSD za běhu, takže to pro někoho nemusí být takový problém.

[trekker.dk]

On CEPH nabízí nějaké partitní raidy?

Paritní raidy ne, místo toho je tam erasure-coded pool, tj. kombinace k stripů a m opravných kódů, kde k a m volí uživatel. Je to tam od roku 2014 (pro RBD a CephFS od 2017.)

Já prostě mám rád dlouhodobě stabilní projekty, kde někdo na počátku dlouho přemýšlel a není nutné podstatné komponenty radikálním způsobem měnit.

Na druhou stranu není špatné, když projekt může něco, co se nehodí pro daný účel, vyhodit, protože to nefunguje a dá se to udělat lépe. Krom toho se nejednalo o žádné radikální změny, to byla až ta poslední, kdy skutečně použili vlastní storage. To předtím bylo bylo jenom hledání optimálního filesystému, princip ukládání dat se neměnil. Akorát se ukázalo, že žádný takový fs není. (Hádám, že potřebovali ušetřit na vývoji a až po letech měli dost velké příjmy na to vytvořit si vlastní storage.)

[Heron]

Jasně, The erasure-coded pool crush ruleset targets hardware designed for cold storage with high latency and slow access time. Takže v podstatě pro archivy, které se moc nebudou číst ani měnit. OK.

Na druhou stranu není špatné, když projekt může něco, co se nehodí pro daný účel, vyhodit, protože to nefunguje a dá se to udělat lépe.

Tak to každopádně.

To předtím bylo bylo jenom hledání optimálního filesystému

Za 10 let 5 FS. Na počátku vlastní FS (EBOFS), potom btrfs (2008 - to byl snad rok na světě?), někde s tím ext3, potom xfs (2012) a potom vlastní BluStore.

Nedohledal jsem, jak dlouho na tom pracovali, ale tak něco kolem 4 let max a v 2017 už je to default OSD (ano, lze použít i XFS). Ale tak jistě, udělat object storage + mini fs pro embedded db (RocksDB) je určitě trivka, to se dá za 4 roky zvládnout.

vlastní storage

Což ve mě vzbuzuje ještě méně důvěry. Udělat robustní FS trvá prostě dlouho, XFS je tu s námi od roku 1994. Nepřijde mi moc rozumné si myslet, že dovedou vyrobit interní FS pro RocksDB (takže fs s naprostým minimem uživatelů, zatímco ostatní FS dostávají nakládačku v běžném provozu, tak tady ne) a k tomu ještě block storage (ok, ten je jednoduchej).

Ale tohle je prostě přístup toho projektu no, kdo to akceptuje, ať to používá, zase je potřeba říct, že jsou v tomhle konzistentní. Nejdřív si spíchnou vlastní FS, potom použijí novorozeně btrfs (necelý rok staré), potom určitě po dávce patchů od RH v roce 2012 doporučí XFS (takže vlastně taky dost mladej fs) a potom opět hurá na vlastní storage. Každopádně je zajímavé to sledovat

[trekker.dk]

The erasure-coded pool crush ruleset targets hardware designed for cold storage with high latency and slow access time. Takže v podstatě pro archivy, které se moc nebudou číst ani měnit. OK.

No jo, počítat kontrolní součty při zápisu a tahat data ze všech disků při čtení je pomalejší než pracovat s čistými kopiemi... to bych považoval za vlastnost, stejně jako u raid 5 a 6. (Kromě hardwarových řadičů, kde je to občas vylepšené tím, že to počítá dedikovaný čip.)

Za 10 let 5 FS. Na počátku...

Udělat robustní filesystém určitě není trivialita, ale o filesystém se v podstatě nepokouší, protože většina funkcionality běžných filesystémů tady není potřeba. Proto taky ustoupili od ukládání dat na filesystémy, mělo to zbytečně velkou režii za věci, které duplikovaly to, co ceph dělal sám.

Ale tohle je prostě přístup toho projektu no, kdo to akceptuje, ať to používá

Pár let, kdy se v podstatě na odpadní hardware, který už k ničemu nebyl, denně odleje 600GB záloh - zatím bez problémů.

[Heron]

Pár let, kdy se v podstatě na odpadní hardware, který už k ničemu nebyl, denně odleje 600GB záloh - zatím bez problémů.

Jasně, to je asi ok. U nás jsme se pokoušeli to nasadit jako produkční storage pro vmware a tam bylo špatně vlastně úplně všechno. (Už jsme se tu o tom hádali.) BlockDevice (připojení přes iSCSI) padal, CephFS export přes NFS padal, dokonce jsme zkoušeli připojit CephFS do jednotlivých VM, to taky padalo. Tím jsme vyčerpali všechny možnosti. Cílem bylo mít storage pro vmdk pro vmka, ideálně tedy blockdevice a isci, v nejhorším na nfs (tak jak nám to běželo roky před tím na ext4 + nfs export do vmware), takže už nebylo co dál testovat.

Osobně si myslím, že nejlepší použití je pro S3 API object storage, ale to se pro naše nasazení nehodilo.

Ty to láduješ na ten CephFS? Jak to máš připojené, do všech zálohovaných strojů, nebo naopak ty data sypeš na jeden ceph node?

[trekker.dk]

U nás jsme se pokoušeli to nasadit jako produkční storage pro vmware a tam bylo špatně vlastně úplně všechno...

Jo, o RBD ovladači v kernelu pár let zpátky mluvil někdo na Linuxdays (asi), že je naprosto k h-u. O CephFS nevím nic, ale hádám, že jaderný ovladač na tom bude úplně podobně. Tipuju, že vývojáři Cephu na přispívání do jádra kašlou, protože je to náročnější a/nebo to není jejich hlavní use-case - např. RBD ovladač v jádře 4.19 z Debianu Buster nepodporuje věci, které Ceph umí už léta.

Jinak přidali vlastní iSCSI bránu https://docs.ceph.com/docs/master/rbd/iscsi-overview/ , ale nezkoušel jsem, na Stretchi byl moc starý user space.

Ty to láduješ na ten CephFS? Jak to máš připojené, do všech zálohovaných strojů, nebo naopak ty data sypeš na jeden ceph node?

Jedna Qemu virtuálka, 10 RBD zařízení, každé připojené zvlášť přes userspace knihovnu (driver=rbd), v tom virtuálu jsou to pak všechno scsi-disk pověšené na virtio-scsi. Nic pro VMWare, ještě by lidi mohli chtít neplatit za jejich software-defined storage a místo toho používat tohle.

[Heron]

Jedna Qemu virtuálka, 10 RBD zařízení, každé připojené zvlášť přes userspace knihovnu (driver=rbd), v tom virtuálu jsou to pak všechno scsi-disk pověšené na virtio-scsi.

To je teda zvláštní řešení pro zálohy. Proč do virtuálky? Proč 10 blockdevice? Co potom s tím v té virtuálce, to spojíš (LVM?) a nad tím nějaký normální FS?

Já teda pro zálohy volím co nejjednodušší řešení, většinou jen hw raid, co nejstandardnější fs (xfs) a je to. Zálohované stroje at si připojí svůj nfs chlívek, nebo tam ta data pošlou jinak (backuppc), na zálohy vmware nakivo. V některých variantách se k tomu připojí i pásková knihovna, data má rovnou na místním disku, takže no problemo.

[sigma]

Zálohované stroje at si připojí svůj nfs chlívek

Tohle se mi nelíbí kvůli tomu, že když je zálohovaný stroj nějakým způsobem napaden, může útočník smazat (nebo v horším případě jen tiše poškodit) i tu zálohu. Pokud to dále odlévám na pásky, tak to až tak nevadí. Jiné řešení je na tom zálohovacím stroji dělat snapshoty, ale to na XFS (+LVM) ve větším moc efektivně nejde.

Zálohovací storage se často využívá i jako archiv, ze kterého musí být snadné obnovit určité soubory nebo nějakou část FS k určitému datu. K tomu jsou ideální právě snapshoty, a to je pro mě důvod proč použít ZFS nebo Btrfs.

Pokud snapshoty na úrovni storage nemám, používám rsync iniciovaný ze zálohovacího systému, který má na zálohovaný systém přístup přes SSH s možností spustit jen rsync sender v read-only režimu. Plus link-dest pro držení historie, ale to funguje jen po celých souborech. Home a mail storage pro pár stovek uživatelů má pár TB a desítky milionů souborů. Tam už je rsync dost na hraně, aby se vůbec stihnul z LVM snapshotu přes noc. Pro takové situace je send/receive ze ZFS neocenitelný. Na Btrfs už to možná spolehlivě funguje taky?

[Heron]

Tohle se mi nelíbí kvůli tomu, že když je zálohovaný stroj nějakým způsobem napaden, může útočník smazat (nebo v horším případě jen tiše poškodit) i tu zálohu. Pokud to dále odlévám na pásky, tak to až tak nevadí.

Ano, odlévá se to, přesouvá mimo dosah NFS apod.

Zálohovací storage se často využívá i jako archiv

Tohle se zase nelíbí mě. Archiv a záloha jsou kompletně jiné úlohy. Na archiv má být vyhrazený stroj / pásková knihovna. Z archivu by nemělo být potřeba vyzobávat jednotlivé soubory.

Na Btrfs už to možná spolehlivě funguje taky?

Co send / receive? To mi fungovalo vždy (tedy minimálně od roku 2013). Ale na zálohy to nepoužívám, používám to na přesun kontejnerů mezi stroji. Zálohy btrfs snapshotů, pokud chci zachovat jejich historii, tak používám SquashFS. Pozor, poslední verze z roku 2019 obsahuje bug, který poškodí výsledný soubor a není možné appendovat. Dá se tomu zabránit volbou -no-xattrs. Předchozí verze 4.3 z roku 2014 je OK.

[sigma]

Na archiv má být vyhrazený stroj / pásková knihovna.

Pokud nechci řešit pásky, tak to znamená jeden systém na backup + další systém na archivy. Oba s velikostí storage srovnatelnou nebo násobnou než velikost provozních dat. To mi přijde zbytečně nákladné. Většinou to řeším v podstatě archivním úložištěm se snapshoty zhruba 10-30 dnů zpět a 24 měsíců zpět. Nebo něco mezi tím. Z online archivů se pak dělají offline zálohy postupně na několik externích HDD, které se po dokončení kopírování odpojují a odnáší fyzicky jinam.

Z archivu by nemělo být potřeba vyzobávat jednotlivé soubory.

A k čemu jinému by měl být? V našem use-case je vytažení jednotlivých souborů 90% případů využití archivu. Jedná se o home storage a maily - omylem smazaný nebo poškozený soubor/mail, který "tam určitě byl někdy před měsícem"; rozdrbaný Windows roaming profile, který uživatel ohlásí po týdnu; nebo pár archaických aplikací, která drží data v souborech a občas někdo potřebuje zreprodukovat stav jak byl před dvěma měsíci.

Přes Sambu je možné takové snapshoty zpřístupnit i přímo uživatelům, a někteří se s tím i naučili dělat a používají to poměrně často.

[Heron]

A k čemu jinému by měl být?

Ok, tak tomu já říkám záloha, archiv je u mě něco jiného. Záloha je provozní, archiv je dlouhodobý. Viz 76

[Heron]

Ještě možná dodatek. Já rozlišuju image, zálohu a archiv.

Image (cat /dev/sda > soubor) se hodí všude tam, kde budu chtít obnovit stroj do zcela stejného stavu (typicky windows stroje, ntb se mi fakt nechce přeinstalovávat), takže mám několik image, tři měsíce dozadu.

Potom je to záloha a zálohu dělám do jiného FS, než je původní. Proto i ten BTRFS dávám do squashfs, nebo se to kopíruje na xfs apod. (Totéž ZFS.) Tak nejde o dokonalou kopii, ale o data a je to spíš pro případ náhodného smazání nějakého souboru uživatelem.

No a archiv je k uložení stavu projektu většinou po jeho dokončení. Aby se o to nepřišlo. To není určeno k okamžité obnově do produkčního stavu (taky to jde), ale o zachování dat a souvislostí mezi nimi. Takže do archivu jde repositář (svn / git), snímek develu, snímek produkce, dokumentace, tickety apod. jako ucelená kolekce patřící k sobě.

Jinak dělal jsem tohle mezi BTRFS (zdroj), ZFS (cíl) a úplně na férovku, ZFS to nezvládá. Zatímco na BTRFS jsem míval i desetitisíce snapshotů uložených na disku, tak tohle pro tři stroje nevydrželo ani rok (tj 3x365). ZFS nemá rádo mnoho snapshotů, potvrdil jsem si to loni během psaní této minisérie, ještě k tomu mám pár poznámek.

Prostě na stejném stroji, kde jsem měl před tím linux a btrfs a desítky tisíc snapshotů je teď ZFS (ve skutečnosti s rychlejšími disky) a ZFS nemá rádo velké množství snapshotů a projevuje se to třeba už jen na directory listingu, kdy vypsat strom o nějakých 400tis souborech trvá klidně i 3 minuty. Když se mu to uklidí, tak po nějaké době se to vrátí do normálu a je to opět během pár s.

$ time find .  | wc -l
  389469

real    0m1.835s

Loni jsem si to potvrdil asi 3x po sobě a od té doby ZFS snapshoty používám jen na nezbytně dlouhou dobu.

[sigma]

OK, jiná terminologie. Já většinou bral archiv jako zálohu, o kterou bych neměl přijít, protože plní i jiné úkoly než "okamžité" obnovení posledního stavu havarovaného zálohovaného systému. Archiv v tvojí terminologii řešíme odděleným prostorem na primárním storage, ve kterém se po dokončení projektu/období uloží nějaký dump/archiv, ale to je obvykle minimálně částečně ruční práce, a tato data změní na read-only. Pro tento prostor je nastaven robustnější zálohovací mechanismus (více cílových míst).

Ale jak u těch záloh (např. na XFS) řešíš více verzí? Myslím tím to, že záloha se dělá např. každý den, ale na smazaný soubor přijdu třeba po 3 dnech. Takže je potřeba nějaký způsob inkrementálního zálohování. Zmiňoval jsi backuppc, OK, to je jedna možnost. Pro velké datasety ze serverů mi to nepřišlo úplně vhodné. Já používám něco jako ten rsnapshot, to mi přijde celkem ideální až na ty věci co tam zmiňuješ, a proto jsem začal řešit snapshoty na úrovni FS. Takže stejná cesta jako ve tvém blogu. Vlastně to celé vzniklo jako reakce na:

Já teda pro zálohy volím co nejjednodušší řešení, většinou jen hw raid, co nejstandardnější fs (xfs) a je to

což mi nejde dohromady s tím blogem, kde zmiňuješ Btrfs snapshoty. Ale jasně, zaleží na tom, kolik těch dat je a jak se mění. Pokud ne moc, je standardní XFS + třeba rsnapshot dobrá volba.

[Heron]

Ale jak u těch záloh (např. na XFS) řešíš více verzí?

To zálohovací pole je jen storage pro jiný software. Takže se to řeší v něm. Nakivo pro vmware, backuppc pro pecka, verze si to řeší samo (a btw, backuppc verze 4 už konečně nepoužívá hardlinky, fs to používá jen pro unikátní soubory a zbytek si to řeší v nějakém interní db - takže už to není tak náročné na iopsy a zejména počítání počtu linků, což klidně běželo 24h).

Ale jasně, zaleží na tom, kolik těch dat je a jak se mění.

Spíš to záleží na tom s kým to děláš. A pokud máš lidi, kteří sotva chápou LVM, tak dělat cokoliv na BTRFS nebo ZFS a celé si to odnést na vlastních zádech, to se mi fakt nechce. Takže ve firmě se snažím všechno dělat as simple as possible a potom se vyřádím v soukromí. A ten blog je o tom soukromém řádění.

Pochopitelně soukromě využívám btrfs mutlidevice a zfs apod, tak jak to popisuju na tom webu. Ale v práci to opravdu nebudu protláčet "proti všem". Ale to nemá být kritika, když vidím, jak se dodnes píšou články o storage z pohledu z roku 1980, tak se těm lidem ani nedivím. Pokud se o to někdo nezajímá, tak má dost zkreslenou představu o tom, co všechno je možné dneska dělat. Pro mě bylo multidevice fs + nezávislé snapshoty jako zjevení a okamžitě jsem věděl, co s tím chci dělat a pro ostatní je to vlastně nezajímavé.

[sigma]

Zálohy btrfs snapshotů, pokud chci zachovat jejich historii, tak používám SquashFS.

Zajímavé, ale na několik TB a desítky milionů souborů mi to nepřijde moc vhodné. Jak jsem psal, potřebuji kvůli výkonu ideálně využit tu informaci z CoW vrtsvy FS. Xattrs (a ACL) potřebuji zalohovat taky, hlavně kvůli Sambě.

Druhý popsaný způsob se send/receive je fajn, je dobré slyšet že to funguje. Já se o to zajímal kolem 2015, a to jsem narážel na info, že to nemusí být 100% spolehlivé, ale detaily už si nepamatuju. No a právě uvedená nevýhoda, že se k obsahu dumpu nelze dostat jinak než plným obnovením, je pro můj use-case skutečně velká a nepřekonatelná. Můžu ty data možná rozsekat na menší svazky a dělat jejich dumpy samostatně, ale někdy je i ten nejmenší smysluplný blok dost velký, a postup při obnovení série snapshotů složitý na to abych vytáhl pár souborů. Musel bych si k tomu alespoň generovat nějaký katalog co se kde a kdy změnilo -- umí třeba Btrfs vylistovat soubory, které jsou v daném snapshotu změněné od předchozího?

[Heron]

No a právě uvedená nevýhoda, že se k obsahu dumpu nelze dostat jinak než plným obnovením, je pro můj use-case skutečně velká a nepřekonatelná.

Ale tak to je obecná vlastnost podobných sendů ne? Nebo ZFS lze obnovit jinak než na ZFS?

umí třeba Btrfs vylistovat soubory, které jsou v daném snapshotu změněné od předchozího?

Ano:

btrfs subvolume find-new subvolume last_gen

  List the recently modified files in a subvolume, after last_gen ID.

Je potřeba si to lehce vyfiltrovat, protože to ukazuje na každou změnu v souboru (takže soubor je tam několikrát):

inode 67479 file offset 1302528 len 32768 disk start 8972292096 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67479 file offset 1339392 len 4096 disk start 8972324864 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67479 file offset 1351680 len 12288 disk start 8972328960 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67479 file offset 1372160 len 32768 disk start 8972341248 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67479 file offset 1413120 len 40960 disk start 8972374016 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67479 file offset 1458176 len 57344 disk start 8972414976 offset 0 gen 25724 flags NONE var/log/journal/9fcd5f8535b544b28b61e1dc5e003ff5/system.journal
inode 67515 file offset 0 len 90 disk start 0 offset 0 gen 25724 flags INLINE var/lib/postgresql/9.6/main/postmaster.pid
inode 67516 file offset 0 len 8192 disk start 8972480512 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/pg_notify/0000
inode 67517 file offset 0 len 20480 disk start 8972500992 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/global/pg_internal.init
inode 67518 file offset 0 len 114688 disk start 8972521472 offset 0 gen 25724 flags NONE var/lib/postgresql/9.6/main/base/13031/pg_internal.init
inode 67519 file offset 0 len 28672 disk start 8971657216 offset 0 gen 25724 flags NONE var/lib/exim4/config.autogenerated

[sigma]

Ale tak to je obecná vlastnost podobných sendů ne? Nebo ZFS lze obnovit jinak než na ZFS?

Nevím o tom, ale o to nejde. Jde o to, jestli ty snapshoty nakonec dlouhodobě skladuju na jiném FS (třeba XFS) jako soubory, nebo jestli je rovnou aplikuju na živý filesystem stejného typu na jiném stroji. Nějak jsem si to spojil s tím, že doporučuješ zálohovat na jiný typ FS, s címž bych souhlasil, ale má to pak tuto nevýhodu.

Je potřeba si to lehce vyfiltrovat, protože to ukazuje na každou změnu v souboru (takže soubor je tam několikrát)

Díky, může se hodit.

[trekker.dk]

Proč do virtuálky?

Protože do ní jde připojit RBD

Proč 10 blockdevice?

10 oddělených filesystémů. ext4 jsem ještě neopravitelně rozbité nezažil, ale opravitelně už jo - IIRC něco jako 2 TB maildirů a nešlo se dostat do jednoho adresáře, ve kterém vlastně ani nebyla žádná data, ale i tak se samozřejmě musel dělat fsck celého toho FS, což je paráda.. Fsck na 60TB filesystému bych dělal nerad.

[Heron]

Protože do ní jde připojit RBD

Ste masochisti. Tohle já třeba nedělám celkem ze zásady, pokud to nejde připojit normálně, tj buď jako systémovej blockdevice nebo jako normální fs tak s tím končím. I kdyby RBD ve qemu fungovalo bezvadně, tak mi opravdu nepřijde normální svěřit data něčemu, k čemu vede cesta jen klíčovou dírkou. (Ještě že to nevidí Kapica, ten by považoval za normální z té virtuálky exportovat nbd a připojit to jako blockdevice na hostiteli.)

10 oddělených filesystémů. ext4 jsem ještě neopravitelně rozbité nezažil, ale opravitelně už jo - IIRC něco jako 2 TB maildirů a nešlo se dostat do jednoho adresáře, ve kterém vlastně ani nebyla žádná data, ale i tak se samozřejmě musel dělat fsck celého toho FS, což je paráda.. Fsck na 60TB filesystému bych dělal nerad.

To dává smysl. Já naposledy viděl ext4 na kolenou, když se trochu rozbilo promazávání session souborů a v jednom adresáři bylo 12milionů souborů. Mazalo se to 14 dnů. Od té doby ten fs psal directory index full, ale jinak fungoval.

[Peter Golis]

(Ještě že to nevidí Kapica, ten by považoval za normální z té virtuálky exportovat nbd a připojit to jako blockdevice na hostiteli.)

Na niečo podobného bola vyvinutá napríklad OpenDedup Appliance. Jedná sa o Virtuálne NAS ktoré má v sebe deduplikáciu a optimalizáciu na hosťovanie VMFS cez VMWare storage api.

Ď za pripomenutie, hral som sa s tým pred rokmi. Ale performance mi nedovolila. Rád si to pozriem teraz keď mám na to vyčlenený SSD a dostatok RAM, i keď to TLC s maličkou SLC Cache ...

[trekker.dk]

Tohle já třeba nedělám celkem ze zásady, pokud to nejde připojit normálně, tj buď jako systémovej blockdevice nebo jako normální fs tak s tím končím.

A povězte mi, Kefalín, čo si predstavujete pod slovem "normálně"? Zrovna pro virtualizaci je blokové zařízení zbytečné, protože je to jen mezikrok, kde kernel emuluje blokové zařízení, aby následně komunikoval se síťovou službou, což může aplikace udělat sama. Navíc virtualizace je téměř určitě víc normální využití RBD než připojení do jednoho fyzického stroje. Pak není divné, že je víc usilí věnováno tomu, aby fungovala virtualizace. (Kde virtualizace samozřejmě znamená Qemu, protože to je také projekt Red Hatu.)

[Heron]

A povězte mi, Kefalín, čo si predstavujete pod slovem "normálně"?

Třeba to, že to bude součástí kernelu, kernel modul a nebude se muset řešit to, zda to běží ve virtuálce nebo na HW. Prostě kdekoliv mám standardní kernel, tak to připojím.

Zrovna pro virtualizaci je blokové zařízení zbytečné

To si právě nemyslím. KVM virtuálky vytvářím vždy nad LV a té virtuálce může být úplně jedno, jaké jsou pod tím PV. Buď to mám na klasických diskách, nebo ssd, nvme, nbd, drbd, iscsi, ale ta virtuálka o tom ani neví a žije si nad tím svým LV. A nemusí o tom vědět ani ta virtualizační technologie, prostě to má jako blockdevice a je to.

[trekker.dk]

Třeba to, že to bude součástí kernelu, kernel modul a nebude se muset řešit to, zda to běží ve virtuálce nebo na HW.

Takový přístup je ovšem iracionální. Představte si situaci, kde hledáte storage pro VMWare a dostanete nabídku na (hypotetické) VMStorage, které parametry předčí všechny ostatní nabídky, ale disky nelze připojit jinak, než jako disky virtuálek, protože se VMWare s ovladačem do jádra hostitele neobtěžoval. Na základě toho tuhle nabídku vyloučíte, přestože pro požadovaný účel (hledáte storage pro VMWare) je nejlepší.

To si právě nemyslím. KVM virtuálky vytvářím vždy nad LV a té virtuálce může být úplně jedno, jaké jsou pod tím PV. ... A nemusí o tom vědět ani ta virtualizační technologie, prostě to má jako blockdevice a je to.

Dobře, nevýhody takového přístupu jsou jasné, u emulovaných blokových zařízení (rbd, nbd, iscsi) máte režii navíc, pro RBD i režii v device mapperu, který duplikuje něco, co Ceph dělá taky. (U RBD bych se navíc bál, že si tam vyrobíte bottleneck, protože jádro nebude ochotné dostatečně využívat toho, že to "zařízení" dokáže pojmout velký počet paralelních požadavků - přece jenom to standardní bloková zařízení neumí.) A pokud náhodou hypervizor umí pro konkrétní typ úložiště nějaké optimalizace, tak je vypnete.

Jaký to má přínos?

[Heron]

Přiznám se, že celá tato konverzace mi přijde zvláštní. Vy jste (při našich nesčetných diskusích na téma btrfs) vždy obhajoval to, že se má používat standardní raid kód v jádře, používat stávající vrstvy a nic neduplikovat apod. (Bez ohledu na to, že to btrfs nedělá, ale to je teď jedno.) A najednou mi tady argumentujete specifickým ovladačem jen pro jednu věc na místo obecného v kernelu. Moc tomu nerozumím.

Takový přístup je ovšem iracionální. Představte si situaci, kde hledáte storage pro VMWare a dostanete nabídku na (hypotetické) VMStorage, které parametry předčí všechny ostatní nabídky, ale disky nelze připojit jinak, než jako disky virtuálek, protože se VMWare s ovladačem do jádra hostitele neobtěžoval. Na základě toho tuhle nabídku vyloučíte, přestože pro požadovaný účel (hledáte storage pro VMWare) je nejlepší.

To je úplně mimo, protože vmware si neinstaluju nad běžným linuxem, ale dostanu hotový produkt, který nainstaluju na HW. Je to blackbox, takže je celkem jedno, jak si to interně řeší. Já bych se především ze všech sil snažil vyhnout vmware samotnému a až potom bych řešil, zda ten který storage je lepší nebo horší. Preferuju obecná řešení, takže aktuálně máme storage přes SAS + iscsi a o speciální storage mountovaný do virtuálek nemám ani zájem ani kdyby existoval.

A pokud náhodou hypervizor umí pro konkrétní typ úložiště nějaké optimalizace, tak je vypnete.

Ano, to se může stát. Ale není to vždy špatně. Na těch miskách vah je toho víc, než jenom "výkon" a některé jiné věci mohou převážit. Pokud bych se například k vůli tomu měl zbavit nějaké modularity a dostatečného oddělení a obecnosti daného řešení, tak bych si takové řešení nezvolil. I za cenu nákupu více HW pro "méně" výkonné řešení.

Nehledě na to, že jsem za svůj život zažil už tolik zázračně výkonných řešení, že bych o tom mohl napsat knihu. Zázračné nejsou, nakonec to totiž vždy záleží jen a pouze na hrubém výkonu HW, který je k disposici. A viděl jsem několik případů, kdy si někdo pro jednu zázračnou technologii zabouchl dveře pro jiná obecná řešení a nakonec neměl ani výkon, ani modularitu.

[trekker.dk]

A najednou mi tady argumentujete specifickým ovladačem jen pro jednu věc na místo obecného v kernelu.

Rozdíl je v tom, že u toho Qemu to není specifický vs. obecný ovladač, ale dva specifické ovladače - jeden pro soubor, druhý pro iSCSI (třetí atd. pro RBD, NBD, NFS, gluster...) A v tom kernelu to také není obecný ovladač, je to jen emulátor (který dost možná používá stejného RBD klienta - nebo přinejmenším kdysi postaveného na stejném základě - akorát v kernel space.)

To je úplně mimo, protože vmware si neinstaluju nad běžným linuxem, ale dostanu hotový produkt, který nainstaluju na HW. Je to blackbox, takže je celkem jedno, jak si to interně řeší.

Pokud vím, tak ten VMWare používáte, takže ten příklad je relevantní. Pokud vám vadí closed-source, tak si místo toho můžete představit virtualizaci pomocí Qemu a hypotetické open-source úložiště HypoCeph, které je všemi parametry lepší než jiné nabídky, ale nemá ovladač na připojení disku do hostitele, jen do hosta. I tady je iracionální jej z výběru vyřadit.

Ale není to vždy špatně. Na těch miskách vah je toho víc, než jenom "výkon" a některé jiné věci mohou převážit. ....

A konkrétně? Myslím konkrétně jaký přínos má ze všeho udělat blokové zařízení místo (například) připojit Qemu k iSCSI (RBD,...) přímo.

[Heron]

které je všemi parametry lepší než jiné nabídky, ale nemá ovladač na připojení disku do hostitele, jen do hosta

Záleží na bodovém ohodnocení jednotlivých nabízených položek. Pro někoho může mít výkon váhu 15%, ale možnost obecného připojení třeba 60%. A třeba jiné položky mohou mít právo veta, třeba nesvobodná licence takového kandidáta může vyřadit rovnou a není potřeba se jím dál zbytečně zabývat.

Pro mě je v tomto konkrétním případě (CEPH) klíčová dostupnost CephFS a v druhé řadě i RBD v kernelu, obé jsme vyzkoušeli, obé jsme shodili, není co dál řešit. Někdo jiný může být happy s tím, že si nad librados napíše vlastní objekt storage (tuším Německá pošta) a někdo je happy s tím, když mu to funguje v qemu. Není na tom nic i/racionálního, prostě každý to má pro svůj projekt vyfiltrované jinak.

Myslím konkrétně jaký přínos má ze všeho udělat blokové zařízení místo (například) připojit Qemu k iSCSI (RBD,...) přímo.

No protože potom ta virtualizace nemusí mít speciální podporu pro x specifických ovladačů, může mít jen podporu pro blockdevice a tedy být jednodušší.

A mít to všechno v kernelu je potom výhodné z toho důvodu, že to nemusím použít jenom ve virtualizaci, ale taky v čemkoliv jiném.

Takže ta virtualizace o nic nepřijde a současně bude jednodušší a "konzumovat" výhody těchto specifických driverů může potom kterýkoliv jiný program, ne jen virtualizace.

Přijde mi poměrně zvláštní, že tohle musím vysvětlovat. Vždyť toto je klasickej unixovej princip. Proč by si měl každej program psát svůj specifický driver pro něco, když stačí obecné rozhraní (soubor, blokové zařízení) a o export toho zařízení se pro všechny postará někdo jinej. A potom úplně cokoliv, co umí pracovat se souborem, se k tomu může připojit.

[trekker.dk]

Záleží na bodovém ohodnocení jednotlivých nabízených položek.

Pokud dáváte možnosti obecného připojení vysokou váhu v případě, že obecné připojení není a nebude způsob, jakým se daná technologie bude při nasazení používat, je to špatně/iracionálně nastavená váha

A mít to všechno v kernelu je potom výhodné z toho důvodu, že to nemusím použít jenom ve virtualizaci, ale taky v čemkoliv jiném.

Takže přínosem je mít možnost, i když se ta možnost možná nevyužije... dobře, přiznám se, že jsem čekal něco hmatatelnějšího...

Přijde mi poměrně zvláštní, že tohle musím vysvětlovat. Vždyť toto je klasickej unixovej princip. Proč by si měl každej program psát svůj specifický driver pro něco, když stačí obecné rozhraní (soubor, blokové zařízení) a o export toho zařízení se pro všechny postará někdo jinej.

Stejný argument ale můžete použít třeba pro webový prohlížeč - proč by si měl psát svůj specifický driver pro HTTP, když stačí obecné rozhraní, které v jádře všechno zařídí a výsledek bude v blokovém zařízení. Mně to fakt nedává smysl, aby program v user space schopný komunikovat se síťovou službou přímo používal jádro jako zprostředkovatele. Nemůže to mít lepší výkon a ještě je to hromada kódu, který běží s oprávněním kernel space.

[Heron]

že obecné připojení není a nebude způsob, jakým se daná technologie bude při nasazení používat

No ale cílem přece není používat nějakou konkrétní technologii. Resp ano, znám lidi, kteří objeví nějakou úžasnou (pro ně) technologii a potom se pokouší ji nějak za každou cenu použít. Já to dělám přesně naopak, já si nakreslím co chci dosáhnout, stanovím si podmínky a až potom na to hledám technologie. Spousta z nich vypadne a z toho zbytku se to postaví. (Pochopitelně už v procesu návrhu znám dostupné technologie a rád si udržuju big picture co je možné a co není, ale fakt to nestavím od těch technologií, ale od toho návrhu.)

Což mimochodem kromě jiného umožňuje ty technologie snadno nahrazovat. Pokud nevyhovuje mdadm, nasadím tam hw raid a udělám pvmove. Všechno co je nad tím o té měně ani neví. Pokud nevyhovuje konkrétní FS, tak díky VFS jej mohu kdykoliv vyměnit za jiný FS a všechno bude fungovat. Pokud píšu v SQL standardu, tak můžu kdykoliv vzít jinou SQL DB splňující standard. Pokud používán REST API, snadno vyměním server nebo klienta. Toto jsou zásady správného návrhu. Nikoliv "chci tamtu technologii".

Takže přínosem je mít možnost, i když se ta možnost možná nevyužije

Jaktože se nevyužije? Mít funkční RBD v kernelu přece znamená, že si to můžu zařadit do protfolia dostupných blockdevice a potom to připojovat třeba do lvm, nebo nad tím udělat libovolný fs apod. Klidně to může být PV pro LV a nad tím virtuálka.

Stejný argument ale můžete použít třeba pro webový prohlížeč

No samozřejmě. Tak zrovna "http driver" by nemusel být v jádře, bohatě by stačila oddělená dynamická knihovna, kterou by ostatní prohlížeče obecně používaly. Jak se to ostatně běžně dělá u všeho jiného (málo co si implementuje vlastní jpg, png apod knihovny, ale linkují si to).

[trekker.dk]

No ale cílem přece není používat nějakou konkrétní technologii. Resp ano, znám lidi, kteří objeví nějakou úžasnou (pro ně) technologii a potom se pokouší ji nějak za každou cenu použít. Já to dělám přesně naopak, já si nakreslím co chci dosáhnout, stanovím si podmínky a až potom na to hledám technologie.

No samozřejmě. A v tomhle případě, o kterém se bavíme, je, že chcete postavit virtualizační řešení (compute nody + storage), hledal jste technologie a nejlepší storage (tj. má nejlepší poměry cena/výkon a takové) neumí obecné připojení, pouze připojení do těch virtuálek. Stále tvrdím, že když se obecné připojení v praktickém nasazení používat nebude, je iracionální tuto storage z výběru vyřadit (tj. dát možnosti obecného připojení tak velkou váhu, že bude tato storage vyřazena)

Což mimochodem kromě jiného umožňuje ty technologie snadno nahrazovat. Pokud nevyhovuje mdadm, nasadím tam hw raid a udělám pvmove.

Dobře, to bych i bral, i když mám docela pochybnost o možnostech praktické realizace. Zatím vždycky, když jsem na tuhle potřebu narazil, tak to skončilo na tom, že v tom serveru už nebylo místo na disky, které by se do toho hw raidu daly připojit. Takže žádné pvmove.

Mít funkční RBD v kernelu přece znamená, že si to můžu zařadit do protfolia dostupných blockdevice a potom to připojovat třeba do lvm, nebo nad tím udělat libovolný fs apod. Klidně to může být PV pro LV a nad tím virtuálka.

Ohledně LV pro virtuálku už jsem mluvil, nedává to smysl, zavádíte si omezující abstrakci a vrstvy navíc (volume manager nad volume managerem) a získáváte za to teoretickou výhodu, která ovšem nemusí dojít praktického využití (a kdyby náhodou taková potřeba vznikla, je to řešitelné jinak)

Nepopírám, že možnost připojit to i jako blokové zařízení v kernelu by byla nice-to-have, ale z toho, že není (tj. ne skrz kernel), bych řekl, že prostě není poptávka. A případy, kde by byla, dost možná má řešit to iSCSI.

Tak zrovna "http driver" by nemusel být v jádře, bohatě by stačila oddělená dynamická knihovna, kterou by ostatní prohlížeče obecně používaly.

Když tak nad tím přemýšlím, prohlížeče možná nebyly ten nejlepší příklad, protože tipuju, že ty si zrovna budou hrát na vlastním písečku. Ale dobře, řekněme, že používají dynamickou knihovnu a jádro HTTP neumí, tudíž si nemůžete připojit filesystém přes WebDAV. To asi nikoho nepřekvapuje a nikdo to nepovažuje za velkou závadu. U Cephu je pak situace analogická, existují dynamické knihovny, které "prohlížečům" Qemu nebo třeba rbd-fuse umožňují připojit se k Cephu a jádro Ceph neumí, tudíž si nemůžete připojit filesystém na RBD.

Znovu, bylo by to nice-to-have, ale vývojářů ani peněz není neomezeně...

[Heron]

Já to zkusím popsat jinak, možná že jsme se moc ztratili v těch konkrétních případech.

Pro mě je vždy lepší mít menší počet obecnějších komponent, než větší počet specifických. Místo specifické komponenty vždy raději použiju obecnější, pokud existuje a jde použít.

Je to vlastně "the unix way" v shellu máme pipe a v případě blokových zařízení máme mnoho lego kostek, které můžeme téměř libovolně skládat. Disková zařízení, mdadm, lvm, iscsi, nbd apod. umí přijímat a exportovat blokové zařízení, lze to vrstvit apod.

Takže pokud mám tohleto, tak si z toho můžu udělat obyč storage s jedním fs, nebo 100x LV, nebo šifrované, mirrorované ad nauseam. A kromě toho to ještě můžu, bez jakýchkoliv dalších specifických komponent, použít k virtualizaci. Nemám důvod použít cokoliv specifického, všechno už mám, tak nad tím LV dám KVM stroj a je to. Cílem není přidávat cokoliv dalšího, cílem je mít tak málo komponent, kolik je možné. (A to pochopitelně v celém portfoliu, ne že to zase někdo pochopí tak, že tento konkrétní projekt bude mít jen jednu specifickou komponentu, takže je to vlastně nejlepší řešení. Nikoliv, nejlepší je mít co nejméně druhů komponent napříč celým portfoliem, aby bylo možno zkušenosti získané někde použít i jinde.)

Stále tvrdím, že když se obecné připojení v praktickém nasazení používat nebude, je iracionální tuto storage z výběru vyřadit (tj. dát možnosti obecného připojení tak velkou váhu, že bude tato storage vyřazena)

Viz výše. V tom jednom projektu se to obecné připojení nevyužije, ale může se využít jinde. A pokud ne, tak je zbytečné tuto technologii nasazovat jen na jeden projekt, když je možné použít i jiné, stávající řešení.

Dobře, to bych i bral, i když mám docela pochybnost o možnostech praktické realizace. Zatím vždycky, když jsem na tuhle potřebu narazil, tak to skončilo na tom, že v tom serveru už nebylo místo na disky, které by se do toho hw raidu daly připojit. Takže žádné pvmove.

Nejde o lokální disky, připojí se sas řadič, externí pole a hurá na přesun. Dělal jsem to několikrát. Funguje to normálně za běhu, akorát je dobré tomu IO trochu odlehčit a nedělat to ve špičkách. (Lze to dělat po jednotlivých LV, takže není potřeba dělat vše naráz.)

U Cephu je pak situace analogická, existují dynamické knihovny, které "prohlížečům" Qemu nebo třeba rbd-fuse umožňují připojit se k Cephu a jádro Ceph neumí, tudíž si nemůžete připojit filesystém na RBD.

Tak zrovna u podobných systémů by člověk očekával, že to jako první půjde připojit jako normální fs (cephfs) a když už to umí i blockdevice, tak i ten. Ale tak to je jedno, už to nemusíme opakovat.

[trekker.dk]

Dobře, zjevně jiný přístup, já se nasazení různorodějších technologií nebráním, pokud to teda vypadá jako něco, s čím nebude moc práce, splní to svůj účel a přinese to nějaké výhody navíc. Což s tím Cephem zatím moc práce nebylo, prostě se to jednou za čas aktualizuje a jednou za dva roky upgraduje. (Všechny ostatní problémy jsou kategorie "chyba obsluhy" a "možná by to přece jenom chtělo trochu silnější hardware, než co se zaprášené válelo na půdě".)

Tak zrovna u podobných systémů by člověk očekával, že to jako první půjde připojit jako normální fs (cephfs) a když už to umí i blockdevice, tak i ten

To bych neřekl, v jádru je to velká key-value databáze, takže bych jako první očekával, že naopak nic z toho nepůjde, protože v datech vlastně žádný filesystém není. Teprve jako druhé by bylo to blockdevice - to je přece jenom relativně jednoduché udělat s klíčem zařízeníX-blok-od-0-do-4MB. Postavit na tom filesystém musela být docela pakárna.

[Heron]

To bych neřekl, v jádru je to velká key-value databáze, takže bych jako první očekával, že naopak nic z toho nepůjde, protože v datech vlastně žádný filesystém není. Teprve jako druhé by bylo to blockdevice - to je přece jenom relativně jednoduché udělat s klíčem zařízeníX-blok-od-0-do-4MB. Postavit na tom filesystém musela být docela pakárna.

Ano, s tím souhlasím a už v komentáři #70 jsem psal, že si myslím, že objektové S3 API bude nejlepší, ale to by se ceph nesměl prezentovat i tím blockdevice a fs. Tak snad to někdy bude hotové.

[trekker.dk]

Já vím, že máte radši obecnost, ale tím API si do toho úložiště zanášíte úzké hrdlo, takže kdybyste to někde chtěl nasadit, doporučuju nejdřív spočítat, jestli nepotřebujete použít přímo Rados.

[Heron]

Jasně, což je přístup vhodný třeba pro Deutsche Telekom. Ale asi ne každá firma má na to, aby si napsala (a dlouhodobě udržovala) nad librados vlastní plugin do dovecotu . Ten německej tým měl něco jako 20 lidí. To je úplně mimo realitu firmy na českém trhu. Udržovat vlastní librados knihovnu k nějaké pro firmu podstatné komponentě.

I toto je důvod k té obecnosti. Pokud tam bude běžným způsobem připojený (ceph)fs, tak i admin, který k tomu přijde jako nováček, se velice rychle zorientuje. Pokud tam bude něco nad librados, tak můžeme hádat, jak to asi dopadne.

[Josef Kufner]

Ale dobře, řekněme, že používají dynamickou knihovnu a jádro HTTP neumí, tudíž si nemůžete připojit filesystém přes WebDAV.

Jádro umí FUSE, takže si v user space spustíme souborový systém a skrze jádro ho připojíme jako každý jiný, takže programy nemusí řešit knihovny a mohou normálně přistupovat k souborům. Je tam nějaký overhead s přecházením do jádra a zpět, ale jinak to funguje velice pěkně.

[trekker.dk]

To je mimo debatu - ano, fuse existuje (a rbd-fuse taky), ale výkon stojí za nemnoho, takže pro produkční nasazení ve větším rozsahu než na testování nebo tak něco to moc není.

[trekker.dk]

zatím bez problémů

Jsou věci, které by člověk neměl říkat předtím, než se pustí do upgrade na novou verzi... Ne že by se to nepovedlo, ani jsem nepřišel o data, ale jeden z nodů se prostě zbláznil, začal usilovně hrabat po discích, ale nedělal nic. Pořád je to víceméně experimentální nasazení, takže jsem tomu následně trochu pomohl k pádu (odpadní hardware taky nepomohl) a vedlo to na hodinový výpadek

Nic, z čeho by se nedalo zotavit, ale začínám mám pocit, že ta věc není dělaná k tomu, aby si to člověk spravoval sám... ale k tomu, aby si to koupil jako open-source blackbox. To se mi, přiznávám se, teda moc nelíbí...

[Jendа]

Pro mě je jediné storage řešení na úrovni RAID-10. V případě btrfs multidevice raid-1.

Jak tohle funguje? Vytvoříš btrfs přes 50 disků a nastavíš data na raid1? Pak btrfs bloky rozhazuje mezi disky náhodně, takže když odejdou libovolné dva současně, tak jsi o něco přišel?

[Heron]

Tak já myslím, že víš, jak to funguje, ne?

BTRFS v režimu raid-1 ukládá bloky na dvě device. A ano, pokud přijdeš o dvě současně, tak můžeš přijít o některé bloky některých souborů. To je prostě vlastnost. A když tohle admin ví, tak tam nebude dávat tolik disků, aby bylo riziko, že vypadnou dva současně. Nebo ty device budou dostatečně malé, aby se to stihlo rychle přeskupit.

Tohle ale platí obecně pro jakýkoliv podobný systém, když budu mít redundanci 4, stále jsem v riziku že o ta data přijdu, akorát konkrétní čísla budou pochopitelně jiná než pro redundanci 2.

[Aleš Kapica]

A když tohle admin ví, tak tam nebude dávat tolik disků, aby bylo riziko, že vypadnou dva současně.

Právě naopak. Žádoucí je větší počet disků. Data jsou pak víc rozptýlená a to znamená menší pravděpodobnost, že se při selhání dvou disků současně něco ztratí dřív než se to stihne zreplikovat. Podmínkou je ale pochopitelně, že to pole není obsazeno na plný knedlík. V podstatě by nemělo zaplnění dojít k hranici, kterou je kapacita disků, zmenšená o 2 disky s největší kapacitou, dělená dvěma. Prakticky. Mám-li kombinaci 2x3TB a 12x2TB, je teoreticky celková kapacita 30TB, jelikož ale mohou chcípnout zrovna ty 3TB disky, mohu reálně počítat jen 24TB, což při Btrfs v módu raid1 znamená že pokud tam navalím víc než 12TB tak riskuji že se mi něco ztratí dřív než se to stihne obnovit.

Pokud jde o chcípnutí dvou disků současně, tak je za normálních okolností téměř nepravděpodobné. Pokud se něco takového stane, tak je mnohem větší pravděpodobnost, že je chyba jinde – napájení, kabel, deska,… A v takovém případě pokud se disk opět objeví, se data neztratí – prakticky vyzkoušeno. Kdysi jsem totiž používal zdroj, který měl modulární kabely – nebrat! – a stačilo lehce zavadit o některý z nich, aby pokles napájení vyřadil 2 disky z MD raid6, načež následovalo cca 9 hodin modlení aby to zbývající disky ustály. Po nasazení Btrfs v raid1 to nebylo nutné. Uloženým datovým blokům na vypadlých discích se nestalo nic a nové se poté co ty disky odpadly uložily na ty co zůstaly.

[trekker.dk]

zdroj, který měl modulární kabely – nebrat!

Jo, kdyby si tak člověk mohl vybírat...

[Aleš Kapica]

Vždycky si můžeš vybrat. Jenom je někdy těžké si to připustit.

Ale chápu, že pokud jsi nucen pracovat s tím, co nakupuje někdo jiný, je ta volba mnohem těžší.