Red Hat Enterprise Linux 7

Red Hat oznámil vydání Red Hat Enterprise Linux 7. Nová verze aktualizuje software, přidává nové technologie a celou řadu vylepšení. Podrobné informace jsou k dispozici v poznámkách k vydání. Ve stejný den tvůrci CentOS, distribuce založené na RHEL, zpřístupnili gitový repozitář obsahující zdrojové kódy příští verze distribuce a skripty umožňující rekompilaci balíčků, jejich modifikaci a vývoj.

10.6.2014 22:07 | little.owl | Nová verze

Komentáře

[little.owl]

Pouziti xfs jako defaultniho file systemu mi prijde jako priznani, ze ext4 ma jiz sve nejlepsi casy za sebou (vlastne proc?) a btrfs neni jeste v produkcnim stavu.

RHEL betu jsem zkousel a je to povedene distro, dobra prace, jen je skoda ze Gnome 3 neni ve verzi o jeden stupen vyssi - 3.10.

[Ruža Becelin]

Na Summitu rikali, ze btrfs jeste neveri natolik, aby si to dovolili supportovat. S tim XFS je to logicke, je to podporovany FS ve Storage serveru, tak nechteji tristit sily, navic ext4 se nad ~50TB nechyta, zatimco XFS jo.

GNOME mne nepali, zajimalo me naposledy tak kolem verze 1.0, ale nastesti tam je porad KDE

[kavol]

Na Summitu rikali, ze btrfs jeste neveri natolik, aby si to dovolili supportovat.

to by mě docela zajímala původní formulace, neb se mi nezdá, že bychom se takto veřejně přiznali, že to žere data

GNOME mne nepali, zajimalo me naposledy tak kolem verze 1.0, ale nastesti tam je porad KDE

no ... sice tam KDE je, ale stylem "můžete si sice u auta nechat vyměnit kola, ale když si tam dáte jiné, tak ty původní vám přivaříme na střechu, a rezervu si musíte nechat původní"

[hura]

A funguje tam to KDE alespoň pořádně nebo je to taková vedlejší "nepodporovaná" záležitost? KDE je vlastně poslední existující velké desktopové (netabletové) prostředí, tak by byla škoda, kdyby to tam nejelo dobře.

[kavol]

tož funguje, ale ... celé je to prošpikované gnomismy, na poslední chvíli bylo odebráno[*] kdm, ale sddm se tam nedostalo, a tak ...

[*] pozn. popisuju stav na testovací mašině, která používá interní repozitáře, což se neshoduje na 100% s tím, co dostali zákazníci, i když pro tyto účely doufám, že je shoda dostatečná

jinak "poslední existující velké desktopové (netabletové) prostředí" ... mno ... jednak AFAIK plasma se teda teď orientuje hodně moc moc na šmatlaplacky, a jednak co takové XFCE?

[Martix.]

KDM bylo odebráno, protože má mrtvý upstream a mainteneři by ho nebyli schopni udržovat dalších 10 let. Na SDDM se bohužel začalo pracovat příliš pozdě a ještě není dodělané. GDM funguje, vývojáři ho udržují a nemá vliv na běžící KDE session, takže bych to neviděl černě.

Jaké "gnomismy" v KDE máš na mysli?

[pavele]

A už má GDM volbu grafického přihlášení na tty7, nebo má pořád ten starý bug jako v RHEL 6 - přihlásím se na tty1, odhlásím se, po novém přihlášení jsem na tty7 a tty1 je nepoužitelná?

V RHEL 6 jsem to obešel instalací KDM.

[Martix.]

GDM v RHEL7 startuje stále na tty1, alespoň dokud nepoužiju funkci "switch user". Máš k dispozici link na ten bug v RHEL6?

[karlik]

V RHEL6 nevím, ale jedná se o tento nebo tento bug.

[KDM]

Nejen to, ale vyskytovaly se i bugy ve stylu "kombinace KDM a GNOME neni podporovana"...

[Martix.]

Já vím, sám jsem je hlásil.

[Ruža Becelin]

to by mě docela zajímala původní formulace, neb se mi nezdá, že bychom se takto veřejně přiznali, že to žere data

Jestli si dobre vzpominam, tak nejak to rikala Denise Dumas - pokud jsi tam nebyl, tak si pust RHEL roadmap na Youtube.

[kavol]

heh, zase tolik mě to nezajímá, abych kvůli tomu procházel dvě hodiny keců

[...]

takhle se o tom hovorilo u kafe pred hodne davnou dobou mezi lidmi co to zkouseli jeste ve verzich oproti tehdejsi dobe davnejsich nez aktualnich. tak uz to tomu jen tak nekdo neodpare. socialni setrvacnost je mocna.

[kavol]

nespletl sis thread? - nějak mi uniká souvislost s příspěvkem, na který reaguješ ... "o tom" má být o btrfs nebo o KDE?

[little.owl]

Zde. Hlavne jde asi o ty limity 50 versus 500TB.

Zajimalo by me jaka je pak situace s JFS. Uziva to na Linuxu produkcne nekdo a proc?

[ivan]

Nepouzivam to, ale mam za to, ze je to vice-mene mrtvy filesystem. Resp. je to funkcni ale nijak dal se nerozviji a ani nebude. Na AIXu se uz pouziva JFS2. Linuxovy port JFS ale vznikl portaci zdrojaku z OS/2 a ta je ted uplne mrtva. Myslim, ze budoucnost JFS zavisi hlavne na IBM.

[Michal Kubeček]

Na AIXu se uz pouziva JFS2. Linuxovy port JFS ale vznikl portaci zdrojaku z OS/2 a ta je ted uplne mrtva.

Zajímalo by mne, odkud se tohle tvrzení (že Linux používá JFS1 a AIX novější JFS2), pořád bere, když i ten nejjednodušší dotaz do Googlu nebo na Wikipedii vede na stránky se správnou informací. Je to téměř přesně naopak, původní JFS byl v podstatě neportovatelný a fungoval jen na AIX. Linuxový port vznikl právě na základě nové verze JFS2, která se sice poprvé objevila v OS/2 Warp, ale pak ji převzal i AIX (a používá ji dodnes).

[Ivan]

Tak to se omlouvam. Tohle jsem nevedel.Nedoslo mi jak strasne strary bylo JFS(1). Prvni verze JFS na Linuxu byly case-insensitive - pamatuju si, ze me to tenkrat dost zarazilo. Pak se to vysvetlilo tim, ze jde o port z OS/2 a ne z AIXu. Na AIXu jsem zacal pouzivat jfs2 az potom, co byl Linuxovy port hotovy takze me ani nenapadlo, ze by bylo mozny ze to funguje drive na Linuxu nez na AIXu.

[Michal Kubeček]

Já ho používám docela dlouho a má zkušenost je, že "just works", což je přesně to, co od filesystému očekávám. Používat jsem ho začal pro velké (od 1 TB výš) filesystémy, protože v té době měl XFS nějaký problém způsobující, že flushnutí cache na víceprocesorovém systému trvalo extrémně dlouho. Paradoxně mám teď občas podobný problém u JFS (i když ty časy nejsou tak strašné jako tehdy s XFS).

[little.owl]

Diky. XFS byl prvni FS - pred mnoha lety a revizi udelanou Red Hat, kde jsem prisel o data. Takze jsem vuci nemu ponekud zaujaty/neduverivy.

[...]

tehda jeste nebyly bariery a defaultni chovani v pripade nalezeni nekonzistence bylo truncate souboru, aby sis nezkriplil data jeste vic a upozornilo te to na spusteni xfs_repair

[jas]

ext4 proste uz nestiha s dobou (nie je stavane na vela TB storage).

btrfs by v produkcnom stave dnes uz mozno aj bol (on je vlastne aj podporovany, len nie default), ale na default chybaju ludia (a podla mna ani ako default file system nema az tak moc zmysel).

[Conscript89]

The Btrfs (B-Tree) file system is supported as a Technology Preview in Red Hat Enterprise Linux 7.

Takze asi takle "podporovane". zdroj

[Aleš Kapica]

Vyjádřil jsem se již v paralelní diskuzi. XFS, vyvíjený od r. 1993 je léty prověřený souborový systém, jehož slabiny jsou známy. Většina manažerů, která rozhoduje o tom jaký má být nasazen FS o něm v minulosti přinejmenším slyšela.

Vývoj Btrfs začal teprve v r. 2008 a aktivní zkušenosti s jeho použitím, které by bylo možné počítat na léta má pouhá hrstka uživatelů (na tomhle portále jsme tuším tři), která však nesedí na manažerských pozicích velkých firem. Tož asi tak.

[Max]

Heron, ty, ten blázen Andrej a já. Takže já znám 4 lidi :).
Zdar Max

[kavol]

pět :-p

[Aleš Kapica]

Jedna ruka netleská..

[alkoholik]

To jsou samozrejme lzi a pomluvy.
;)

[little.owl]

No nasadit Brtfs do produkce, hned jak to odpadne vyvojarum kernelu od pracek, chce kus chlapa. Pokud tam jsou stale mozne problemy s bezpecnosti dat, jak naznacuje Kavol, pak to plne chapu, tohle je jedna z oblasti, kde se neriskuje.

[Rezza]

Tak ve Fedora se brtfs resi uz nejakou dobu a myslim si, ze uz relativne ve stavu, kdy by default mohl byt by to slo. Ale nejdriv by si s nim musela poradne poradit Anaconda :))). To je asi nejvetsi problem, brtfs totiz podporujeme a pri poslednim release jsme se snazili Anacondaky presvedcit, at na btrfs a thinp daji nejaky "kdyz fakt chcete, tak to dostanete", protoze z toho byla kupa blockeru.

[Aleš Kapica]

Napadnul mě ještě jeden důvod proč je upřednostněný XFS a ne Btrfs. Agent Pacemakeru (za jehož vývojem stojí Red Hat) pro práci s FS je totiž absolutně pitomý. Nejprve jsem řešil problémy s OCFS2. Nakonec mi nezbylo, než si před třemi lety napsat místo něj vlastního agenta a loni jsem si do něj doimplementoval i podporu pro Btrfs a jeho subvolume. Bohužel mé časové a komunikační schopnosti nejsou na takové úrovni, abych byl schopen ho protlačit do mainline. Tak jen pro info, kdyby náhodou někdo také tenhle problém řešil, že je agent pro CRM který zvládá i Btrfs k dispozici.

[Rezza]

Na Pacemakeru dela Andrew Beekhof. S nim jsem na jednom jiz mrtvem projektu delal a muzu mu zkusit podstrcit to tvoje :).

[Aleš Kapica]

Aktuální kód agenta co používám jsem dal k dispozici na veřejnou repozitory crm_agents. Nemám na to extra vývojovou repozitory, protože kód udržuji v repozitáři našeho puppet masteru, který je neveřejný.

[jas]

Ja by som v tom nehladal ziadne konspiracne teorie. Proste nemaju vyvojarov, co by to podporovali. Povodne mali Josefa Bacika, ale ten odisiel. Mali este jedneho btrfs vyvojara (na meno si uz nespomeniem), ale ten pokial viem tiez odisiel, takze na podporu btrfs neostal nik. Tipujem, ze plna podpora pre btrfs pride priblizne v dobe, ked sa im podari zohnat nejakeho vyvojara btrfs (resp. aspon dvoch).

Pri XFS je situacia uplne ina -- je tu Dave Chinner a Eric Sandeen, Christoph Hellwig je contractor a este su tu dvaja zacinajuci XFS vyvojari (Carlos Maiolino a Brian Foster).

[jas]

Tak som si na druhe meno spomenul, je to Zach Brown a on v RH ostal. Kazdopadne sam na plnu podporu zrejme nestaci.

[Aleš Kapica]

Však v to nikdo konspiraci nehledá. Já jsem napsal svůj názor na to, proč Red Hat upřednostnil XFS jako default systém před Btrfs.

Osobně mi to je jedno. Používám Debian a souborový systém si může každý zvolit jaký chce. Pokud jde o Btrfs, nemám pocit, že by obsahoval nějakou kritickou chybu, takže je fajn, že se tomu věnuje alespoň někdo. A implementace nových features mě zase až tak nepálí.

Jiná věc je Pacemaker. Tam je bohužel situace s agenty smutná. Mohl bych o tom vyprávět. Zatím jsem zmínil pouze agenta pro FS, ale dlouho jsem nemohl plně integrovat své virtualizační řešení do clusteru, protože prostě neexistoval jednoduchý agent, který by uměl spustit virtuál přes qemu. Existuje jakás takás podpora pro libvirt a xen, ale pro čisté qemu nebylo nic. Tak jsem si to holt musel napsat.

Agent pro OCFS2 byl děsně změnu zastaralý a s novější implementací, která používala zamykání v kernelu kolaboval. Proto jsem to tehdy pojal komplexně a přepsal FS, i o2cb. Teď už OSFS2 nikde nepoužívám, takže jsem přepsal agent FS tak aby byl vyloženě na míru Btrfs.

Bohužel jak se zdá budu nejspíš muset zase přepsat i agenta pro DRBD. Ten od Linbitu sice funguje lépe než ten původní, nicméně za určitých okolností se chová dost divně. Tedy především v prostředí asymetrického clusteru, který má víc jak dva nody. A tohle divné chování DRBD agenta od Linbitu vede k tomu, že když se do clusteru zapojí další nod, tak chce mocí mermo přehodit master na všech(!) spuštěných DRBD polí. Přitom se jinak s DRBD nic neděje a v konfiguraci není pro ten nově přidaný nód žádná služba. Naštěstí se tím jenom závislé zdroje dostanou do stavu unmanaged a všechno funguje dál jak má. Ale není to pěkné a musí se to vždycky co nejrychleji přes cleanup opravit.

[little.owl]

Ale nejdriv by si s nim musela poradne poradit Anaconda :))).

Ach jo ....

[kavol]

Pokud tam jsou stale mozne problemy s bezpecnosti dat, jak naznacuje Kavol

kavol naznačuje? - kavol na to má bugreport (hm, když už o tom mluvíme, měl bych přetestovat 1044456) a v souvislosti s tím potkal další problémy (ach ano, opět systemd)

[jas]

1093909 -- na 99.9 % nejde o bug; to, ze fuser ani lsof nic neukazuju znamena len, ze mount nie je blokovany kvoli userspace aplikacii. Mount moze byt stale blokovany v kerneli -- submount, dm, md, loop device, ...

1044456, 1052207 -- afaik btrfs nema (na rozdiel od XFS) godown utilitu, takze dana oblast (cca power failure) nie je a z principu ani nemoze byt poriadne otestovana.

[kavol]

1093909 -- na 99.9 % nejde o bug; to, ze fuser ani lsof nic neukazuju znamena len, ze mount nie je blokovany kvoli userspace aplikacii. Mount moze byt stale blokovany v kerneli -- submount, dm, md, loop device, ...

ovšem ten bug není o tom, co ukazuje nebo neukazuje fuser/lsof, ale o tom, že to nejde umountnout, a tedy nejde nad tím pustit fsck

1044456, 1052207 -- afaik btrfs nema (na rozdiel od XFS) godown utilitu, takze dana oblast (cca power failure) nie je a z principu ani nemoze byt poriadne otestovana.

jen upřesním, že u 1052207 nešlo o power failure bo to bylo na notebooku, ten je jaksi z principu sám sobě upskou

co chtěl básník říci tvrzením "z principu nemůže být řádně otestovaná" nevím, podle mého to jenom potvrzuje, že btrfs fakt není připraven na reálné nasazení (ať "produkční" nebo BFU)

[jas]

ovšem ten bug není o tom, co ukazuje nebo neukazuje fuser/lsof, ale o tom, že to nejde umountnout, a tedy nejde nad tím pustit fsck

To, ze je mount blokovany podmountom, dm, md, loopou alebo niecim podobnym nie je bug -- nemozem odpojit file system ak z neho pouzivaju data ine moduly v kernel space. To o fuser/lsof bolo len vysvetlenie preco nemusia nic ukazovat a aj tak nejde o bug.

Bug by to bol len v pripade, ze by umount nebol blokovany nicim inym v kernel space -- blokoval by umount priamo btrfs modul sam o sebe.

jen upřesním, že u 1052207 nešlo o power failure bo to bylo na notebooku, ten je jaksi z principu sám sobě upskou

Disconnect a reconnect disku je cca to iste ako power failure.

co chtěl básník říci tvrzením "z principu nemůže být řádně otestovaná" nevím, podle mého to jenom potvrzuje, že btrfs fakt není připraven na reálné nasazení (ať "produkční" nebo BFU)

Ze pokial viem chyba tool, aby sa mohli poriadne otestovat power failure scenare. FS, ktore ten tool nemaju budu na problemy s power failure doplacat este dlho po tom, co vzniknu. XFS bol v podobnej situacii par rokov dozadu (velke problemy s power failure), tak kvoli lepsej testovatelnosti vyvojari vyvinuli tool, ktory simuluje power failure za behu systemu (nie, vyberanim snury zo zastrcky sa to fakt poriadne otestovat neda).

A ano, tym vravim, ze btrfs ma slabiny v danej oblasti. Druha vec je, ze vdaka vstavanym snapshotom power failure bugy pri btrfs nie su az tak zhave.

[Aleš Kapica]

A ano, tym vravim, ze btrfs ma slabiny v danej oblasti. Druha vec je, ze vdaka vstavanym snapshotom power failure bugy pri btrfs nie su az tak zhave.

To mohu potvrdit, neboť s tím mám osobní zkušenost - pravidelně se mi rozbíjelo pole kvůli vadné zástrčce na SATA kabelu. Stačilo jemně pohnout kabelem, a disk byl z pole fuč. Pořád jsem rebuildoval pole a že to trvá než dá SW RAID6 4TB dohromady. Pak jsem na to přišel a raději změnil zapojení. Přesto jsem o data z Btrfs nad tímto polem nikdy nepřišel.

Bohužel jinak to dopadlo když mi chcípnul jeden z disků pole, nad kterým byl ext4. Záznam o souborech sice zůstal zachován, ale data z některých byla fuč. Naštěstí zde byla druhá polovina DRBD, takže zmizela jen data co se nestihla odreplikovat než to kleklo.

[kavol]

To, ze je mount blokovany podmountom, dm, md, loopou alebo niecim podobnym nie je bug -- nemozem odpojit file system ak z neho pouzivaju data ine moduly v kernel space. To o fuser/lsof bolo len vysvetlenie preco nemusia nic ukazovat a aj tak nejde o bug.

Bug by to bol len v pripade, ze by umount nebol blokovany nicim inym v kernel space -- blokoval by umount priamo btrfs modul sam o sebe.

to já nevím, čím konkrétně je to blokované, ale z uživatelského hlediska to bug je, že se to nedokáže uvolnit (pozn. netvrdím, že to je bug v umountu - jestli je to používané, je v pořádku, že se to odmítne odpojit, pak je ale problém, že je to používané, i když to nemá být používané)

jen upřesním, že u 1052207 nešlo o power failure bo to bylo na notebooku, ten je jaksi z principu sám sobě upskou

Disconnect a reconnect disku je cca to iste ako power failure.

ehm, za prvé, to (dis-/reconnect) je ale bug 1044456, nikoli bug 1052207

za druhé, dovolil bych si nesouhlasit, resp. tedy to "cca" je hodně velké - u power failure jde vše do kytek, u reconnectu může mít kernel vše co nezapsal stále v paměti

(nie, vyberanim snury zo zastrcky sa to fakt poriadne otestovat neda).

tak naokraj, přesně tohlento jsme ale v minulém zaměstnání dělali

Druha vec je, ze vdaka vstavanym snapshotom power failure bugy pri btrfs nie su az tak zhave.

s touto bagatelizací bych si dovolil nesouhlasit - ani v jednom z uvedených případů jsem ten systém už nerozjel a data z něj nevydoloval

(no, to není tak úplně přesné, v druhém případě se z toho dalo nabootovat a vše číst, problém nastával až po nějakém množství zápisů, přičemž tento se neustále po každém rebootu snižoval; ale úplně se to rozpadlo teprve právě po pokusu použít btrfsck)

[jas]

to já nevím, čím konkrétně je to blokované, ale z uživatelského hlediska to bug je, že se to nedokáže uvolnit (pozn. netvrdím, že to je bug v umountu - jestli je to používané, je v pořádku, že se to odmítne odpojit, pak je ale problém, že je to používané, i když to nemá být používané)

Len to je chyba uzivatela (pripadne zvysku systemu), ze to nevie. Kernel modul fs nemoze odpojit particiu, z ktorej sa cita. A citat z nej mozu kludne ine kernel moduly, ktorym to bolo povedane z user-space ci uz priamo uzivatelom alebo nejakym init scriptom. Pre zaciatok by som aspon pustil umount -R, ktory to odpoji rekurzivne (ak nepojde ani to, tak to stale nemusi znamenat, ze to je chyba niekde v systeme, este to moze blokovat kadeco ine inicializovane z user space).

ehm, za prvé, to (dis-/reconnect) je ale bug 1044456, nikoli bug 1052207

za druhé, dovolil bych si nesouhlasit, resp. tedy to "cca" je hodně velké - u power failure jde vše do kytek, u reconnectu může mít kernel vše co nezapsal stále v paměti

Ono myli, ze 1052207 je klonom 1044456.

Je pravda, ze nedavno sa pri usb a reconnecte zacali fs spravat trocha inak a dokazu pokracovat. Nestudoval som este ako to docielili, ale moj skromny tip je, ze v tom ma prsty systemd (udev cast), ktore dovoli za urcitych okolnosti znovunapojit zariadenie a pri zapisoch v dobe, ked bol disk odpojeny sa potom len vyhodi I/O error. V tom pripade je to zrejme skor podobne I/O errorom a uprimne netusim ako je na tom btrfs v tej oblasti (netestoval som). Implementacie vsetkych FS byvaju v tychto pripadoch celkom zabugovane (pri XFS sa na tom aspon robilo, neviem ako najnovsie upstream jadra, ale v RHEL 7 su tam stale nejake zname problemy -- aj ked nie korupcia, len pad systemu).

V starsich jadrach je to to iste, co power failure (tam sa robil shutdown, k reinicializacii nedochadzalo -- ani nemohlo, udev po reconnecte hodil nove zariadenie).

s touto bagatelizací bych si dovolil nesouhlasit - ani v jednom z uvedených případů jsem ten systém už nerozjel a data z něj nevydoloval

Tak, samozrejme treba tie snapshoty aj pravidelne robit. Pre produkcnu sferu (lahke) snapshoty ako zabezpecenie celkom stacia (samozrejme, nie vsade). Pre bezneho uzivatela je to uz horsie.

[kdave]

A ano, tym vravim, ze btrfs ma slabiny v danej oblasti. Druha vec je, ze vdaka vstavanym snapshotom power failure bugy pri btrfs nie su az tak zhave.

Pro zurnalovany filesystem ma takovy tool velky smysl, protoze je obtizne naskladat operace do zurnalu tak, aby pri preruseni v libovolnem okamziku bylo vzdy mozne po obnove (replay) dosahnout nejakeho konzistentniho stavu. I s velkym usilim mohou zustavat chyby, na ktere se prichazi zridka a tezko se zjistuje, jak se to do toho stavu mohlo dostat.

Je mozne formalne popsat zurnal a paralelni operace na nem provadene a pak testovat tento model. Viz Using model checking to find serious file system errors "[...] We applied it to four widely-used, heavily-tested file systems: ext3, JFS, ReiserFS and XFS. We found serious bugs in all of them, 33 in total. [...]". Stale je ale potreba testovat implementaci, model muze pomoci odhalit zasadni chyby v navrhu nebo prilisnou konzervativnost, ktera muze vest k neefektivite (zmineno tez v tom paperu).

Pridavat pak novou featuru (napriklad checksumovani metadat) je docela peklo, vsechna cest xfs vyvojarum.

Btrfs ma jiny model konzistence, takze simulovat a testovat preruseni ma smysl jen mezi zapisy superblocku. Coz je by default 30 vterin (periodicky transaction commit), jinak se muze dit casteji.

Posledni zasadni (znama) chyba, ktera mohla zpusobit to, ze na disk byly zapsany bloky z ruznych transakcnich epoch, ackoli mely nalezet k jedne, byla opravena v kernelu 3.2. Navic bylo potreba mit vice disku, u jednoho se neprojevovala, plus nejake podminky na mergovani bloku v blocklayeru.

Pro ucely overovani vzajemnych odkazu bloku ma btrfs 'integrity-checker', coz je infrastruktura, ktera hlida provazanost bloku a otestuje pri commitu, jestli je vsechno, jak ma byt. Checker vznikl v dobe, kdy se resila zminena chyba a pozdeji nasel jeste jednu chybu (take tezko dosazitelny corner case).

Poznamka bokem: COW model v btrfs znacne usnadnuje pridavani novych featur vseho druhu, implementace se soustredi na konzistentni upravy struktur v pameti a vubec se neresi zadne slozitosti s potencialnimi pady a polovicatymi zapisy do zurnalu a replayem. (Ale take to neni uplne zadarmo.)

Z tohoto smeru do btrfs pritekaji featury a jeste dost dlouho budou. U xfs nebo ext4 jsme se dockali checksumu metadat nebo inlinovanych souboru a dalsi novinky prichazeji pomalu. Nerikam, ze je to spatne, pokud je hlavnim cilem takovych filesystemu maximalizace vykonu. Z odstupu ale mezi xfs a ext4 neni az takovy rozdil, takze je jasne, ze zustane jen jeden, ktery se jevi lepsi podle dlouhodobych kriterii.

[little.owl]

btrfs fakt není připraven na reálné nasazení (ať "produkční" nebo BFU)

Dnes, pred par hodinama: [GIT PULL] Btrfs for 3.16:

We also have some very hard to find corruption fixes, ....

[redbot]

Ta chyba #1093911 asi skonci s WONTFIX, ale necham se prekvapit. Ted se mi to nechce dohledavat, ale nekdo od Archu to uz reportoval a pry je to vlastnost systemd.

[kavol]

to je možné; pak to jen přibude na seznam věcí, ve kterých systemd reálně zhoršil předchozí stav bez naděje na nápravu ... a pak se někteří diví, že ne všichni systemd milují ...

[jas]

Ja by som do toho nepchal nejak moc systemd. Cloveku staci len nejaky fs s /bin/sash a staticky skompilovanymi fs repair + mount utilitami, o zvysok sa postara root=[dev] init=/bin/sash.

[kavol]

no tak on stačí i boot z cd/usb/sítě ...

pointa byla, že kdysi, před dávnými a dávnými časy, byl režim rescue určen, a skutečně použitelný, pro obnovu systému bez závislosti na tom, jak "zdravý" je root ... dnes když napíšu do bootline "rescue", tak mi naběhne normální desktop, a ano, tento problém opravdu souvisí se systemd

[little.owl]

Prijde mi, ze jedna spise o problemy toolu nad Btrfs, nez vlastniho FS.

U RHEL by to mel byt blocker, u Fedory asi nikoliv.

[kavol]

no, že se vlastní FS rozsypal (jinak bych jej nepotřeboval spravovat, že), není problém?

[little.owl]

Pokud prerusite SATA kabel, vypnete tvrde napajeni bez nejake zalohy ci mate vadnou RAM, mi neprijde poskozeni FS neocekavane. Co by se vsak nemelo stat nikdy, je nemoznost FS opravit ci otestovat a izolovat poskozena data; pak je skutecne dobre ze jste to popsal a reportoval.

[kavol]

Pokud prerusite SATA kabel,

již jsem odpovídal ... pokud systém běží, data má kernel v cache, může zahodit co přišlo potvrzení, že se zapsalo, a zbytek pošle znova, když se kabel znova připojí

pokud se tak nestane, ok, asi není správné házet to na filesystém ale spíš o vrstvu níž na driver k řadiči, ale vim já, jak je to provázaný ... pro mě je podstatný, že tato situace mi zabila systém nad btrfs, zatímco ext2/3/4 nebo reiserfs mi přežil i horší věci (pravda, jednou jsem s reiserfs čekal asi rok na spravení problému v reiserfsck taky, ale v té době bych o něm říkal asi něco podobného jako o btrfs teď, už je to fakt dost let zpátky)

vypnete tvrde napajeni bez nejake zalohy

to se nestalo

ci mate vadnou RAM

hm, v prvém případě běžel memtest přes víkend, v druhém "jenom" přes noc, a žádné jiné problémy nepozoruju ...

mi neprijde poskozeni FS neocekavane.

to sice ne, ale nějak jsem si za ta léta zvykl, že si s tím poradí fsck při startu a neotravuje mě to, natož aby se to rozpadlo do neopravitelného stavu ...

Co by se vsak nemelo stat nikdy, je nemoznost FS opravit

naprostý souhlas, a proto se tady o btrfs(ck) vyjadřuju tak, jak se vyjadřuju ... jinak ď. za odkaz na ten pull request, myslímže je to výmluvnější nežli mé nářky nad dvěma pády na hubu

[Rezza]

Fedora ma mnohem striktnejsi pravidla co je a co neni blocker nez RHEL :).

[little.owl]

Zacinam se bat o sva data na CentOS.

[Sid]

Ake su pravidla RHEL? Ked velky zakaznik povie, ze je to blocker tak to bude blocker aj keby to bola len tlacitko posunute o 1px?

[jas]

Nie, devel ma stale pravo to odmietnut.

[kavol]

Ked velky zakaznik povie, ze je to blocker tak to bude blocker aj keby to bola len tlacitko posunute o 1px?

to si pleteš procesy

zákazníci nemaj co kecat do rozhodování o tom, co je nebo není blocker (ať už pro celý release nebo pro cokoli menšího)

můžou se samozřejmě dožadovat spravení bugu (tedy posunutí tlačítka o 1 px), pokud to nic nerozbije ostatním, a nebudu popírat, že důležitost zákazníka hraje roli v tom, jestli vůbec a jak rychle se opravy dočká, ale to je věc poněkud mimoběžná s tím, jestli se něco rozhodneme vydat i přes známé chyby (což se různě obchází, např. tzv. 0day erraty, tedy to co vyjde zároveň s releasem), a které věci naopak budou vydání blokovat

je nutné brát v potaz, že RHEL není pár náhodně poskládaných bitů, ale složitý mechanismus, kde jednotlivé díly musí zapadat, dodávaný jako celek - tzn. když se v nějakém programu posune tlačítko o 1 px, tak to není problém jen toho programu, ale je potřeba přegenerovat, otestovat a znovu rozdistribuovat instalační média, a podobně

[Michal Kubeček]

Především až na řídké výjimky nebude release cyklus zákazníka synchronizovaný s release cyklem RHEL (a zejména ne u těch velkých) a pro zákazníka není podstatné, jestli bude bug opravený při vydání RHEL, ale jestli bude opravený v době, kdy on má freeze svého produktu, který ho obsahuje.

[pavele]

Mohl by někdo vysvětlit ty limity?

Pokud vím, ext4 má limit pro filesystem a soubor 1 EiB, XFS pro filesystem 16 EiB a pro soubor 8 EiB.

[jas]

To su teoreticke limity, v praxi implementacia ext4 do nedavna koncila cca pri 16 TB (RHEL 6), v RHEL 7 na nom vyvojari trocha zapracovali a zvysili limity. Sucasna implementacia XFS zvlada aspon 8 EB - 1B subory a fs (16 EB - 1 B som neskusal).

Problem s ext4 je aj v tom, ze neskaluje dobre pri velkych fs (operacie su pomale).

Podporovany limit znamena, ze RH bude dany storage na danej verzii podporovat -- tj. v pripade bugov sa ich bude snazit opravovat. Nad podporovany limit nemusi (v praxi sa prizmuruju oci, obvzlast ak je clovek ochotny spolupracovat a testovat).

[kdave]

To su teoreticke limity, v praxi implementacia ext4 do nedavna koncila cca pri 16 TB (RHEL 6), v RHEL 7 na nom vyvojari trocha zapracovali a zvysili limity. Sucasna implementacia XFS zvlada aspon 8 EB - 1B subory a fs (16 EB - 1 B som neskusal).

Tech 8EB je omezeni ve vfs, protoze typ pro offset do souboru je "signed 64 bit loff_t", a validni hodnoty jsou jen kladne 0..2^63-1. Limit na cely filesystem se da overit vyrobenim nekolika xEB souboru, ktere ten filesystem zaplni az pod strechu. Zkousel jsem to onehda s btrfs, dohromady 16EB se tam veslo a vypadalo to opravdu divne :)

[jas]

Ked som sa s tym hral naposledy, tak som pouzival este loopy a ten limit 8E -1 B bol prave kvoli tomu. Teraz by som to asi robil cez dm-sparse -- snapshot nad dm-zero alebo dm-thinp (ale s tym som sa este nehral, tak neviem co vsetko zvlada), loopy su na toto strasne neefektivne.

Este som sa chcel trocha pobavit s xEB fs a RESVSPC, ale na to uz nemam moc cas (dostat ENOSPC na 8 EB fs musi vyzerat este divnejsie ).

[little.owl]

Jinak:

1) dokaze nekdo zhodnotit v nekolika bodech (a) design ZFS versus Btrfs, (b) soucasny stav ZFS a Btrfs, odhad do budoucna?

2) ma uziti XFS ci Btrfs smysl ci vyhodu u +/- desktopu, oproti ext4 a jaky?

Jiste Google, ale pokud se v teto oblasti nepohybujete, neni jednoduche si vytvorit [uplny] obrazek.

[jas]

ma uziti XFS ci Btrfs smysl ci vyhodu u +/- desktopu, oproti ext4 a jaky?

Vyssie limity dokazu vyuzit aj userspace/desktop aplikacie (namatkou mmap 2**47 B suboru a praca s danou pamatou). Pre niektorych moze byt potesujuce, ze nie je apriori 2 % limit na metadata. Tiez dokazu tie FS lepsie vyuzit viac jadier systemu.

Kazdopadne ani ext4 nie je stale mrtvy a ma svoje vyhody (aj ked prevazne historicke -- niektore aplikacie ocakavaju jeho specificke vlastnosti).

[Aleš Kapica]

Nejsem vývojář kernelu, takže mohu napsat jen proč jsem já upřednostil Btrfs před ZFS.

• ZFS byl původně čistě záležitostí Solarisu. Ať se na mě nidkdo nezlobí, ale implementace souborového systému přes FUSE mi přjde poněkud vošajstlich
• ZFS je pojato jako univerzální souborový systém, který v jednom balíku nabízí to, co lze v pohodě zajistit pomoci několika samostatných nástrojů. Oproti tomu Btrfs je souborový systém a o nic jiného se nesnaží.
• Osobně vidím univerzálnost ZFS spíš jako slabinu. Pokud potřebuji blokové zařízení, udělám si ho přes LVM. Pokud ho chci honit kamsi po síti, použiju iSCSI nebo NBD. ZFS se mi z tohoto úhlu pohledu jeví jako blackbox.

A budoucnost? SUN je v kopru. Koupil ho Oracle. To se pochopitelně odráží i na zájmu o Solaris jako takový. Btrfs, právě díky tomu že je v kernelu, má do budoucna velké šance. Až totiž nastoupí na ty manažerské pozice osoby nezatížené minulostí přijde jeho chvíle. Oproti ext4 je mnohem flexibilnější. Já osobně využívám snapshotování, kvóty, on-line změnu velikosti, raid na úrovni extentů a v případě potřeby on-line rekompresi extentů. Viz stránka k Btrfs v naší wiki. Bohužel mám toho celkově moc, a zpracovat to do podoby manuálu není jen tak, takže mám spoustu věcí v plaintextových poznámkách.

• S XFS nemám žádnou osobní zkušenost, jenom vím, že jeho slabinou je náhlý výpadek napájení. Drží si totiž spoustu věcí v paměti a pokud řadič nemá baterku, aby stihnul při výpadku změny zapsat, tak hrozí ztráta dat.
• Na desktopu je to celkem jedno. Já používám Btrfs na notebooku především z toho důvodu, že nevěřím SSD diskům. Proto mám dva SSD disky. A nač mít softwarový raid1 na úrovni celých zařízení, když Btrfs umí data mirrovat rovnou na úrovni extentů. Krom toho mám jako bonus zálohování přes snapshoty. Tohle ext4, ani XFS zkrátka neumí.

[jas]

btrfs je na tom rovnako ako zfs -- obsahuje vlastne implementacie raidu, lvm a par dalsich dm veci. Samozrejme ide dat aj na cisty hw, ale to klucove v btrfs je prave to, ze to maju aj vsetko blackboxnute.

Hocijaka fuse implementacia FS sa neda moc zvazovat na realne nasadenie (skor len ako nudzovka). FS nebude nikdy v userspace (aspon kym sa nepresadia mikrojadra, kde sa user space a kernel space tak trocha prelina) dosahovat rychlost kernel space implementacie.

Ano, XFS malo problemy s power failure, ale na tom sa poslednych par rokov vyrazne pracovalo. A ano, pokial radic klame (tj. tvrdi, ze zapisal data, ked ich mal v cache, ktora nie je zalohovana baterkou), tak si s tym XFS neporadi, ale to ziadny FS. Dizajnovat FS s prihliadnutim na to, ze mi hardware moze klamat o realnom zapise mne osobne pride absurdne.

[Aleš Kapica]

btrfs je na tom rovnako ako zfs -- obsahuje vlastne implementacie raidu, lvm a par dalsich dm veci. Samozrejme ide dat aj na cisty hw, ale to klucove v btrfs je prave to, ze to maju aj vsetko blackboxnute.

No tak to prr!!! I když některé věci mají své paralely u LVM, není to LVM. A implementace raidu je naprosto jiná. Btrfs je souborový systém, a raiduje pouze extenty které se skutečně používají, kdežto MD, nebo LVM RAID replikují kdejaké smetí na úrovni blokového zařízení, bez ohledu na to jestli jde o data užitečná, nebo ne. A to je přesně to co dělá největší režii - že se u nich replikuje a kontroluje kdejaký bordel. Pod pojmem blackbox si představuji něco, do čeho není vidět, což ale není případ Btrfs. Pokud člověk opravdu chce, tak se dostane až k do obsahu těch raw extentů. Jenže proč taky?

Dizajnovat FS s prihliadnutim na to, ze mi hardware moze klamat o realnom zapise mne osobne pride absurdne.

Mě ne. Osobně mi velmi vyhovuje, že starší verzi extentu Btrfs opustí až kdy je bezpečně uložena verze nová. Na Btrfs si cením jeho robustnost a spolehlivost. Honit si brko nad tím který FS je nejrychlejší, tak z toho jsem vyrostl velice dávno a záhy. A věřte že jsem měl i velice rychlá řešení - bohužel ale byla zároveň velmi náchylná na chybu lidského faktoru.

[pavlix]

A implementace raidu je naprosto jiná. Btrfs je souborový systém, a raiduje pouze extenty které se skutečně používají, kdežto MD, nebo LVM RAID replikují kdejaké smetí na úrovni blokového zařízení, bez ohledu na to jestli jde o data užitečná, nebo ne.

+1

[jas]

Samozrejme, ze tie implementacie nie su totozne, ale sprostredkuju prevazne tu istu funkcionalitu (+/-). Chapem ich opodstanenie, ale aj tak sa mi to pri storage moc nepaci. Ja som pod tym blackbox bral hlavne ten aspekt zlepenosti vsetkych implementacii v nejakej krabici. Kazdopadne, to sa v ZFS neda vobec pozriet na to vnutro? Tomu mi pride tazke verit.

Ani btrfs na to nie je dizajnovany. To, ze ju opusta az vtedy je sice pekne (a celkom bezna prax pri FS), ale hw, ktory mu klame ho znici aj tak. Problem je presne v tom 'bezpecne ulozen'. Ak hw klame (nema zalohovanu cache a pri zapise do nej tvrdi, ze data su bezpecne zapisane), tak file system nevie, kedy su ktore data bezpecne ulozene. Staci pridat inteligentny zapis cachovanych dat na disk (tj. nezapisuju sa v tom poradi v ktorom prisli, ale optimalizuje sa zapis, aby sa redukovali potrebne otacky disku) a vypadok energie neprezije nic.

V tomto pripade ide podla mna jednoznacne o dizajnovu chybu hardware, XFS je v tom nevinne. V pripade aspon sekvencneho zapisu cachovanych dat su tu bariery (barriers), ktore by sa o to mali postarat.

[jas]

A implementace raidu je naprosto jiná. Btrfs je souborový systém, a raiduje pouze extenty které se skutečně používají, kdežto MD, nebo LVM RAID replikují kdejaké smetí na úrovni blokového zařízení, bez ohledu na to jestli jde o data užitečná, nebo ne. A to je přesně to co dělá největší režii - že se u nich replikuje a kontroluje kdejaký bordel.

Este k tomuto. Neviem ako to je v sucasnosti, ale vdaka veciam ako discard toto v blizkej dobe nemusi byt pravda. Na urovni dm sa discard uz pouzivat (zneuzivat) zacal (aj mimo ssd, napr. dm-thin).

[Michal Kubeček]

a raiduje pouze extenty které se skutečně používají, kdežto MD, nebo LVM RAID replikují kdejaké smetí na úrovni blokového zařízení, bez ohledu na to jestli jde o data užitečná, nebo ne

Přesnější by bylo napsat: …zatímco MD RAID replikuje pouze chunky, do kterých se něco zapsalo, a LVM RAID pouze extenty, do kterých se něco zapsalo. Nebudeme-li předpokládat, že driver filesystému jen tak z nudy zapisuje do míst, kam vlastně nic psát nepotřebuje, je sice pravda, že se toho obecně replikuje o něco víc, než by nezbytně muselo, ale ne zase o tolik. Jen na začátku bývá zvykem zduplikovat všechno, ale i to lze snadno potlačit.

[Aleš Kapica]

V tom to právě je. Ony totiž nerozlišují jestli těmi změnami naaahodou nerozbijeji FS co je nad nimi.

[Michal Kubeček]

Zkuste být trochu konkrétnější a popsat reálný scénář, jak by replikace dat v rámci MD/LVM RAID rozbít filesystém na příslušném zařízení, aniž by k tomu rozbití došlo, i v případě, že by tam ten RAID nebyl. Mne žádný nenapadá.

[Aleš Kapica]

Jednoduše. Popíšu zcela konkrétní situaci která se mi stala.

Na jednom ze čtyř fyzických disků lokálního md raidu se objevila chyba. Systém přestal data lokálně zapisovat a ukládala se pouze jejich replika přes drbd. Než došla paměť a drbd se rozpadlo.

To se mohu pouze dohadovat, protože jsem se ke stroji dostal v době kdy byl kaput. Bohužel ovšem ne tak, aby chcípnul úplně, takže druhý stroj nemohl převzít roli primáru, protože mu ten první pořád držel potřebnou IP adresu.

Zjistil jsem že jeden z disků je vadný. Vyhodil jsem ho z raidu a zkusil pole namountovat. Vše ze zdálo ok. Předpokládal jsem, že když vypadnul pouze jeden z disků, tak by s tím nemusel mít problém. Jelikož jsem nevěděl kdy došlo k rozpadu DRBD, čekal jsem že lokálně uložená data primárního stroje budou aktuálnější, než na sekundáru.

Čekal jsem že se ztratí pouze data, která se nestihla zapsat, takže jsem dal fsck a nestačil se divit. Jak to doběhlo, tak jsem zjistil, že hromada - i starších dat - zmizela.

Měl jsem sice ještě sekundární stroj, na kterém ukládání dat probíhalo bez problémů, ale neměl jsem odvahu pustit fsck i na tu repliku, protože jsem nevěděl, jestli to nezapsalo přes DRBD nějaké nesmysly i tam.

No a pak jsem zjistil, že není nabouraný jen datový oddíl (ext3), ale také systémový (ext4).

Už jsem na nic nečekal. Sekundární stroj jsem ho rozjel jako primár a následovala kompletní reinstalace celého bývalého primárního stroje. Naštěstí to šlo rychle, protože stačilo zkopírovat systém původního sekundáru, změnit IP, hostname a nějaké drobnosti.

No a pak jsem přikročil ke psaní agenta pro Pacemaker, abych mohl přejít na Btrfs i na sdíleném disku a zbavit se ext FS úplně. (Stalo se loni 7.srpna 2013)

[Michal Kubeček]

Z toho mi pořád nevychází, že by problém byl způsobený MD RAIDem.

[Aleš Kapica]

Tak pokud vycházím z premisy, že je ext4 spolehlivý FS, který může rozhodit pouze chyba na úrovni blokového zařízení (kterým byl v tomto případě SW RAID6), a věřím tomu, že SW RAID6 je schopen ustát výpadek až dvou (ze čtyř) disků, zcela logicky hledám problém na straně kde se objevil - na stroji, kde selhal jeden fyzický disk z tohoto SW RAID6 pole.

A z toho, jakým způsobem se problém projevil, opět logicky odvozuji, že muselo dojít k poškození části FS, která má uloženy informace o i-nodech. K čemuž by u RAID6 nemělo teoreticky dojít ani při výpadku dvou disků ze čtyř. Nuže dobrá, stalo se. Rozdíl mezi ext systémy a Btrfs je především v tom, jakým způsobem vůbec fungují. U Btrfs si většinu potřebných informací tahá extent sebou. Takže pravděpodobnost, že díky poškození části blokového zařízení s metadaty k datům uloženým na jiné části disku o ně přijdu, je mnohem menší.

[Michal Kubeček]

a věřím tomu, že SW RAID6 je schopen ustát výpadek až dvou (ze čtyř) disků

Tady je trochu problém. Jakákoli implementace je schopna se vyrovnat jen s problémem, o kterém se dozví. Takže to všechno funguje perfektně, pokud se chyba projeví selháním zápisu nebo čtení. Bohužel ne vždy odejde disk takhle "slušně", občas se stane, že disk se po nějakou dobu tváří, že je všechno v pořádku, ale čte nebo zapisuje chybná data.

Ve vašem případě je to ještě komplikované tím DRBD, které se občas chová trochu zvláštně (na vlastní oči jsem třeba viděl neomezené čekání pod spinlockem na odpověď od druhého serveru). Hlavně bych ale hledal problém spíš v tom, proč a jakým způsobem ten stroj vlastně "umřel", protože tam může být zakopaný pes.

U Btrfs si většinu potřebných informací tahá extent sebou. Takže pravděpodobnost, že díky poškození části blokového zařízení s metadaty k datům uloženým na jiné části disku o ně přijdu, je mnohem menší.

To je samozřejmě možné, ale na druhou stranu jsou metadata komplikovanější, takže bych se jejich poškození "náhodnou střelbou" bál trochu víc - ale to je jen pocit, ne zkušenost.

[alkoholik]

Porusil jsi dulezite pravidlo "nikdy nic nepredpokladej!".

[Jarda]

Tady něco nehraje. RAID6 nad 4 disky, jeden vypadl, systém přestal zapisovat. Ehm?

[sigma]

Zjistil jsem že jeden z disků je vadný. Vyhodil jsem ho z raidu a zkusil pole namountovat. Vše ze zdálo ok. Předpokládal jsem, že když vypadnul pouze jeden z disků, tak by s tím nemusel mít problém. Jelikož jsem nevěděl kdy došlo k rozpadu DRBD, čekal jsem že lokálně uložená data primárního stroje budou aktuálnější, než na sekundáru. Čekal jsem že se ztratí pouze data, která se nestihla zapsat, takže jsem dal fsck a nestačil se divit. Jak to doběhlo, tak jsem zjistil, že hromada - i starších dat - zmizela.

Ona ta technologie samotných SATA/SAS disků a řadičů nad tím není zázračná, a linuxový SW RAID už vůbec. Pokud vám disk resp. bloková vrstva začne vracet vadná data, tak to není situace, že když vypadnul pouze jeden z disků...

Tohle je právě jeden z důvodů, proč je ZFS navržen tak jak je. Pár let zpět jsem viděl hezkou prezentaci, kde kvalifikovali právě tyhle jevy, kdy už samotný disk, nebo řadič nad ním v klidu vrací vadná data. Nemusíte to asi zjistit - keyword: silent data corruption. Pokud máte rack plný 2TB SATA disků je to dost na to, aby se tím FS zabýval, a nakonec i váš příklad ukazuje, že to má smysl vždy - protože HW na téhle úrovni chybuje, a je dobré to vědět a nemuset předpokládat, že to je OK. Na tom ZFS bylo zejména zajímavé to, že měli postavenou poměrně rozsáhlou automatickou testovací infrastrukturu, která všechny tyhle chyby a třeba výpadky napájení uměla simulovat. To se obávám, že u BTRFS jen tak nebude.

Takže proto má ZFS a BTRFS checksumy dat (pro opravu se ovšem dají použít jen když má FS pod kontrolou i RAID vrstvu), proto některá storage řešení mají checksumy na úrovni blokové vrstvy, nebo provádí alespoň kontinuální "background scan" (to by šlo asi i u mdraid).

[Aleš Kapica]

Takže proto má ZFS a BTRFS checksumy dat (pro opravu se ovšem dají použít jen když má FS pod kontrolou i RAID vrstvu), proto některá storage řešení mají checksumy na úrovni blokové vrstvy, nebo provádí alespoň kontinuální "background scan" (to by šlo asi i u mdraid).

To je právě důvod, proč jsem přešel na Btrfs i na notebooku. Pokud jde o ty interní záležitosti jako je např. průběžná kontrola dat na pozadí, atp. Věřím tomu, že vývoj Btrfs postupně probíhá, takže pokud tam některé věci nejsou, je pouze otázkou času, kdy se objeví. Přijde mi to pořád lepší varianta, než používat FS který je sice taky nemá, ale z principu ani nikdy mít nebude.

[Michal Kubeček]

ZFS je pojato jako univerzální souborový systém, který v jednom balíku nabízí to, co lze v pohodě zajistit pomoci několika samostatných nástrojů. Oproti tomu Btrfs je souborový systém a o nic jiného se nesnaží.

To myslíte vážně?

[mankind_boost]

+1234

[Aleš Kapica]

Dobře, ať se nebavíme tak akademicky. Můžete napsat cca kolik strojů a s jakými OS a FS spravujete? Stačí procentuálně. Tvoří některé z nich i nějaký cluster?

U nás máme se ZFS pouze jeden stroj, na kterém běží Nexenta (OpenSolaris) a který spravuje kolega. K němu mohu říct pouze to, že jde o nereplikovaný standalone stroj, který když se posere za sebe nemá náhradu.

Zato bych mohl vyprávět o ostrých soubojích, které se objevují obyčejně v době, kdy se začne něco srát a není hned jasné co a proč, při kterých musím tvrdě obhajovat svá řešení. Aby se pak zhruba po roce až dvou ukázalo, že jsme byli zase o kus napřed. Mé největší štěstí je, že se spolupracuji na některých věcech s lidmi co patří v této oblasti mezi skutečné autority, takže když je opravdu nejhůř, odkazuji na ně a jejich názor na věc.

[Michal Kubeček]

Promiňte, ale vůbec netuším, jakým způsobem váš příspěvek reaguje na mé pozastavení se nad tvrzením, že zatímco ZFS obsahuje spoustu featur jdoucích daleko nad rámec toho, co si obvykle pod pojmem "filesystém" představujeme, BtrFS je jen filesystém a nic víc.

[Aleš Kapica]

Asi vám uniklo, že to byl jen zvídavý dotaz. Zajímají mě vaše zkušenosti. Možná bych se pak mohl na některé věci zeptat konkrétněji a lecčemus se i přiučit.

[Michal Kubeček]

V současné době už nespravuji kromě vlastních počítačů nic. Ale díval jsem se do kódu MD, takže mám představu, jak funguje, a už jsem byl nucen orientovat se i v kódu DRBD. Většinou se ale spíš zabývám síťovým subsystémem.

[mankind_boost]

Takže vy na to prostě neodpovíte?

[snajpa]

U nas treba nic jineho, nez ZFS nedava smysl.
Leda, az a] bude mit linux poradny IO scheduler (nezajima me tolik scheduling podle procesu, ale jde o efektivni vyuziti disku pod filesystemem), b] poradnou souborovou cache (dcache je vysmech, kdo si neco o ARC precetl, vi - hint: most frequently used + most recently used lists), c] az bude mit neco jako ZIL (tzn. fsync mi nezasekne celej system), d] hierarchicka organizace datasetu je proste potreba, ne jenom hloupy vymysl (poznate pri vyvoji jakehokoliv slozitejsiho uloziste dat).
Jedine diky ZFS jsme schopni mit 90 kontejneru, ktere i neco delaji, nad jednim serverem. S ext4 to proste neslo, stacilo par MySQL a bylo mrtvo.
BTRFS je uplne neco jineho a neda se se ZFS srovnavat, v podstate BTRFS kopiruje akorat "shiny blink blink" featury ZFS, ale implementuje je uplne jinak - Jeff Bonwick se pri navrhu ZFS v kazdem ohledu drzel toho, ze to ma byt Zettabyte FS, tzn. ze na tom lidi opravdu budou mit kvanta dat - pekne je to videt napr. v jeho blogu o space maps (kde jini pouzivaji bitove mapy volnych bloku, on zvolil zase radikalne jiny pristup - jako s celym ZFS). Kdezto u BTRFS se zas premysli v rozmerech masin velikosti notebooku, nebo virtualniho stroje - coz je OK, ale na takove use-cases uz tu FS mame, pod linuxem ale proste chybi FS pouzitelny na velkou masinu.

[kdave]

BTRFS je uplne neco jineho a neda se se ZFS srovnavat, v podstate BTRFS kopiruje akorat "shiny blink blink" featury ZFS, ale implementuje je uplne jinak...

Kopiruje, protoze je zadny jiny nativni linuxovy filesystem nema a uzivatele je chteji, protoze je mozna znaji ze zfs nebo netapp, inispiraci a kopirovani nikdo nepopira.

Designove je btrfs jine, pouziva "shadows and clones", zatimco zfs ma "generation pointers". Viz clanek od O. Rodeha, kde srovnava btrfs a zfs po teto strance. BTRFS: The Linux B-Tree Filesystem (free verze).

Take se lisi interni struktury a diskovy format, takze nezbyva nez to implementovat uplne jinak.

Kdezto u BTRFS se zas premysli v rozmerech masin velikosti notebooku, nebo virtualniho stroje - coz je OK, ale na takove use-cases uz tu FS mame, pod linuxem ale proste chybi FS pouzitelny na velkou masinu.

No, to ze je uz v navrhu podpora pro vice zarizeni, raidy atp, se s masinami velikosti notebooku moc neshoduje.

ZFS ma proti btrfs vyhodu nekolika let deploymentu ve velkem, takove zkusenosti s btrfs nejsou. Je jasne, ze kdyz hledam neco na velkou masinu a chci, aby to fungovalo uz dnes, tak sahnu po tom vyzkousenem.

Podpora od vendoru pribyva, casem budou bezna "hotova reseni" v podobe NASu, rozsirovani mezi prostym lidem na noteboocich je podle me primerene a prispiva k tomu, ze si na btrfs postupne zvykame.

[little.owl]

Designove je btrfs jine, pouziva "shadows and clones", zatimco zfs ma "generation pointers". Viz clanek od O. Rodeha, kde srovnava btrfs a zfs po teto strance. BTRFS: The Linux B-Tree Filesystem (free verze).

Konecne nejaky rozumny dokument. Diky.

[kdave]

Zmiňovaná free verze, která bohužel neobsahuje to detailnější porovnání rozdílů zfs/btrfs. Škoda, ale třeba o tom někdo napíše článeček.

[bohyn]

ZFS uz ma i kernel modul zfsonlinux.org. Vyhodu ZFS vidim v ARC (chytrejsi nez linuxova LRU cache) a L2ARC na SSD - s tim dokaze byt ZFS brutalne rychly.

[kdave]

Vyhodu ZFS vidim v ARC (chytrejsi nez linuxova LRU cache)

Zrovna v souvislosti se zfsonlinux je pametova cache problem, protoze nevyuziva tu existujici, zfs si dela svoji vlastni spravu a s tim svoje nedoresene problemy (ticket je zavreny z duvodu obsahlosti, ne protoze uz by se vedelo jak to s temi cachemi udelat).

[bohyn]

ZFS nepouziva systemovou cache, protoze ma chytrejsi ARC. Pokud chcete pouzivat linuxovou cache, neni problem, ARC se da vypnout/zapnout per filesystem, popripade povolit jen na metadata.

[little.owl]

ARC (chytrejsi nez linuxova LRU cache)

Viz. treba popis zde.

[kdave]

To se úplně nabízí k benchmarkování, ale nenašel jsem, že by to někdo už porovnával. Linuxová page cache není úplně hloupá, nepoužíva naivní LRU. Ten paper, co odkazoval little.owl je z roku 2003, od té doby se lecos změnilo.

Pro naivní LRU je nejhorší případ jednorázového čtení, v kombinaci s občasným opakovaným přístupem k jiným datům, která jsou postupně vytlačena.

Jak čtu o tom ARC, tak má seznamy pro recent/frequent přístup stránky a adaptivně zvětšuje/zmenšuje jednu z těch cache podle loadu. Linuxová page cache má něco podobného, active/inactive seznamy stránek. Jednorázové čtení by časem zaplnilo inactive seznam a odtamtud by rychleji vypadávaly, zatímco v active seznamu budou ty častěji přistupované.

Rozdíl v těch algoritmech je jakým způsobem se rozhodují, kde je ta hranice a jak moc ještě zvětšovat jednu část na úkor druhé. Nestudoval jsem implementace, je možné, že ARC se adaptuje rychleji v nějakých situacích, ale rámcově v tom nevidím zásadní rozdíl.

Linux nabízí možnost programům dát kernelu hint přes fadvise(2) o způsobu použití dat čtených ze souboru.

Pro ten příklad s jednorázovým čtením je možné použít FADV_NOREUSE nebo FADV_DONTNEED, čímž by se mělo eliminovat vytlačování často přistupovaných stránek, a případně jim dát ještě FADV_WILLNEED.

Obecně je těžké napsat cachovací algoritmy pro široké spektrum loadů, takže se dělají kompromisy a lokální adaptace a detekce typu přístupu (random, sequential), ale možnosti jsou omezené a trackování má svojí režii.

V případě, že je u aplikace dopředu známý typ přístupu k datům, je lepší to řešit už na této úrovni a neočekávát, že to za mě magicky udělá page cache. (Předpokládám, že mám aplikaci, kde tohle má vůbec smysl optimalizovat.)

ARC na metadata je zřejmě jiný případ, tohle si filesystémy můžou dělat úplně po svém s i bez page cache. Btrfs ji používá, ale nedává hinty o frekvenci přístupu k blokům, takže v patologických případech můžou z cache mizet důležité stránky (například root node u b-stromu). Je v plánu to upravit alespoň proti tomuhle případu a zahazovat směrem od listů ke kořenům. Infrastruktura k tomu existuje, shrinkery.

[snajpa]

Inactive/active mi uz z prekladu zni jako neco uplne jineho, nez most frequently/most recently used. Linuxova cache opravdu hloupa je, na to mi staci videt ten rozdil v chovani v praxi - tefy, minimalne je uplne hloupa pro repetitivni zateze typu server, okorenene uplne nahodnou aktivitou okolo (aneb co se deje, kdyz ma clovek hodne ruznorodych kontajneru, jako my). Btw, na LWN se nedavno mihnul clanek, ze se nekdo konecne probral a chce tu cache v linuxu prepsat - takze asi fakt neni idealni.

[David Jaša]

Ono něco bylo i přeloženo tady.

[little.owl]

To se úplně nabízí k benchmarkování, ale nenašel jsem, že by to někdo už porovnával.

+1

Ten paper, co odkazoval little.owl je z roku 2003, od té doby se lecos změnilo.

Abych to upresnil, clanek je z 2009, puvodni desing paper ARC, ktery byl udelan u IBM, je skutecne z 2003, a je zde.

Rozdíl v těch algoritmech je jakým způsobem se rozhodují, kde je ta hranice a jak moc ještě zvětšovat jednu část na úkor druhé.

Tedy, hodne nepresne, jak jsem to v rychlosti pochopil.

ARC udrzuje dva listy: the most recently used a the most frequently used, pricemz strategie je, ze by oba listy mely ukazovat na +/- stejnou velikost - velikost cache a podle loadu se adaptivne rozhoduje, co se ve skutecnosti udrzuje v pameti. Algoritmus trochu vypada jako adaptivni predikce toho, jaka page bude potreba priste, jakysi filtr pro odhad "temporal locality".

Linux. Standardni LRU chyby informace jak casto se ke strance pristupuje a proto se udrzuji zminene listy active/inactive, navic unevictable, pricemz existuji strategie jak stranky presouvat mezi listy a shrink-nout inactive list. Kod je v mm/vmscan.c.

Ty pristupy jsou jine a asi diky mojim DSP zakladum se mi zda ARC srozumitelnejsi, je tam vice elegantni statistiky. U Linuxu je to pro me cerna magie, mozna tim, ze nemam dokumentaci, krome ne uplne transparentniho kodu, ale je dost mozne ze diky vecem jako shrinkers pujde dobre vyladit.

[bohyn]

Pro naivní LRU je nejhorší případ jednorázového čtení, v kombinaci s občasným opakovaným přístupem k jiným datům, která jsou postupně vytlačena.

IMHO je v linuxu stale naivni LRU. Nedavno jsem stahnul ze serveru logy (pres scp) a pote smazal a projevilo se to vyprazdnenim cache (kernel 3.2.1).

[little.owl]

Ne, algoritmus ma povedomi o cetnosti.

[snajpa]

At jsem se snazil, jak chtel, nenasel jsem to tam. Asi mluvis o implementaci njakeho jineho linuxu, nez vsichni pouzivame. Btw, vcelku vyzivne cteni - i kdyz mne celkem uvedlo do deprese, protoze jsem si nemyslel, ze to muze byt az tak totalne 'bez designu' a naprasene vlivem casu - tady. A vubec, jakou ma cenu presvedcovat fanatiky, co si mysli, ze linux dela vsechno nejlip Vsak v tomhle jsou linuxaci uplne stejni, jako se tu nadava na windowsaky... Smutne. Jeste kdyby s vama praxe souhlasila, ze to ma linux vsechno nejlip...

[little.owl]

At jsem se snazil, jak chtel, nenasel jsem to tam.

Slo mi o to "naivni", nehlede k tomu, ze ona to ve sve podstate ani LRU neni, jak se zminuje i v onom dokumentu, byt ma v sobe LRU prvky. Zminovana LRU-2Q je ve sve podstate dvoufrontova implementacni variace LRU-K, kde K je 2, a temporalni informace se tak pouziva. Toho ze pozice stranky v listu zavisi i na velikosti listu, nikoliv na casu posledni reference a ze listy jsou ignorovany, kdyz se provadi paging out, jsem si vsiml a spise to zvysilo moji nejistotu, jak to vlastne cele [dynamicky] funguje; ani vas [starsi] odkaz mi moc nepomohl.

, ze to muze byt az tak totalne 'bez designu' a naprasene vlivem casu

Je to hodne evolucne nalipane, proto jsem nahore psal, ze ARC mi prijde srozumitelnejsi.

Jeste kdyby s vama praxe souhlasila, ze to ma linux vsechno nejlip...

To jsem ale nikdy netvrdil.

[snajpa]

OK, uz te chapu. "Ma povedomi" mysleno jako neprimo to z toho algoritmu vyplyva, to zrejme jo - ten kod je ale takovej gulas, ze ani to v tom poradne nevidim. Proc vubec nevzit rovnou ARC a neimplementovat ji misto page cache, jak v soucasne podobe je? Je tam neco, co by tomu branilo? Je pravda, ze jsem asi prilis zasedly na "vetsi systemy", ze mi mozna unikaji embedded - ale ARC mi samotna jako moc pametove neefektivni neprijde - branilo by tomu neco? Tedy krome toho, ze to zatim nikdo neudelal.

[little.owl]

Kouknul jsem se behem obeda na puvodni dokument referovany ve vasem odkazu, LRU-2Q, je to skutecne variace LRU-K. Ja bych nebyl tak kriticky, ten algoritmus je proste stary - oni to treba testovali a odladovali na DB2 pod loadem v 1994 - ted je situace, treba s vasimi kontejnery, asi uplne jina, ostatne i HW. To ze to udrzeli uz dvacet let pouzitelne, i za cenu ruzneho netransparentniho hackovani, nevidim jako neuspech.

Proc vubec nevzit rovnou ARC a neimplementovat ji misto page cache, jak v soucasne podobe je?

ARC byl vyvinut pred deseti lety a od te doby se to opet posunulo. Existuji i jine algoritmy, treba CART - resi tam problemy ARC - treba nutnost aktualizovat listy pro kazdy page hit. Problem nebudou jen patenty, ale fakt ze Linux ma plno specifickych veci a scenaru uziti, ktere budou hrat roli - reseni virtualizace, cgroups etc. - musi se to usit na miru pro pristich dvacet let a hned to nebude. Co se planuje a jestli na tom nekdo pracuje - asi ano - nevim.

[little.owl]

Tak jsem se koukal, co je noveho s patenty, a hle, par dni zpet publikovano, Red Hat: Mechanism for Page Replacement in Cache Memory. Nevim nakolik je to uzitelne, ale resi se tam veci, ktere bych cekal, jako (a) trackovani per aplikaci, (b) NUMA architektura.

[snajpa]

Diky za odkazy. Pozitivni zaver z toho tedy je, ze se muzeme tesit, ze se to zlepsi. Alles gut

[kdave]

Btw, vcelku vyzivne cteni - i kdyz mne celkem uvedlo do deprese, protoze jsem si nemyslel, ze to muze byt az tak totalne 'bez designu' a naprasene vlivem casu - tady.

Jen doplneni, to je z knizky "Understanding the Linux Virtual Memory Manager", ktera popisuje kernel 2.4. Jsou tam vzdycky na konci poznamky jak je to v 2.6 udelane jinak. Podobny dokument, ktery by popisoval chovani na jadrech rady 3.x, neznam. Na MM wiki jsou nejake zminky o jinych page replacement algoritmech, ale i tak dost stare (2008), AdvancedPageReplacement. Je tam zminen i CART, o kterem psal nize little.owl.

A vubec, jakou ma cenu presvedcovat fanatiky, co si mysli, ze linux dela vsechno nejlip Vsak v tomhle jsou linuxaci uplne stejni, jako se tu nadava na windowsaky... Smutne. Jeste kdyby s vama praxe souhlasila, ze to ma linux vsechno nejlip...

Tohle neni argument. Me taha za usi, kdyz od "zfs lidi" slysim, ze linuxova page cache je hloupa bez nejakych presnejsich informaci nez "me to funguje takhle", nebo protoze to rekl Jeff Bonwick.

Udelat poradne mereni stoji cas, ktery kazdy z nas radeji venuje jinym vecem. Nicmene, me zajimaji ty rozdily mezi ARC implementovanou v zfs porovnanou s tim, co je ted mozne vyzdimat z linuxove implementace page cache, takze si s tim casem pohraju. Jednak proto, ze to muze odhalit chyby, a druhak, abych mel nejake padnejsi argumenty, az zase prijde podobna namitka.

[kdave]

IMHO je v linuxu stale naivni LRU. Nedavno jsem stahnul ze serveru logy (pres scp) a pote smazal a projevilo se to vyprazdnenim cache (kernel 3.2.1).

A to vypovida o cem? To, ze se z page cache zahodi stranky po smazani souboru je z definice. To, ze se data po cteni nactou do cache je jasne, protoze k tomu cache slouzi. Pokud na stroji v tu chvili nebezel jiny load, ktery page cache aktivne pouzival, pak nebyl duvod se zachovat jinak.

Bez dalsich cisel je to nicnerikajici tvrzeni, nevime velikost RAM, nevime stav pameti pred a po nakopirovani, nevime load, nevime velikost souboru, nevime nastaveni zakladnich sysctl parametru pro page cache. V lepsim pripade nas zajimaji i periodicke statstiky o stavu pameti v prubehu kopirovani.

Krome toho kernel 3.2 je na nejake mereni dost zastaraly.

[little.owl]

ZFS uz ma i kernel modul zfsonlinux.org.

A stabilita a spolehlivost teto implementace?

[snajpa]

vpsFree na tom bezi uz nejakou chvili, samozrejme to nebylo bez porodnich bolesti a clovek musel prijit na to, jak to poradne otestovat, trochu si povybirat commity a tak - ale zrovna par dni zpatky byla releasnuta verze 0.6.3, kterou povazuju opravdu za hodnou produkcniho nasazeni.

[kdave]

S XFS nemám žádnou osobní zkušenost, jenom vím, že jeho slabinou je náhlý výpadek napájení. Drží si totiž spoustu věcí v paměti a pokud řadič nemá baterku, aby stihnul při výpadku změny zapsat, tak hrozí ztráta dat.

U xfs je ten problém, že pokud se neudělá fsync, tak je možné, že se za celou dobu života nového souboru neuloží jeho velikost. Data se průběžně zapisují na pozadí nebo s fdatasync, ale metadat se ani jedno netýká, a kůli výkonnosti se prostě změna velikosti nežurnáluje. Takže po výpadku se objeví spousta nulových souborů.

Když si přijdete postěžovat do xfs mailinglistu, tak vám řeknou, že je to chyba aplikace, protože měla fsyncovat a nespoléhat na to, že např. ext3 fsyncuje trochu jinak a že se to bude chovat stejně i na xfs.

Jinak historicky xfs nulovalo poškozené soubory a nesnažilo se je to opravit, prý protože u SGI se hodně počítalo, a bylo jednodušší to spočítat znova, když byl soubor 0 než to obnovovat. Ale to už je opravené.

Co se týče cachovaní dat v paměti a potenciální ztráty při výpadku, to je vlastností všech filesystémů s delayed block allocation. To je xfs, ext4 a btrfs. Po výpadku je filesystém v konzistentním stavu, ale data co měl v paměti jsou ztracena. Kdo si všiml, že ext3 se to netýká, má bod.

[petr_p]

Protože XFS je rychlejší než ext4.

[little.owl]

Zalezi na situaci. Jake mohou mit vliv na toto srovnani zmeny zde?

[petr_p]

Obávám se, že prachbídné. Buďto máte zátěž, kdy jen jeden proces dělá I/O, pak se multique nevyužije, protože budete vše směrovat na jeden uzel. Nebo budete mít souborový systém s nevhodnou architekturou, takže furt bude něco synchronizovat mezi uzly. (Ne nadarmo se uvedený dokument opíral o pomalé RMA mezi uzly.) Nebo zahodíte XFS i ext4 a použijete OCFS2 nebo GFS2 či jiný distribuovaný souborový systém, kde DRBD bude moci efektivně využít multiqueue jakožto náhradu sítě.

Osobně se domnívám, že většině lidí bude souborový systém ukradený, protože multiqueue použijí jako blokovou podložku pro virtuální stroje.

[little.owl]

Nebo budete mít souborový systém s nevhodnou architekturou, takže furt bude něco synchronizovat mezi uzly.

Ano, prave.

[little.owl]

Jinak. Ctyri I/O intenzivni procesy, kazdy na vlastnim jadre. Dva procesy velmi rychly kontinualni zapis dat, dva procesy mene intenzivni random write/read (mmap(), podobny approach jako MongoDB). Pomery datovych toku dane, kontinualni zapis automaticky genereruje random R/W. Jedno SSD - HW limitace, v nejhorsim lze rozsirit na dve. Cil je maximalizovat spickovy datovy tok/propustnost ukladu dat. Nepouzit fs a jit na block layer je asi cesta. A hint?

[mam]

Na starsom servery ostat jedine na centos 6, kedze verzia 7 podporuje len 64bit.

[R]

To musi byt este starsie P4 (resp. Xeon z neho odvodeny, pripadne este nieco starsie). Lebo uz P4 s LGA775 podporuju 64-bit.

Inak tiez mame par starych serverov (P3 Celerony a dokonca aj P2) - sluzia dobre, tak nie je dovod na vymenu. Debian bude aj nadalej pre 32-bit.

[kouzer]

Hm a systemd je default...

[Conscript89]

A co vim, tak ani nejde nahradit.

[hnidopich]

A co vim, tak ani nejde nahradit.

Co je to za plky? Jakze vim nejde nahradit! Emacs tam je tiez a v najnovsej verzii. <FLAME>Ale preco by to niekto robil, ze? </FLAME>

[R]

Ja vim, on vi, ty pico!

[Heron]

Ehm, kdo tohleto zablokoval? Vždyt se jedná o výčet několika textových editorů, vtipně poskládaných do věty, která po doplnění diakritiky může mít jiný význam -- ale tahleta věta se ve světě Linuxu objevuje minimálně 16 let (kdy jsem ji slyšel poprvé). Tohle tedy adminovi dost ujelo.

[Michal Kubeček]

Ehm, kdo tohleto zablokoval?

Hint: slovo "administrátor" je klikací.

[Heron]

No vidíš, já a to nikdy neklikl, myslel jsem, že to prostě vede na redakci. Zase jsem chytřejší.

Snad se i Max naučí další editor a nebude pico považovat za vulgaritu

[Max]

Bohužel, to není o vědění, ale o chápání :-/
Zdar Max

[Conscript89]

Hm, Emacs provozuju nad systemd, bez nej by to v RHELu 7 neslo Ale neni to zase tak spatny napad zkusit napsta init v elispu.

[R]

Cize nemas GNU/Linux, ale Emacs/Systemd?

[Andrej]

Tohle je jenom pro Enterprise nebo se to dá používat i na jiných lodích?

[Leinad]

Sice to není certifikované, ale mělo by to jít i na sesterských lodích

[Conscript89]

Pokud je ovsem 64B.

[alkoholik]

Borgove to nainstaluji kdekoliv. To vis, otevrena architektura..

[marbu]

I jine lode jsou podporovane (link z roku 2013, takze to neni o rhelu 7).