Plán vývoje Red Hat Enterprise Linuxu poodhalen

Denise Dumas poodhalila plán vývoje Red Hat Enterprise Linuxu. V rozhovoru pro TechTarget uvedla například, že v připravovaném Red Hat Enterprise Linuxu 7 bude výchozím grafickým uživatelským rozhraním GNOME Classic Mode a výchozím souborovým systémem pro boot, root a uživatelská data bude XFS. Plán vývoje a připravované novinky byly prezentovány také na konferenci Red Hat Summit 2013. Přednášky jsou k dispozici například na YouTube (Red Hat Enterprise Linux Roadmap: 1. část a 2. část).

14.6.2013 14:26 | Ladislav Hagara | Zajímavý článek

Komentáře

[Jiří J.]

GNOME Classic Mode? To jsou mi novinky.

Ale jo, třeba už nás ti nahoře i vyslyšeli v tom, že by se Gnome 3 asi špatně prodával do míst, kde je teď Gnome 2.

[Ladislav Hagara]

Denise Dumas říká, že to musí být opravdu těžké pro lidi od GNOME, kteří milují moderní rozhraní. Nelze ale chtít po administrátorech, kteří mohou spravovat současně RHEL 5, 6 i 7, aby sedmičku ovládali úplně jinak.

[pavlix]

Denise Dumas říká, že to musí být opravdu těžké pro lidi od GNOME, kteří milují moderní rozhraní.

Denise je v tomto ohledu velmi tolerantní a milá. Nicméně nikdo nechce od Gnomáků, aby přestali pracovat na svém moderním rozhraní, jen zde zřejmě Red Hat prosazuje své korporátní zájmy, když tlačí své vlastní placené vývojáře do údržby classic mode.

[w4rr10r]

...není to v podstatě většina vývojářů GNOME?

[pavlix]

A není to jedno? Když chce člověk od nějaké firmy pobírat každý měsíc plat, neměl by pro něj být problém se smířit s tím, že pro ni bude muset alespoň někdy pracovat.

[petr_p]

Že by ani Ábíčku se nevyhnula diskuze „Red Hat ovládá Gnome?

[Tomáš Bžatek]

Dalsi haters diskuze. Vetsina tech core Gnomaku pracuje v RH temer od zacatku projektu.

[pavlix]

Haters diskuze? Ani mi nepřijde, já tam spíš vidím dohadování se o tom, zda dotyčný napsal blbost, či nikoliv.

[Sešívaný]

Což je, myslím, velmi rozumný přístup. Je zachována určitá kompatibilita rozhraní a kdo chce, může používat to nové.

[kavol]

RHEL 5, 6 i 7

hej, 3 a 4 ještě nejsou mrtvé!

[.]

Hmmm... I 2.1 by se tu našla. Když ti aplikační odmítají testovat migrovanou aplikaci na novějších OS. Darebáci líní.

[kavol]

našlo by se ledacos, já mluvil o tom, co je stále podporováno

[23123123]

preco XFS ? preco nie ext4 ? nie je dost stable ? ma performance problemy ?

[zippy]

XFS bolo v poslednej dobe prepisane a ma vyrazne vyssiu rychlost zapisu a citania nez ostatne FS. Dokonca vyvojari XFS tvrdia, ze bottleneck je teraz vo VFS. Tak mozno aj preto sa rozhodli pre XFS.

[erino72]

Cakal by som ze pojdu skor do btrfs ktore chceli natlacit do fedory :D

[little.owl]

Btrfs ve Fedore uz davno je. To ze se kazdy release najdou lide, ktery si mysli, ze by to mel byt uz default file system je jina vec.

[Tomáš Bžatek]

btrfs jsem zrovna v sobotu vykopal pryc. Tak pomaly FS jsem dlouho nevidel (na 3.9.5 kernelu).

[jas]

Ta pomalost by sa snad este nejak dala prezit, pri najmensom je tam aspon nadej, ze sa to zlepsi. Osobne mi pride horsie, ze si implementuje vsetko sam (lvm, raid a pod.) -- novy zdroj bugov. Tiez moc nechapem ako je mozne, ze mu nieco take prechadza. Obvzlast, ked si spomeniem ako na to bolo nadavane v pripade reiser 4, ktory tak riesil len komprimaciu a kompresiu (tam to paradoxne bolo podla mna omnoho viac pochopitelne, kedze na to vo VFS nebola podpora).

PS: Ak ma niekto lepsie informacie a v btrfs sa to vsetko riesi skutocne cez VFS, tak sa rad necham poucit, ale pride mi to nepravdepodobne s prihliadnutim na to, ze maju vlastnu implementaciu lvm aj raid (vyvoj btrfs sledujem len velmi okrajovo).

[Petr Ježek]

Do fedory byl brtfs zaveden, aby bylo více neřízených testerů.

[little.owl]

a ma vyrazne vyssiu rychlost zapisu a citania nez ostatne FS.

Nejaka cisla by byla? Zrovna o tomhle jako duvodu bych pochyboval, stejne jako nasazeni "poslednej dobe prepisaneho" file systemu.

[Leinad]

Řekl bych, že vychází z článku: http://lwn.net/Articles/476263/

[little.owl]

Diky, tohle mi uslo, xfs jsem po spatne zkusenosti z predchozich let odepsal, mozna chybne. Tohle me zaujmulo a mozna to vysvetluje volbu Red Hat:

Metadata-heavy workloads can end up changing the same directory block many times in a short period; each of those changes generates a record that must be written to the journal. That is the source of the huge journal traffic. The solution to the problem is simple in concept: delay the journal updates and combine changes to the same block into a single entry.

The actual delayed logging technique was mostly stolen from the ext3 filesystem. Since that algorithm is known to work, a lot less time was required to prove that it would work well for XFS as well. Along with its performance benefits, this change resulted in a net reduction in code.

One thing that was not required was any sort of on-disk format change - though that may be in the works in the future for other reasons.

Delayed logging is the big change, but far from the only one. The log space reservation fast path is a very hot path in XFS; it is now lockless, though the slow path still requires a global lock at this point. The asynchronous metadata writeback code was creating badly scattered I/O, reducing performance considerably. Now metadata writeback is delayed and sorted prior to writing out.

So how does XFS scale now? For one or two threads, XFS is still slightly slower than ext4, but it scales linearly up to eight threads, while ext4 gets worse, and btrfs gets a lot worse.

But the big challenge for the future is in the area of reliability; that may require some significant changes in the XFS filesystem.

Ext4, instead, suffers from architectural scalability issues. According to Dave's results, it is not the fastest filesystem anymore. There are few plans for reliability improvements, and its on-disk format is showing its age. Ext4 will struggle to support the storage demands of the near future.

Ext4, Dave said, is suffering from architectural deficiencies - using bitmaps for space tracking, in particular - that are typical of an 80's era filesystem.

Posledni bod mohu potvrdit. Bitmapy setri pamet, ale z hlediska performance a soubezneho pristupu je nocni mura.

[David Jaša]

Ono asi nebude náhodou, proč RH podporuje XFS jako jediný FS pod Glusterem (RHS) nebo pro Scalable FS (oddíly > 16 TB)...

[Šangala]

Já si myslím, že pochybuješ správně, v rámci testování jsem testoval i jednotlivé FS a třeba tady XFS v zásadě obsadil čelo, nicméně rozdíly jsou velmi malé a dost záleží na čem „leží“. Spíš byse přiklonil, podle předchozí jinak seřazenéno, k prohlášení: „XFS má nižší nároky na CPU“ než jiné FS.
Nicméně dělal jsem groβe-big test velkého množství souborů (až set miliónů), který jsem musel přerušit a jsem ve fázi přehodnocení metodiky (a hlavně ve fázi „nemám na to čas“), protože velmi zásadně to ovlivňovali úplně jiné faktory (včetně monitoringu testu) a výsledky byly v zásadě neseřaditelné a říkající asi jen velmi specifické drobnosti (co z toho lezlo furt stejně XFS nejmín náročnější na CPU a btrfs nejvíc, stabilní hodnota, nicméně s nezajímavým rozdílem).
A k prohlášení bych přidal: „XFS je dlouhodobě odzkoušený, nenáročný(, nerezervující si prostor) a »jednoduchý« FS - tudíž: »super volba« “.

[little.owl]

Vysledky vaseho testovani jsem videl, hezka prace. Jediny problem co tam vidim, je uziti CentOS, ktery pouziva starsi kernel. Zmeny v xfs by meli byt 3.3+, stalo by to za to otestovat s novym kernelem.

Me ted spise zajima nova BCache SSD/HDD, ktera prichazi v 3.10, to je presne co potrebuji.

[David Jaša]

Spousta částí kernelu aktuálního RHELu má blíž k upstreamu, než k uváděné verzi.

[little.owl]

No a jsou ty zmeny v xfs backportovany do soucasneho RHEL 6.x?

[David Jaša]

rpm -q --changelog kernel naznačuje, že ...

[little.owl]

RTFM nebo spise RTFC, ze? ...

[jas]

Asi najdolezitejsia vec z hladiska vykonu (delayed logging) tam je od RHEL 6.2.

[little.owl]

Koukam do logu, tam je zillion changes.

[jas]

Myslim, ze takmer vsetky patche z 3.2 tam uz budu + celkom podstatna cast z 3.4 (a pokial ide o opravy chyb/vylepsenia vykonu nevyzadujuce vyraznejsie backporty, tak aj zmeny z novsich jadier). Detailnejsie by na to vedel odpovedat Dave Chinner, ktory stoji za asi vsetkymi vacsimi zmenami v xfs v rhel6

btw: Pre zaujemcov o detaily ohladom xfs (ohladom jeho vyvoja, pripadne pokial s nim mate nejaky problem, ktory chcete aj riesit) odporucam xfs mailing list.

[kyytaM]

EnhanceIO, Bcache or DM-Cache? :D

[little.owl]

Jen bez integrace v mainstream kernelu a podpory distribuce je to moc prace ... takze az F20.

[Michal Vyskočil]

XFS v zásadě obsadil čelo, nicméně rozdíly jsou velmi malé a dost záleží na čem „leží“.

Ony ty malé rozdíly při opravdu velmi velkém nasazení zase tak malé nejsou .

A k prohlášení bych přidal: „XFS je dlouhodobě odzkoušený, nenáročný(, nerezervující si prostor) a »jednoduchý« FS - tudíž: »super volba« “.

Na to jednoduchý není afaik dost uvozovek. Nicméně je až s podivem, že i přes tu irixovou emulační vrstvu to běhá tak dobře.

[lertimir]

Co myslíte pod "irixovou emulační vrstvou"?

[Michal Vyskočil]

XFS byl původně napsán pro IRIX a až později portován na Linux, takže linuxové VFS si povídá s XFS prostřednictvím mezivrstvy. Více informací je v Porting XFS to Linux a z lkml plyne, že to rozhraní tam stále je.

[lertimir]

To že XFS je od SGI jsem věděl. Jen jsem si myslel, že interface mezi filesystémem a operačním systémem v unixu a linuxu je podobnější a že v té vrstvě by skoro nic nebylo.

[Lukas]

Zadna takova vrstva neexistuje :) Navic v tom odkazovanema mailu se o nicem takovem ani nemluvi.

[little.owl]

Taky jsem na to koukal ... jak jsem jen pochopil, kdysi museli nektere veci kdysi emulovat .. treba here and here ... ale ted uz mi to prijde out-of-date.

[Michal Vyskočil]

Mluví se o XFS/VFS layer a XFS core, což je to, co jsem myslel. Tohle rozdělení vzniklo v důsledku portu z Irixu. Je dost dobře možné, že v minulosti byla daleko tlustější, ale například xfs_vnode.h je v kernelu stále a přesně o tom se odkazuje dokument VFS glue.

[tuxmartin]

A co JFS? Jake ma vyhody/nevyhody? Nikde nemuzu najit zadne zajimave srovnani a hlavne zkusenosti s ostatnimi linuxovymi fs. V testu vypada celkem dobre.

[Michal]

Nevyhody - JFS neni podporovane zadnou velkou firmou. Tudiz se o jeho vykon, rozvoj a pripadne problemy nebude zajimat tolik lidi jako o XFS nebo o [KdoViCoJeTedCoolvSuse]FS. To mi prijde docela zasadni.

[Stanislav Petr]

IBM ti neprijde dostatecne velky? Jak vlkou firmu si teda prestavujes?

[Ivan]

IBM ma JFS2. Navic Linuxovy JFS je port z OS/2 a ne z AIXu.

[Michal Kubeček]

IBM ma JFS2.

V Linuxu je JFS2, stejnějako v AIX. To, že se JFS2 poprvé objevil v OS/2 Warp Server, je jen shoda okolností. Původní JFS1 AFAIK de facto na ničem jiném než na AIX fungovat ani nemohl.

[Michal Kubeček]

Já s ním mám zkušenosti velmi dobré. Problém je hlavně v tom, že ho moc lidí nepoužívá, takže se o něm moc nepíše a nemluví, takže se ho málokdo rozhodne používat, takže …

[little.owl]

Ale porad jsme se nedozvedeli, proc by ho nekdo uzivat mel ... Tedy, proc ho pouzivate vy?

[Václav HFechs Švirga]

Já ho nasadil na jednom noťasu na /home, někde jsem četl, že je nenáročný na CPU (méně než jiné fs), takže větší výdrž baterky a nehrozí u něj ten problém, jako u XFS, kde když je rozepsaný soubor a vypne se počítač, tak se přepíše nulama. Jestli je to ale pravda nevím , v každém případě problém s ním nikdy nebyl. Ale ten noťas byl výkonostní křáp, proto jsem tak šachoval a na normální stroje dávam vždy osvědčený ext4.

[jas]

...a nehrozí u něj ten problém, jako u XFS, kde když je rozepsaný soubor a vypne se počítač, tak se přepíše nulama.

Velmi zjednodusene a zle interpretovane. Nedostatocne podmienky.

• pocitac musi byt vypnuty nasilim (bez umount)
• tyka sa to hlavne cerstvo vytvorenych suborov (< 1 minuta od zapisu + rezerva na skutocny zapis dat, po 60 sekundach sa vola flush vo VFS)

Co sa v skutocnosti (zjednodusene) deje: Z dovodu poziadaviek na rozumny vykon fs sa data nezapisuju okamzite pri ich vytvoreni (nie, okamzity zapis skutocne nik nechce pre kazde IO; ak to aplikacia potrebuje, tak je tu fsync a fdatasync), ale az ked je to pre fs vhodne (aby sa nezapisovali zbytocne data o velkosti mensej ako je velkost bloku a pod. dovody). Dalej sa data hlaviciek suborov (nazov, lokacia, velkost a pod.) nezapisuju zaroven so skutocnymi datami suboru (dovodom je opat vykon). Vysledkom je existencia prazdnych suborov (hlavicka bola zapisana, data suboru nie). Nieco podobne sa deje vo vsetkych file systemoch, akurat ext3 pouziva hack, ktory vyvolava flush kazdych 5 sekund a ext3 spolu s ext4 hadzu podobne null subory do lost+found, takze ich nie je vidno a uzivatel si tak casto ani nevsimne, ze o nejake data prisiel (co je uprimne snad este horsie).

Boli, samozrejme, v danej oblasti aj bugy (a je mozne, ze este stale su), ale v poslednej dobe sa tomu vyvojari celkom dost venovali a celkom vela chyb bolo opravenych.

Dalsim dovodom podobneho spravania je hlupy hw (nie nutne vadny, skutocne hlupy). Velka vacsina diskov a raid poli ma vlastnu cache. Problem je, ze niektore disky hlasia data ako zapisane v momente, ked sa data dostanu do cache. Dalej niektore z tych diskov nemaju zalozne napajanie a teda v momente, ked vypadne prud su data, ktore boli v cache, stratene. S tymto sa nedokaze uz vysporiadat uplne ziadny fs (pozadovat, aby fs pracoval s tym, ze mu disk klame je absurdne).

[little.owl]

UPS, UPS, UPS ....

ext3 spolu s ext4 hadzu podobne null subory do lost+found, takze ich nie je vidno a uzivatel si tak casto ani nevsimne, ze o nejake data prisiel (co je uprimne snad este horsie).

To tedy je ...

[little.owl]

...a nehrozí u něj ten problém, jako u XFS, kde když je rozepsaný soubor a vypne se počítač, tak se přepíše nulama.

Velmi zjednodusene a zle interpretovane.

Nejaka poznamka je k tomu asi zde .... ?

[jas]

jj, v starych jadrach to byvalo viditelnejsie (a odtial si to asi aj vacsina ludi pamata).

[David Jaša]

Dalej niektore z tych diskov nemaju zalozne napajanie

Tohle v době superkondenzátorů a drahých disků fakt nechápu.

[jas]

Ani ja moc, ale zevraj to robia aj niektore drahsie diskove polia (alternativne moze dany zalozny zdroj prist casom o svoju kapacitu...). Zmysel by to davalo jedine ak sa tam apriori predpoklada UPS a potom dany zalozny zdroj energie len zbytocne navysuje cenu, akokolvek nejde o nejak vyraznu polozku.

[lertimir]

Já hlavně nechápu, proč se nevyrábí zdroje, které by měly nějakou velmi malou výdrž, ať již na kondezátorech nebo malé baterii. Stačilo by tak cca 10-20 vteřin, vydrželo by to bliknutí sítě, a pokud by byl výpadek, tak by čas stačil na zápis do disků. Nebyl byl potřeba měnič jako u UPS, protože by to dodávalo už stejnosměrný proud, a pokud by takový zdroj stál o 500-700 víc bez váhání za něj bych to dal.

[Šangala]

To by ale museli být „speciální“ zdroje asi označené třeba „servevrové bez grafiky ma 250W“.
Udržet přesné specifikace napětí, na každé větvi by muselo být řešené baterií na každá větvi + další stabilizační prvky.
Já bych raději chtěl zdroj do PC na 12V stejnosměrné, ale samozřejmě bez měniče :).

[little.owl]

Je to tak. Pred rokem jsme neco podobneho resili. Ridici jednotka musela byt pri vypnuti napajeni schopna se rozumne ukoncit, to znamenalo v nasem pripade ulozit nektera data do EEPROM. V praxi to znamenalo udrzet jednotku spolehlive v chodu, s rezervou, jeste cca 500ms. Museli jsme prekopat cele napajeni - tri napajeci napeti procesoru a periferii, nachylnost k latch-up; naklady na napajeci zdroj sly hodne nahoru.

To by ale museli být „speciální“ zdroje asi označené třeba „servevrové bez grafiky ma 250W“.

U PC by to v praxi znamenalo mit dualni zdroj, v podstate integrovanou malou UPS; troufam si trvdit, ze v pro vetsinu lidi by bylo reseni standardni PSU + UPS lepsi a levnejsi cesta.

[David Jaša]

U PC by to v praxi znamenalo mit dualni zdroj, v podstate integrovanou malou UPS; troufam si trvdit, ze v pro vetsinu lidi by bylo reseni standardni PSU + UPS lepsi a levnejsi cesta.

Jak moc velký problém by bylo mít baterii superkondenzátorů na stejnosměrné části zdroje? Přijde mi, že velmi krátké výpadky napětí (probliknutí světel, restart tiskáren, ...) zdroje zvládají pokrýt už roky, tak by snad nemusel být probém to o pár sekud protáhnout.

[little.owl]

o pár sekud protáhnout.

Par sekund muze byt docela dost energie. Kondenzatory s velkou kapacitou a malym svodem [a treba i velkym Q-faktorem] nejsou levna zalezitost, i kdyz by to slo.
U standardniho designu PC spinaneho zdroje neni za normalnich provoznich podminek pouziti extremne velkych kapacit nutne, ostatne spis ani zadouci, snad s vyjimkou vyhlazovaciho kondenzatoru za vstupnim usmernovacem, jehoz velka kapacita ale komplikuje zapinani a design vstupni sekce, ktery uz ted neni jednoduchy diky [aktivnimu] PFC. Integrovani zalozniho zdroje energie je pak velky zasah, a kdyz uz se dela, tak bych uvital delsi chod nez par sekund. V desktopu neni jen jeden spinany zdroj, ale nekolik nezavislych zdroju, ktere se chovaji jako zatez hlavniho spinaneho zdroje a v dobe zakolisani napeti, padu ci vypnuti jsou jejich zatezove prechodove charakteristiky nevypocitatelne, coz opet nepomaha. Dimenzovat se to musi pro nejhorsi pripad, na sekundy bych garantovany chod merit nechtel.

[omg]

tim, ze by to bylo ve zdroji, tak to ma primou linku na zakladni desku a muze to nastavit linku, ktera vyvola NMI nebo SMI a cely system pujde do sekundy do suspendu.

[lertimir]

To jistě chápu, že ten zdroj by musel být jiný, ale to, co popisujete je vývoj zařízení, samozřejmě počáteční vývoj je vždy drahý. V provozu pak o nákladech mnohem více rozhoduje seriovost (a kvalita komponent) než přímo komplikovanost řešení. Co by bylo neprůchozí na řešení blízké tomu, jak jsou napájeny notebooky?

[Václav HFechs Švirga]

Ok, díky za upřesnění. Samozřejmě jsem myslel násilné vypnutí.

[Michal Kubeček]

Hlavní důvod, proč jsem ho vůbec zkusil, bylo to, že u většího XFS (stovky GB a víc) na strojích s více CPU (2-4) tehdy trvalo flushnutí writeback cache (např. příkazem sync) neuvěřitelně dlouho (podle toho, co ukazovalo /proc/meminfo, to vycházelo na něco jako 3 MB/s). Výsledkem bylo, že např. po vypnutí virtuálu pod VMware Workstation následovala minutová prodleva, během které byl systém víceméně nepoužitelný. Do ReiserFS se mi moc nechtělo, ext3 se na velké filesystémy a soubory moc nehodí a ext4 tehdy ještě nebyl (nebo jen experimentální), tak jsem zkusil JFS a protože jsem s ním žádné vážnější problémy nezaznamenal, používám ho pro větší filesystémy dodnes.

[little.owl]

Diky, to je v podsate jediny velky FS, ktery jsem jeste nepouzival.

[David Jaša]

Průser je po nekorektním ukončení OS - rozesynchronizují se dvě kopie čehosi (superblok?) a s trochou štěstí, cviku a gůglení se to dá dát dohromady. Ale dělejte to někde na cestách.

Osobně jsem skončil u kombinace ext4 na "normální" používání a xfs pro počítače s UPS.

[Michal Kubeček]

Jen pro pořádek: nekorektních ukončení systémů s JFS jsem už zažil spoustu a to, co popisujete, se mi nikdy nestalo. Takže to rozhodně nelze brát tak, jako že by to byl běžný výsledek.

[David Jaša]

Pro mě to běžný výsledek byl. Dotyčné disky mi dál dobře sloužily i poté, co dotyčný systém šel z notebooku pryč, takže hw za to nemohl.

Jak tak vzpomínám, tak mi JFS přišel v nějaké běžné situaci pomalý, ale už si nepamatuju, co to bylo - používal jsem JFS ve zhruba stejné době, kdy jste s ním začínal vy (odhadem 2007-2009) a už je to holt dávno.

Ve výsledku jsem přešel na ext4 u naprosté většiny systémů, co jsem instaloval od té doby, a je to nejmíň problémový FS po všech stránkách.

[Michal Kubeček]

Jak tak vzpomínám, tak mi JFS přišel v nějaké běžné situaci pomalý

Občas mi přišlo, že trvá nezvykle dlouho smazání rozsáhlé adresářové struktury (zrojáky jádra, Firefoxu apod.). Ale ne vždy a všude.

[David Jaša]

Ano, pravda, mazání to bylo.

[Lukas]

Xfs rozhodne neni "jednoduchy", a to ani zdaleka. Rozhodne neni jednodussi nez napriklad ext4.

Nenarocny ? Nenarocny na co ? Vzdycky zalezi na workloadu.

Nerezervujici si prostor ? Co je tohle za blbost, vzhledem k tomu ze kazdy fs si "rezervuje prostor" tak je tezko rict to je tim mysleno. Ano xfs nema staticke rozlozeni metadat/dat na disku (az na superbloky napriklad) jako ma napriklad ext4, jenze xfs v tomhle rozhodne neni sam. Z hlediska zajisteni spolehlivosti se to pak da povazovat i za nevyhodu.

[iwk]

Tu su slajdy http://www.h-online.com/open/slideshow/bilderstrecke_1631968.html?back=1631791;back_page=1;image=1

[Leinad]

To jsou rok starý slide a z dnešního pohledu nejsou už 100% pravdivé

[iwk]

A cim si prispel ty, Madar chory?

[pavlix]

LOL, to mi nedělej takhle při pátku.

[xxxs]

mne sa zdalo, ze prispel informaciou o ich aktualnosti.

[jc]

To XFS taky nechapu. Jestli za tim neni lobbing ze strany vyvojaru fsck.xfs

[j AM]

Dobrá zpráva!