Red Hat končí s Btrfs, zřejmě nadobro

Jejich volba ale uvítal bych technické zdůvodnění proč. Btrfs používají i velké komerční projekty ( namátkou Synology ) a pokud je zde nějaký důvod k pochybnostem bylo by dobré ho znát.

Hlavní důvod je, že RH udržuje jednu verzi jádra po celou dobu supportu a Btrfs má tak rozsáhlé patche, že opravy nezvládají backportovat.

Mne by zajimalo, jaktoze na webu btrfs pisou ze RAID5/6 is fucked do not use it a v Synology je ted defaultne btrfs a RAID5/6 si klidne muzes udelat.

Od čínských soudruhů, kteří opatchovali ext3 tak, aby byl case insensitive, protože si nepřečetli manuál k Sambě, bych nějaké hlubší úvahy v tomto směru neočekával.

No jo, ale v té době ještě funkcionální programování tolik neletělo.

Jasne NetApp ;-))) ... ZFS v jadre je i jako moduly, problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data a stacilo by to opravit, ale NEJDE ... a ro jak na freeBSD tak na solarisu ... kdyz jsem Oracle psal v diskuzi, ze nemit fsck.zfs je hloupost a kazdy FS se muze pokazit, tak to smazali

Dale ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool, tedy pro me na nic, ja kupuji disky a prodavam je do sw_raidu 5 ... rekli, ze zadne profi reseni tuhle vlastnost nema, tak jsem jim rekl ze ji ma NetApp a ten umi rozsirit RaidGrupu o disk a pak si clovek muze pustit restripe dat, aby byly vytizeny vsechny disky rovnomerne, to mi taky smazali ... nebot jak vsichni vime, neni lepsi reseni nez NetApp, hledali jsme 2 roky a nic nefungovalo tak dobre.

PS: Netapp je NAS,RAID pole, bezi nad FreeBSD, coz je tajeno, ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano) a umi mnoho protokolu a nad tim vsim umi delat lokalni snapshoty a prenaset je ne jiny netapp ... bezi na tom mnoho SAP reseni, nebo SQL (DB2/Oracle) a misto FC voli NFS, je to flexibilnejsi a rychlost je stejna, jen je treba zmenit NFS blok, na mnoho nahodnych operaci je lepsi jej mit mensi, dramaticky pak roste rychlost pro mnoho pristupu a klesa latence

ZFS má problémy třeba u disků, které špatně implementují flush cache (potvrdí jej před zápisem). Výpadek proudu pak dokáže ZFS odrovnat. Přitom by to šlo vyřešit snadno, stačilo by odrolovat několik posledních transakcí do konzistentního stavu, ZFS všechna potřebná data má. Což by byla práce právě pro nějakou fsck-like utilitu spuštěnou po startu.

Předpokládám, že ten problém je, že nemůžete přidat další disk do vdevu, ne že nemůžete do poolu přidat další vdev. Třeba nejde mít 6diskový RAID-6 vdev a přidáním dvou disků z něj udělat 8diskový RAID-6 vdev. Btrfs i mdadm tohle umí.

ZFS tohle samozrejme umi, kdyz ho slusne pozadas (zpool import -F|-m|-n).

Jestli tvuj pozadavek je FS ktery 100% funguje i kdyz hardware vyslovene lze (ignoruje cache flush, ignoruje zapisy, cte data z nahodnych mist, pise data na nahodna mista atd) tak chci videt co pouzivas. Moderni FS se snazi takovou situaci detekovat, aby si vedel kdy sahnout do zaloh.

Problem pridavani disku do existujiciho vdev je non-issue v ZFS target audience (enterprise). Problem je bohuzel hluboko ve vlastnostech on-disk formatu (a pozadavcich na stabilitu zapsanych dat/COW).
Nevim jak tohle btrfs dela, ale tipnul bych ze tam bude nejaky hacek (jako kdyz defragmentace rusi block-sharing snapshotu).

kdyz uz o tom mluvis, zkousel si na btrfs RAID5/6 rebuild/resilver? IIUC je to porad cele rozsypane a nahodne ztraci data.

"problem ZFS je ten, ze nema opravne nastroje"
To není pravda, ZFS má tzv. scrub, který kontroluje a případně opravuje data na zpoolu. Navíc ZFS automaticky opravuje chyby, které zjistí při běžném IO.

"nemit fsck.zfs je hloupost"
Tohle je asi věc názoru - mě naopak přijde jako hloupost chtít mít nástroj jako fsck, který funguje jen na neaktivním (odmountovaném) soborovém systému a čekat hodiny nebo i dny než doběhne. Takže jsem rád za scrub, který běží na pozadí.

"kazdy FS se muze pokazit"
100% souhlas, tesat do kamene.

"tak to smazali"
zkoušel jste založit Bug nebo request?

"ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool"
Tohle není pravda, disky se do poolu samozřejmě přidávat dají. Je ale pravda, že v ZFS nelze přidávat disky do existujícího RAID-Z vdevu.

"bezi nad FreeBSD, coz je tajeno"
Jen pro zajímavost, kdo a jak to tají? Tohohle si přece musel všimnout každý, kdo někdy viděl NetApp alespoň bootovat. Navíc FreeBSD se pro podobné účely používá dost často (viz např. Isilon), takže se snad není za co stydět?

"ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano)"
Kdo a jak to dokazal? Pokud máte na mysli ten spor NetApp vs Sun, tak pokud si správně vzpomínám, NetApp chtěl (1) zabránit tomu, aby Sun nabízel storage řešení založená na ZFS (pracovní stanice a general purpose servery byly ok) a (2) aby Sun nezveřejňoval zdrojáky ZFS a (3) nepodporoval další šíření ZFS. Spor byl urovnán a přesné pozadí asi nikdo z nás nezná, ale vzhledem k tomu, že Sun vzápětí zveřejnil zdrojáky ZFS, aktivně podporoval ZFS implementaci v Mac OS X a FreeBSD a začal prodávat storage boxy založené na ZFS (Sun Storage 7000), nedá se podle mě mluvit o nějakém drtivém vítězství NetAppu. Spíš bych to viděl na klasický patentový trolling.

http://bcachefs.org

Přesně na to jsem si také vzpomněl. Hlavně mě překvapilo, jak rychle se bcachefs dostalo do stabilního stavu ve srovnání se ZFS nebo Btrfs.

Po zkušenostech s bcache od stejného autora, která od verze jádra 3.14 trpěla (snad dodnes nevyřešenou) regresí způsobující zvýšený load a s neopatchovaným jádrem ve writeback režimu občas deadlocky, nemám k čemukoli, co má v názvu "bcache", moc důvěry...

Volume management BTRFS, že je výkonově horší než XFS+LVM? I u stovek snapshotů? Máš k tomu nějaká tvrdá data?

Btrfs se zaměřuje na aktuální problémy Linuxu. Jedním z nich je systemd, ten pod Solarisem není. Přečtěte si
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html a pochopíte.

U běžné konfigurace (např. samostatná pracovní stanice) systemd funguje, protože ta konfigurace je otestovaná. Když ale používáte konfigurace méně běžné (třeba NFS, LDAP), tak se může stát, že po změně konfigurace a rebootu se systemd zakousne a do systému se nedá dostat. Ani přes konzoli, ani přes síť ... Pak můžete trávit desítky minut odstraňováním problému v rescue módu, a nebo (když máte snapshoty), prostě jen nabootujete systém před provedením změny. Problém pak zkoumáte na jiném (ne produkčním) stroji.

Nicméně souhlasím s tím, že snapshoty žerou hodně místa. Výše zmiňovaná dokumentace uvádí, že btrfs je nastaveno jako default pro partitions se 16 GB. Já mám 32 GB a je to málo. Na "běžný" provoz to stačí, ale upgrade se na tom bez ručního mazání snapshotů dělat nedá. Na větším serveru jsem radši vyhradil 100 GB.

Pro uživatelská data openSUSE doporučuje XFS. Tady Btrfs žádné významné výhody nemá.

Má zkušenost je, že používání systemd bez btrfs je čistý masochismus. Několikrát se mi stalo, že po updatu nebo rekonfiguraci se systemd někde zasekl a OS nenabootoval. V tom případě stačilo nabootovat ze staršího snapshotu. (V openSUSE je naštěstí vytváření snapshotů automatizované.) Představa, že bych měl používat systemd bez snapshotů mě děsí.

Jak bych to ve zkratce... No asi takhle: s tou Javou 9, resp. konkrétně JPMS, to bylo úplně jinak, než si pravděpodobně myslíš, ale coby zaměstnanec Red Hatu to radši nebudu víc komentovat.

Udělal, viz např. archivy jpms-spec-experts a jigsaw-dev.

Reakce byvaleho Redhatiho vyvojare pro sirsi kontext:
https://news.ycombinator.com/item?id=14907771

No ja jej pouzival a zase zahodil, bezel bezel a ackoliv mel stovky MB volnych na svoje metadata a mel jeste 6TB volneho mista, takze mohl expandovat, tak prestal fungovat a jel rychlosti diskety a to i cteni, nikde nebylo napsano, jak to zvetsit, jen ze by to mela opravit reorganizace dat, tak jsme to pustil a prd. ... az jsem zjistil nedokumentovany parametr pri mountu, ktery mi poslal vyvojar, no mel jsem tam asi hodne souboru, ale nic extra, evidentne ovsem vice, nez do te doby kdo testoval.

Od te doby utekly min 4 roky a BTRFS bude asi jinde, ale nedivim se RH ze jej zahodil, kolikrat jeste zmeni strukturu dat ? ... kazdy jej tam bude moct pouzivat na svoji pest a treba az bude oznacen za stable, zase se do RH vrati.

RH je profi reseni a ma nahradu, rika se ji NetApp ... je to sice externi, ale zato velmi spolehlive a podporovane uplne vsemi.

Před 4 lety bylo Btrfs hodně jiné, a taky bylo dost jasně označené jako experimental. Formát dat je stabilní od roku 2014, strukturu dat od té doby nezměnilo ani jednou. V jádře je (s výjimkou RAID56) jako stabilní od roku 2015.

Mám pár let starou velmi podobou zkušenost. Zrovna by se mi ale fakt hodně hodily snapshoty, tak jsem si říkal, že zkusím jeden testovací disk na btrfs převést. Posledních pár řádku vypadá takhle:

btrfs-convert(btrfs_se­arch_slot+0x2d­7)[0x4140d7]
btrfs-convert(btrfs_csum­_file_block+0x4b7)[0x4­26537]
btrfs-convert[0x40bed4]
btrfs-convert(main+0x1764)[0­x40ae14]
/lib64/libc.so­.6(__libc_star­t_main+0xf0)[0x7­f0817cad640]
btrfs-convert(_star­t+0x29)[0x40bab9]
Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen])

Já si nepamatuji, že by mi za posledních 15 let takhle zhavarovala nějaká utilita pro práci s ext*, XFS, Reiser, ... . Asi se RH ani moc nedivím.

Ona nějaká utilita pro ext*, XFS nebo Reiser umí převádět z jiného souborového systému? btrfs-convert je pořád experimentální, mimo jiné si třeba neporadí s tím, pokud ten FS není v konzistentním stavu, proto doporučují před konverzí spustit fsck -f.

Btrfs je defaultní souborový systém pro partition s operačním systémem ve SLESu 12 a současném openSUSE. To samozřejmě nedokazuje, že je to stabilní souborový systém. Ale ostré nasazení na spoustě počítačů indikuje, že vlastnosti, které se tam používají, dostatečně stabilní jsou. Všechny vlastnosti btrfs stabilní ještě nejsou, víc info je na https://btrfs.wiki.kernel.org/index.php/Status .

Fajn a na čem teda nadále provozovat docker? Asi momentálně teda ne na RH systémech...

to ze by ho vyzadoval netvrdim...

Protoze docker provozuju na btrfs a mam to ozkousene ze me to vyhovuje a ze to funguje jak ma, proto... Na notesu me bezi docker na ext4, ale ne uz tak bezproblemove, mozna mam jen smulu, ale na btrfs sem nemel sebemensi problem, tak proc to rozbijet?... O to me jde.

Tu hype sračku je nejlépe neprovozovat vůbec na ničem. :-P

Hello.
Okolo dockera je (alebo bol) celkom hype. Pametam sa ked som sa o tom chcel nieco dozvediet, tak som natrafil na kopec "tutorialov" kde sa hypsta manici vytesovali ake je to uber a kool a jedine co s tym dokazali predviest bolo ze si stiahli image z dockerhubu a spustili ho. Ale ako sracka mi to nepripada. Prevadzkujem to zatial experimentalne a celkom vyhovuje. Ma to pod kapotou zhruba to co som od toho vyzadoval teda vytvorenie image, nejaky ten deployment, kontejnery samozrejme a nejaky ten dohlad. Zatial ale neriesim ziaden failover, swarm ani ziadnu velku orchestraciu. Ale mam v merku aj LXC a runc. Takze kde skoncim este uvidim. :-)

je to takova sracka ze na to prechazej v dnesni dobe prakticky vsichni. To ze nechapes prinos kontejneru je tva blbost. Netvrdim ze docker je alfa omega, ale nastartoval tenhle trend, spojil technologie ktere tu jiz byly davno pred nim a spojil je do celkem pekneho celku.

souhlas s Ondrejem, docker kritizují lidé, kteří ho prostě nepoužívají, stejně tak tutoriály píší lidé, kteří nemají dostatečné znalosti a veřejné containery jsou sra*ky.

Docker spojil co tady bylo do fungujícího celku, v současnosti na něj přechází hodně firem kvůli úspoře nákladů, osobně provozuji clustery o celkově tisících serverech s dockereme či jinými containery. V čechách na tom běží celý seznam, celá řada levných hostingů, ani o tom nevíte.

Presne tak.
Jedinej problem je presne ve spatnejch tutorialech a ve spatnejch verejnejch kontejnerech. Osobne pouzivam prakticky jen ty od _, cili ofiko kontejnery, ty od lidi jsou vetsinou naboptnale srajdy, cest vyjimkam, co maj nesmyslne XX vrstev a v zakladu nejlepe ubuntu, nebo centos.

Docker mi nic ine nepripomina ako FreeBSD jaily, ktore maju tak uz 20 rokov.
Jedine pozitivum dockera vidim v dokumentacii.

Samozřejmě že připomíná. Několik lidí tady výrazně napsalo, že Docker "spojil dohromady věci které ti již byly dávno předtím"

A zase tie flame wars na ZFS, btrfs, dokonca WAFL od NetAppu, ktorý stojí raketu a je ešte viac proprietary ako bývalo ZFS alebo je v podaní Oracle. Ale o to nejde.
Určite nikomu nemohlo uniknúť, že RH prešiel u RHEL7 z ext4 na XFS. Možno blbé rozhodnutie, možno nie. Ale XFS je veterán z roku 1994, a kto sleduje aspoň phoronix.com alebo nebodaj kernel patche, tak si určite všimol, že XFS pomaly naberá kód, ktorý zabezpečí COW, snapshoty, post-write deduplikáciu, checksumy (metadata už checksummed sú), atd. Vôbec by som sa nečudoval, ak RH spolupracuje s SGI na vývoji a obohatení XFS do formy, ktorá bude konkurovať ZFS či Btrfs. A áno, XFS nie je a asi nebude mať volume management ako btrfs alebo ZFS, ale načo znova vymýšľať koleso, keď tu máme LVM2? Integrovaný RAID má už dávno, a XFS dokonca detekuje parametre LVM2 RAID a nastaví sa podľa neho pre lepší beh, a to už dávno. Držme si palce, pomaly ale rock-solid.

Nepouzivaqne misto FS oznamuje posilanim prikazu TRIM do LVM.

Už jenom to, jak se RH zapletl s MS, stačilo. Blbý. Co ?

linux os na železe je parodie...

rhel se snaží udělat další widle, takže zaobírat se tím jaký fs bude podporován nebo ne, je nesmysl, protože ani widle ani linux na železo nepatří.

kdo nemá peníze nasadí wmvare, kdo peníze má a jde mu o 24/7 provoz a to doslova, nasadí aix a powervm, no a kdo ví co dělá a má k dispozici rozpočet nasadím zOS/vm a openstack :)

takže ať si pytlíkují třeba super-open-skoro-zsf, ale ve virtuálu a neserou se na hw, tam na to prostě namají, stejně jako MS !

provoz 24/7 lze zajistit i na padajících systémech typu linux, v praxi to můžeš vidět u některých našich operátorů. To nemyslím jako ironii, volnost ve výběru HW a vendorů je obrovský tahoun, stejně tak dostupné lidské zdroje.

Na aix u nás (v EU) není dostatek lidí pro support, i IBM není ochotná prodat hodně mašin.

aix využívá toho, že běží jen na svým HW a nemusí podporovat kdejakou plechovku.

to ano, komoditní hw, je dnes buzz word a všichni se snaží ušetřit, jenže to pak stejně končí kombinací hp, dell + centos, takže rhel z toho nemá nic, vyjma základny beta testerů a nasranejch adminů u koncáku, kteří nevědí co s tím,,

rhel jako hypervizor nemá ani na vmware natož pak na technologie od ibm, které jsou na úplně jiné planetě.

takže jestli pojedou na btrfs, nebo xfs je úplně jedno protože jejich os je tak jako widle jen app launcher at nemá na železe co dělat.

co se týče aixu, francie je blízko a brněnský ibm nabíra jako divej a risc cpu + vlastní architektura je obrovská výhoda tak jako u mac os x na desktopech

rhel měl šanci udržet a přebrat pozici tradičních unixů, ale sázkou na systemd a další, tyto pozice v enterprise vyklidil...

dnešní trh, jsou proprietární hypervizory a objektová úložiště na komoditním hw u vendorů typu amazon a google a proprietárním hw typu zOS+openstack a isilon na freebsd u koncáků....zbytek zdechne a nebo bude přežívat ve vm jako app launcher...

jistě, poslední slovo nemám já jako architect, ale stake-holder/s a ten se, to Vás mohu ujistit, neřídí komunitním nadšením pro systemd, btrfs atd, tj. prostředky investuje z rozmyslem :)

Ono vlastně ani není divu, za poslední dvě dekády, linux totálně prošutroval desktop, a tak jak měl našlapnuto okolo roku 2007 na serverech, také nedokázal zužitkovat....

5 let btrfs, desktop, nula problémů, tento FS dnes nemá obdoby, naopak data zachránil několikrát, navíc je neuvěřitelně user-friendly oproti šílené monstróznosti ZFS. Budu používat dál bez ohledu, zda ho RH podporuje nebo ne, nechápu ten buzz.