Red Hat Enterprise Linux 7.4

Společnost Red Hat oznámila vydání Red Hat Enterprise Linuxu 7.4, který přináší vedle nových vlastností a oprav chyb také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.

1.8.2017 22:00 | Ladislav Hagara | Nová verze

Komentáře

[AsciiWolf]

"Btrfs has been deprecated"

[Ladislav Hagara]

Odkaz do poznámek k vydání.
Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.

[Franta Hanzlík]

A openldap (jenom server?) si budou muset RHEL useri taky prekladat sami.

[Duroň]

WTF?! Čím to jako chtějí nahradit? XFS nad LVM? To jim ten Oracle tak leží v žaludku?

[Conscript89]

Nahradit? Btrfs bylo pokud vim stale jen development preview nebo experimental (ted nevim co z toho, ale urcite to nebylo tak, ze by bylo doporucovane do produkcniho nasazeni) a nebylo tak plne podporovane v RHEL-7. Oproti tomu je prave zminene xfs + LVM podporovane a defaultni.

[Pavel]

A s tím xfs a LVM se skutečně dají používat třeba stovky snapshotů? Co jsem četl, tak propad výkonu s každým snapshotem rostl, to platí u LVM stále?

[Conscript89]

Ja jen reagoval na to, ze nejde nahradit neco, co ani nebylo :)

[little.owl]

Zajimave. Jak se zda, btrfs je po letech stale natolik problematicky souborovy system, ze Red Hat dosel k zaveru ze potencialni problemy zakazniku, ktere by musel v ramci jejich podpory resit a pripadny risk spojeny se ztratou dat nevyvazi jeho prakticky prinos ve srovnani xfs/lvm/mdraid.

Otazkou je jestli cela implementace a koncepce jak btrfs, tak ZFS je vhodna pro soucasne a ocekavane budouci ulozne technologie, kdy jsou jiz dostupne rychle terabytove 3D NAND disky, se kterymi v dobe navrhu asi nikdo moc nepocital. Apple a jeho APFS je odpocatku optimalizovany pro flash disky a preferuje produkcni stav pred poctem vlastnosti, coz je lepsi cesta. Nastesti pro Linux se pracuje i na alternativach jako je bcachefs.

[snajpa]

CoW natura obou BTRFS a ZFS je dela rovnou vhodne pro SSD. Staci vyhodit/vyradit/nedelat vsechny ty optimalizace kvuli rotacnimu mediu. V cem je kousek problem je stara implementace, ktera moc nepocitala s tak low latency storage, postupne se ZFS kod prekopava na lock-free mechanismy nebo aspon na skalovatelnejsi zamykani. All-flash storage se ZFS jsou beznou zalezitosti, nevim o tom, ze by bylo nevhodne davat ZFS na terabajtove NAND disky. Ja to ze sveho pohledu aktivniho uzivatele vnimam tak, ze ZFS nema backreference, neumi tim padem realokaci bloku (odkomprimovat zakomprimovana data, offline dedup, zmenseni poolu, odebrani vdevu...), ale je produkcne pouzitelne ve velkem. BTRFS si vzalo za cil ZFS dohnat a samozrejme predehnat, bez jakehokoliv backingu nejakou storage firmou, ktera by to tahala. CoW FS jsou proste prilis komplexni problemy na to, aby to zbastlil nekdo doma na koleni, jako za dob EXTu.

[little.owl]

Staci vyhodit/vyradit/nedelat vsechny ty optimalizace kvuli rotacnimu mediu.
...
V cem je kousek problem je stara implementace, ktera moc nepocitala s tak low latency storage, postupne se ZFS kod prekopava na lock-free mechanismy nebo aspon na skalovatelnejsi zamykani.

To jsem mel na mysli, nikoliv CoW. Mohout to byt pomerne zasadni zmeny, zasah do designu a prepis kodu.

Red Hat ma asi svou cestu - Stratis: zde a zde. Z textu:

We should not just copy ZFS. ZFS is now fifteen years old and the storage landscape has changed since its design.

Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved.

9. Implementable in 1-2 years
(a) We’re already behind, waiting another 10 years isn’t an option

[Michal Kubeček]

Zajimave. Jak se zda, btrfs je po letech stale natolik problematicky souborovy system, ze Red Hat dosel k zaveru ze potencialni problemy zakazniku, ktere by musel v ramci jejich podpory resit a pripadny risk spojeny se ztratou dat nevyvazi jeho prakticky prinos ve srovnani xfs/lvm/mdraid.

Ono to až tak úplně takhle není, i když se to jejich markeťáci pochopitelně budou snažit tvrdit nebo aspoň naznačovat, aby zákazníky odradili od SLESu.

Spíš jde o to, že u enterprise distribucí vládne filosofie "one tool per task", kterou sice osobně považuji za velmi nebezpečnou a škodlivou, ale chápu, že z obchodního hlediska smysl dává. O každou možnost volby mezi dvěma řešeními je potřeba tvrdě bojovat. Red Hat se prostě rozhodl preferovat jiné řešení a své zdroje soustředit na něj. To je celé, neznamená to automaticky, že ostatní řešení jsou a priori špatná.

[petr]

Problem s btrfs u redhatu je ten, ze btrfs ma zatim spousty produkcnich omezeni - viz raid5/6 issues a tudiz by pro adminy bylo neprakticke pouzivat pro treba raid 1 btrfs commandy a pro raid 5 neco jineho. Resili jsme tohle ve firme a je to extra work a extra dokumentace a hlavne to neni fail proof (admin v navalu radosti udela raid6 s btrfs a po case jsme v zadely). Co se tyce zfs a ssd, v praxi je pouzitelne bez problemu (nekolik stroju, dohromady asi 300tb pro data v ruznych konfiguracich).

[little.owl]

Ono to až tak úplně takhle není, i když se to jejich markeťáci pochopitelně budou snažit tvrdit nebo aspoň naznačovat, aby zákazníky odradili od SLESu.

Vcera jsem v rychlosti projel btrfs mailing list a podival se do git logu. Muj zaver je, ze je tam stale spousta problemu a zmen v kodu, a skutecne to nebudi dojem ze btfrs je v producknim a stabilizovanem stavu, coz je po deseti letech vyvoje celkem smutne.

Spíš jde o to, že u enterprise distribucí vládne filosofie "one tool per task", kterou sice osobně považuji za velmi nebezpečnou a škodlivou, ale chápu, že z obchodního hlediska smysl dává.

One tool per task je btrfs, ktere integruje vse dohromady. Nemyslim, ze by se Red Hat dlouhodobe zbavoval takoveho reseni, pokud by mel dojem ze to nekam vede, ostatne Fedora se mnohokrat pokusela pouzit btrfs jako defaultni system a vzdy to bylo zastaveno technickymi problemy.

[Michal Kubeček]

Vcera jsem v rychlosti projel btrfs mailing list a podival se do git logu. Muj zaver je, ze je tam stale spousta problemu a zmen v kodu, a skutecne to nebudi dojem ze btfrs je v producknim a stabilizovanem stavu, coz je po deseti letech vyvoje celkem smutne.

Především je potřeba si uvědomit, že btrfs není jeden nedělitelný monolit. Je to živý kód, kde stále přibývají nové featury, a je pochopitelné, že ty nové části jsou v méně zralém stavu než ty starší. To, že ve SLESu je podporovaný btrfs, neznamená automaticky, že jsou podporované všechny jeho featury včetně těch, ze kterých ještě kape barva.

One tool per task je btrfs, ktere integruje vse dohromady.

To není "one tool per task", to je spíš "one tool for all task" - koneckonců je to jeden z důvodů, proč osobně btrfs nijak v lásce nemám. Princip "one tool per task" spočívá v tom, že tam, kde jsou dvě řešení s podobnou funkcionalitu, se jedno vybere a druhé zahodí. Např. sendmail a postfix, syslog-ng a rsyslog apod. V tomto případě je to XFS+LVM+??? vs. btrfs.

Nemyslim, ze by se Red Hat dlouhodobe zbavoval takoveho reseni, pokud by mel dojem ze to nekam vede,

Tady máte třeba komentář Josefa Bacíka, který o tom celkem jistě ví víc než kdokoli z nás.

ostatne Fedora se mnohokrat pokusela pouzit btrfs jako defaultni system a vzdy to bylo zastaveno technickymi problemy

Do vývoje Fedory nevidím. V openSUSE je jako default už pár let a problémy samozřejmě jsou, ale co jsem vypozoroval, většina z nich není primárně způsobena btrfs jako takovým, ale nepříliš šťastným rozhodnutím defaultně všem zapnout snapper a dělat snapshoty, kdykoli by mohly být jen trochu potřeba, jako by snad všichni měli nekonečně velké disky.

Pro pořádek: nejsem žádný fanda btrfs, na svých strojích ho nikde nemám a ani nemám v plánu to v dohledné době změnit. Ale nelíbí se mi ta (bohužel očekávaná) reakce ve stylu "Red Hat od toho dává ruce pryč, to musí být naprostý shit."

[petr]

Redhat ale primarne cili na enterprise a promin, kdyz btrfs ma potize se “zakladnimi” veci typu raid5/6, tak je to z pohledu redhat pro enterprise opravdu naprosty shit.

[Michal Kubeček]

RAID 5/6 implementovaný coby součást filesystému zase až tak základní věc asi nebude, když je btrfs jediný linuxový filesystém, který ji nabízí.

[Petr]

Zfs?

[Michal Kubeček]

ZFS nemůžu při nejlepší vůli považovat za "linuxový filesystém".

[Petr]

Problem je ze kdyz budes delat raid 0/1/5/6/x tak budes chtit v enterprise pouzit ten samy set commandu a ne delat if raid 1 pouzij to, if raid 5 pouzij to,... v tomhle jetreba na zfs znat enerprise mysleni u navrhu.

[Petr]

Jinak skvele cteni je https://btrfs.wiki.kernel.org/index.php/Status kde vidis ze treba device replace gets stuck on devices with bad sectors, nebo jeste lepsi RAID1 Needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present. Nebo Quotas - mostly OK. Btrfs je mozna pouzitelny pro takove ty domaci hratky kde si to porno proste stahnes znovu, ale mit ho nekde na storage ke kteremu pristupuji stovky nebo tisice lidi je nerealne. Jako technologicke preview dobry, ale do produkce bych ho nedal.

[little.owl]

Btrfs je mozna pouzitelny pro takove ty domaci hratky kde si to porno proste stahnes znovu, ale mit ho nekde na storage ke kteremu pristupuji stovky nebo tisice lidi je nerealne. Jako technologicke preview dobry, ale do produkce bych ho nedal.

+1

[Michal Kubeček]

Já ho taky nikde nemám (jak už jsem ostatně psal), ale to je hlavně proto, že jsem usoudil, že by mi to přineslo komplikace navíc, zatímco pro výhody, které bych tím získal, většinou nemám moc využití.

Námět k zamyšlení: ve SLESu je btrfs IIRC podporovaný někdy od SLE11 SP3. To mimo jiné znamená, že se musíme zabývat bugy nahlášenými zákazníky a řešení každého takového bugu znamená pro firmu nemalé náklady. Každý zákazník, který by kvůli btrfs ztratil důvěru ve SLES nebo naše produkty obecně (a ruku na srdce, horší bugy než rozbitý filesystém nebo tiše poškozená data v podstatě neexistují) znamená obrovskou ztrátu peněz. Přesto jsem zatím nezaznamenal, že management docházel k názoru, že sázka na btrfs byla omyl a že na tom proděláváme kalhoty. Nevím jak vám, ale mně z toho vychází, že to asi zase až taková katastrofa nebude. Ne že by bugy nebyly a ano, je jich víc než třeba na ext4 (s XFS bych řekl asi tak srovnatelně, ale to je jen odhad, statistiku si nevedu), ale ten obraz všeobecného zmaru a utrpení, kteří tady někteří malují, to taky není.

[little.owl]

Je to živý kód, kde stále přibývají nové featury, a je pochopitelné, že ty nové části jsou v méně zralém stavu než ty starší.

Ale co vlastne funguje? Zatim vidim spoustu spekulaci a dohadu, a lide ze zoufalstvi tvori tabulky jako zde. Odpoved od Chris Mason neprozradi nic, v podstate v tomtu duchu se opakuje jiz roky.

Tady máte třeba komentář Josefa Bacíka, který o tom celkem jistě ví víc než kdokoli z nás.

To je otazka, on jiz je dlouho mimo Red Hat, ale kontakty asi mit bude. Nicmene nechce se mi verit, ze pokud by Red Hat skutecne mel zajem, nemuze si vychovat vyvojare, v podstate je to otazka penez ochotnych do toho dlouhodobe investovat.

Ale nelíbí se mi ta (bohužel očekávaná) reakce ve stylu "Red Hat od toho dává ruce pryč, to musí být naprostý shit."

Takhle to postavene nebylo. Red Hat spise rika, ze ztratit nadeji, ze v dohledne dobe bude situace lepsi a hleda jine reseni. Kdyz jde o dulezita data, kazdy nastroj je shit dokud neprokaze jinak.

[Jana J.]

Ale co vlastne funguje?

Co zkusit navštívit stránky projektu?

[Petr]

+1 dekuji.

[little.owl]

Pokud bych tomu veril, pak mozna. V okamziku kdy i po letech jsou videt bugy jako hned prvni nalezeny ze vcerejska zde, kdy pri pokusu o opravu po hard reset systemu konci na OpenSUSE s core dumpem, beru jakekoliv OK s velkou rezervou.

A tohle opravdu pomuze :

Send OK corner cases may still exist

[Jana J.]

Pokud bych tomu veril

Aha, čili předtím šlo o řečnickou otázku (protože lepší informace asi nedostanete a pokud byste je i dostal, věřit jim asi nebudete úplně stejně). Potom tedy pardon...

[little.owl]

Aha, čili předtím šlo o řečnickou otázku

Ne.

protože lepší informace asi nedostanete a pokud byste je i dostal, věřit jim asi nebudete úplně stejně

Nikoliv, jen po letech uz nemam velkou duveru v btrfs team, jejich tvrzeni o stavu projektu a v jejich schopnost problemy v dohledne dobe vyresit.

[snajpa]

Nicmene nechce se mi verit, ze pokud by Red Hat skutecne mel zajem,

A tohle Red Hat neumi. Cokoliv novyho, co chce delat, musi nakoupit z venku, interni projekty psany od nuly vevnitr jsou vetsinou naprosty fial. Red Hatu failuje jeho management struktura, nezvladnou pracovat s makacema a zustavaj jim akorat lopaty, ktery jsou ale bez napadu. Aspon soude podle toho, co se tu deje v Brne dlouhodobe .

[kolcon]

OK, no a cim teda nahradit:

• subvolumy a jejich mountovani pres subvol=
• on-the-fly kompresi
• pohodlne zalohovani pres snapshoty a rozdilovy btrfs send?