Jaký preferujete filesystém v roce 2017

24.8.2017 23:10 | Linux - IT | poslední úprava: 24.8.2017 23:10

Pod dojmem zprávičky o nepodpoře btrfs si dovoluji sondovat ... jaký filesystem preferujete v roce 2017 na notebooku, stolním počítači a serveru ...
Doslova tam je ...

Btrfs has been deprecated
The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. 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.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.        

Anketa

Anketa

Anketa

Komentáře

[Jendа]

Defaultně ext4 a pokud opravdu nutně potřebuju snapshoty, tak btrfs (s vědomím toho, že můžu o data kdykoli přijít).

[pavlix]

Zrovna jsem přešel na btrfs experimentálně na openSUSE Tumbleweed a nejspíš skončím na openSUSE Leap rovněž s btrfs.

[little.owl]

Ty jsi utekl od Fedory?

[pavlix]

Chtěl jsi říct od Gentoo, ne?

[little.owl]

Tak o tom jsem si vubec nedovolil uvazovat. openSUSE Leap take pouzivam.

[little.owl]

Chyby mi tam FS pro externi [usb] medium. Postupne jsem presel z ext4/jfs na xfs, i kdyz jsem s ext4/jfs nikdy nemel zadne problemy. Specializovanejsi veci pres lvm/dm-integrity/dm-verity/dm-crypt. S btrfs po zatim spise mizernych zkusenostech jen experimentuji, stejne jako s bcachefs.

[lertimir]

A zkoušel jsi bcache (čistě jako cache), Nechal jsem si na SSD kus místa na bcache, ale zatím jsem se do ní neodhodlal, tvurce doporučuje aby bcache se vytvářelo přímo na fyzickém blokovém zařízení a to ted nemám. (ale mám M.2 slot takže uvažuji, že bych přes něj odcachoval nekolik xTB disků.

[little.owl]

Pouzival jsem bcache v kombinaci 64GB SSD + pomaly 2TB rotacni HDD, a prinos hodne zalezel na typu zateze. Nemel jsem v zasade zadny problem a ve vetsine desktopovych scenaru vcetne kompilace byl vliv viditelny.

[Jan Zapletal]

btrfs kvůli jedné věci - kontrolní součty dat i metadat.

Líbí se mi i jeho další vlastnosti, jako subvolumes, snapshoty, integrovaný raid, ale zjistil jsem, že tyto vlastnosti ve skutečnosti nepoužívám.

Kdyby do ext4 (nebo klidně někam do nějaké obecnější vrstvy) přidali kontrolní součty dat, vrátil bych se k ext4.

[Jendа]

Chtěl bych se zeptat, kolik silent data corruption už ti to odhalilo (ideálně teda na počítači s ECC). Mně i několika dalším lidem z místních diskuzí zatím 0.

[trekker.dk]

Máme malý (33 disků) ceph cluster na zálohu záloh (off-site.) Párkrát už data corruption kvůli nesouhlasícím kopiím mirrorovaných dat zjistil, ovšem vždycky to bylo kvůli nečitelnému sektoru na jednom z disků, takže úplně silent to nebylo

[Petr]

Btrfs nepouzivam, ale mohu ti dat statistiku za posledni 4 roky u zfs ze svych domacich storage (ruzne lokality, celkove necely 1PB dat). Na vsech strojich mam ecc a pouzivam sas disky, tudiz ty systemy osobne povazuji za min nachylne k silent data corruption. Presto se objevili historicky 3 na jednom nodu a 1 na dalsim nodu.

[pc2005]

SD řadič na mým mobilu mi dělá data corruption. Ale to je tak extrémní případ, že bych to nepočítal .

[Jendа]

btw. dm-integrity, ale předpokládám, že to bude pomalé.

[Nicky726]

Jsem na tom podobně, akorát používám i snapshoty (zjednodušují zálohování – snapper), subvolumes (už jsem narazil na to, že velikosti partic, o kterých jsem si před lety myslel, že budou stačit, nestačily, nebo naopak zbytečně přebývaly, a musel jsem s tím šachovat) a integrovaný raid (data mám krom notebooku na btrfs-raid1, na domácím servříku nyní nově ze tří disků s různými velikostmi, kde je BTRFS afaik mnohem flexibilnější, než klasický raid).

Ext4 mi přežívá už jen na dvou nejstarších strojích, na jednom jen systém, na druhém i data. A v práci, kde jsou uleželejší distribuce.

[Kandidat vied]

jfs server aj desktop

[Petr Tomášek]

Anketa je manipulativní, předpokládá, že člověk preferuje jedno jediné řešení (a ne třeba více různých FS podle použití). Nechápu, proč v anketě nejsou checkboxy...

Minimálně tam měla stát otáזka, jaký FS člověk preferuje pro systém a jaký pro data.

[Petr]

To bychom mohli zajit i dal, co treba fs pro db, fs pro textove dokumenty, fs pro multimedia atd.

[Petr Tomášek]

Ano, pochopitelně to, že jsou různé fs různě výkonné pro malé/velké soubory, je fakt.

[vencour]

Jo pravda. Anketa je k tématu "jeden filesystém zlobí", proto se ptám pouze na ten jeden, komu/čemu důvěřujete a na co spoléháte, na to, co dělá den světlejší.
Systém nainstaluju a když tak obnovím. O data přijít nechci a proto mne zajímají víc. Dává to smysl?

[Petr Tomášek]

Ne, nedává.

100% nedůvěřuju žádnému FS, pro praktické použití (žádné kritické aplikace) mi ext2/3/4, btrfs i třeba zfs přijde dostatečně stabilní. Rád zkouším různé věci a nerad se upínám na jedno jediné řešení.

Z tohodle pohledu mi ta anketa přijde naprosto na hlavu...

[vencour]

Anketa byla kvůli tomu, zda je btrfs bazmek nebo ne, zda mu aspoń někdo důvěřuje. Proto byly radiobutony.
Tj. cca 1/5 lidí mu důvěřuje víc či jej preferuje. To mi stačí.
Stejně tak mi přijde reiser4 na serveru jako joke asi ... jeden hlas tam je

[Petr]

Na desktopech i noteboocich pouzivam apfs, na storage serverech pouzivam zfs (freebsd), na webovych serverech ext4.

[R]

Mame este niekolko serverov a kopu stanic s ext3. Za 10 rokov prevadzky nebol na serveroch nikdy ziadny problem. Na staniciach sa vyskytol jeden typ problemu (asi 20-krat, stanic su stovky): multiply-claimed blocks. Vacsinou medzi nejakym log suborom a niecim dalsim. Asi nejaky bug v starom kerneli.

Na nove instalacie davam ext4.

[knizmi]

Na mobilu a Raspberry mam F2FS. Celkem me prekvapuje, ze ho tu jeste nikdo nezminil.

Na notebooku mam zatim ext4, ale budoucna taky uvazuju o F2FS.

[alium]

na ntb používám f2fs druhým rokem, nikdy nebyl problém...

[kralyk z abclinuxu]

Na telefonu jsem měl f2fs a jednoho dne se z neznámého důvodu ten fs úplně rozpadl.

[Heron]

Ta anketa je bohužel trochu omezující, protože dovoluje pouze jeden FS na jedno dotazované prostředí.

Na jednom serveru mám BTRFS, XFS, EXT4, na druhém serveru (FreeBSD) mám UFS, ZFS, a na dalším potom jen BTRFS. Na stolním PC mám XFS, BTRFS, NTFS, EXT3.

Ad otázka na preferenci na linuxu: Opět záleží na použití daného FS. Kde budu využívat COW, tak tam by default BTRFS. Kde nebudu chtít COW, tak XFS. Další FS jsou potom na zálohovacích mediích. Není dobré zálohovat data ze stejného FS na stejný FS, pokud by byla chyba v jeho driveru, tak lze přijít o oboje.

Zkrátka, je nesmysl se omezovat pouze na jednu technologii. Nic jako nejlepší FS neexistuje. Vždy záleží na použití a na posouzení výhod a nevýhod. V linuxu máme možnost použít hromadu různých FS, takže pro konkrétní nasazení je vždy možné zvolit ten nejlepší.

[little.owl]

Kde nebudu chtít COW, tak XFS.

xfs ma v podstate CoW, viz zde.

[Heron]

Jo, o této snaze vím, uvidíme, kam se to posune.

[little.owl]

Ono to jiz funguje, staci formatovat s -m reflink=1.

[Heron]

No "stačí". Jak se to potom používá?

V manu čtu:

This feature enables the creation of per-file snapshots and deduplication.

tzn pro cp --reflink=always.

Jak se vytvoří snapshot celého fs?

[little.owl]

Snapshotting a CoW je trochu neco jineho. Zatim si vystacim xfsdump/lvm.

[Petr Tomášek]

Zkrátka, je nesmysl se omezovat pouze na jednu technologii. Nic jako nejlepší FS neexistuje. Vždy záleží na použití a na posouzení výhod a nevýhod. V linuxu máme možnost použít hromadu různých FS, takže pro konkrétní nasazení je vždy možné zvolit ten nejlepší.

+10^10

[Aleš Kapica]

Já bych řekl, že jde tak trochu o zavádějící informaci, kterou si lze vyložit spíš tak, že Red Hat u Enterprise verze opouští svět, kde server i úložiště bylo na jednom stroji – to je oblast kde je Btrfs nejefektivnější. Ostatně proto se také (pokud vím) používá u malých domácích NAS zařízení co dělá Synology. Pro cloudové technologie je výhodnější, když se stroj automaticky začlení jako další nod do distribuovaného systému. Takže na co lokální souborový systém, když stroj může najet rovnou ze sítě a svá lokální bloková zařízení integrovat do cephu.

[little.owl]

Já bych řekl, že jde tak trochu o zavádějící informaci, kterou si lze vyložit spíš tak, že Red Hat u Enterprise verze opouští svět, kde server i úložiště bylo na jednom stroji

Ja bych spise rekl, ze Red Hat nevstupuje to sveta, kde je vsechno monoliticky splacane do jednoho blobu a preferuje flexibilni vrstvenou architekturu, kde ma administrator kontrolu nad jednotlivymi vrstvami a bloky, a muze si vybirat jejich implementaci.

– to je oblast kde je Btrfs nejefektivnější.

Jak kdy. Pokud chcete mit treba vysoky prutok dat, i na jednom stroji, bude CPU bottleneck a nektere veci jako treba CRC ci sifrovani je lepsi offloadovat na speializovany HW. Potom je vrstveny modularni pristup lepsi.

[Aleš Kapica]

No. Vzhledem k tomu, že se považuji za člověka co se přesně tímhle způsobem snaží věci řešit, si myslím, že tomu tak není. Btrfs nenahrazuje LVM ani RAID, jak si někteří myslí. A také to samozřejmě není všespasitelný FS.

[Heron]

Ja bych spise rekl, ze Red Hat nevstupuje to sveta, kde je vsechno monoliticky splacane do jednoho blobu a preferuje flexibilni vrstvenou architekturu, kde ma administrator kontrolu nad jednotlivymi vrstvami a bloky, a muze si vybirat jejich implementaci.

To je sice hezké, ale ještě nikdo neukázal, jak tohle efektivně na více vrstvách implementovat.

Ano, máme vrstvu redundance (MD), ale ta nemá páru o tom, které bloky jsou nebo nejsou používané, takže při výměně disku typicky syncuje vše. Může mít tabulku použitých bloků, jenže tato se bude dublovat, viz další text.

Můžeme mít vrstvu rozdělení (LVM), která třeba může řešit distribuci volného místa pomocí thinprovisioningu (a to, jak to "řeší" LVM považuji za špatný vtip). To znamená, že si opět bude držet tabulku bloků přidělených jednotlivým LV a tabulku volného místa.

Na tím můžeme mít "klasický" fs, který si opět vede tabulku zabraných bloků a dolů posílá info o tom, které bloky jsou uvolněné.

Od roku 2009, kdy BTRFS tohle vše spojil dohromady a vyřešit tak x věcí najednou, sice kde kdo hovoří o tom, jak je to koncepčně špatně, ale ještě nikdo nepřišel s tím, jak to udělat rozdělené do x vrstev a dobře.

Nehledě teda na to, že jediný argument pro rozdělení do vrstev raid, rozdělení, fs nad blokových device je asi tak na úrovni: prostě se to tak dělá.

[trekker.dk]

To je sice hezké, ale ještě nikdo neukázal, jak tohle efektivně na více vrstvách implementovat.

V Linuxu nikdo neukázal ani to, jak to efektivně implementovat na jedné vrstvě. Myslím funkční, takže btrfs se nepočítá.

Ano, máme vrstvu redundance (MD), ale ta nemá páru o tom, které bloky jsou nebo nejsou používané, takže při výměně disku typicky syncuje vše. Může mít tabulku použitých bloků, jenže tato se bude dublovat, viz další text.

Zrovna u tabulky použitých bloků pořád nevidím principiální problém v tom, aby si tuhle tabulku buď

a) udržovalo blokové zařízení, kterého by se vrstvy nad ním mohly ptát

b) udržoval filesystém, kterého by se vrstvy pod ním mohly ptát

Od roku 2009, kdy BTRFS tohle vše spojil dohromady a vyřešit tak x věcí najednou

To moc nevyřešil - jak se diskutuje vedle, implementace RAIDu 5/6 je nefunkční a RAID 1 má, řekněme, významné nevýhody.

sice kde kdo hovoří o tom, jak je to koncepčně špatně, ale ještě nikdo nepřišel s tím, jak to udělat rozdělené do x vrstev a dobře.

Taky se nikdo nesnažil. Postupná evoluce není tak dobrá reklama jako nový a revoluční filesystém.

[Jendа]

Ano, máme vrstvu redundance (MD), ale ta nemá páru o tom, které bloky jsou nebo nejsou používané, takže při výměně disku typicky syncuje vše.

To mi v praxi nepřijde zas takový problém:

• Při chvilkovém výpadku máme bitmapu.
• Na rotačních discích bude při alespoň trochu zaplněném FS rychlejší stejně syncovat vše (lineární čtení+zápis) než seekovat po použitých blocích.
• Jediný problém je to na SSD, ale tam to holt hned po syncu trimnu.

Na tím můžeme mít "klasický" fs, který si opět vede tabulku zabraných bloků a dolů posílá info o tom, které bloky jsou uvolněné.

I tohle se AFAIK v principu umí (FS ti to řekne třeba když děláš trim), akorát to nikdo neimplementoval do MD.

[Heron]

No, takže kromě trimu ve fs (což se dělalo především pro ssd), vlastně není hotového nic.

Nebo jinak, používáte někdo někde ten LVM thin provisioning?

[trekker.dk]

Nebo jinak, používáte někdo někde ten LVM thin provisioning?

Ne, funguje to pěkně blbě. Teda možná to byla MŽK chyba, ale když jsem to zkoušel, tak jsem se dopracoval k tomuhle:

V Debianu Jessie i Stretch není možné uvolnit místo v thin pool zmenšením LV. Po zmenšení LV zůstává podle lvs -a obsazené místo na thin pool stejné. Jediný způsob, jak místo skutečně uvolnit, je LV zcela smazat.

[Aleš Kapica]

Já to chvíli používal, kvůli snapshotování u GlusterFS subvolume a bleskově jsem se toho zbavil, jakmile jsem viděl jak idiotským způsobem tu věc řeší,

[marbu]

A to idiotské řešení bylo v GlusterFS nebo samotném LVM thin provisioning?

[Aleš Kapica]

Snapshotování u GlusterFS. Kdyby to umělo spolupracovat s Btrfs, bylo by o něčem jiném.

Jenže právě kvůli tomu snapshotování jsem to LVM použil. Oproti klasickému LVM thin provisioning přinesl akorát degradaci výkonu a zvýšené riziko výskytu problému. Viz manuál pro LVM_(thin_provisioning) v naší wiki. Dávalo by to smysl leda v případě, že bych provozoval virtuály, které by v celkovém objemu zabíraly víc místa, než kolik jsem měl k dispozici. U klasického LVM diskový oddíl nemůže dostat víc extentů než je k dispozici. Ale je jasné kde která data jsou a lze je tak efektivně rozhodit mezi pomalejší a rychlejší bloková zařízení, cíleně přesouvat, aj. Tam kde je použitý thin provisioning jsou data všude možně v rámci poolu což zvyšuje - obzvláště při častých změnách - fragmentaci dat, což vede pochopitelně k dalšímu poklesu výkonu.

[trekker.dk]

preferuje flexibilni vrstvenou architekturu, kde ma administrator kontrolu nad jednotlivymi vrstvami a bloky, a muze si vybirat jejich implementaci.

Jj, třeba když si chce vybrat z implementace raidu, tak má na výběr z MD raid. Nebo snapshoty a svazky, tam je na výběr z device mapperu. Ne že bych tady zrovna chtěl obhajovat btrfs a jejich přístup "blbě reimplementujeme všechno, co v kernelu už je", ale těch implementací na výběr opravdu moc není.

[Filip Jirsák]

Ostatně proto se také (pokud vím) používá u malých domácích NAS zařízení co dělá Synology.

Zrovna Synology zpřístupnili btrfs docela pozdě, cca před dvěma roky, a to jen pro výkonnější systémy. A výchozí je pořád ext4, btrfs je rozšířená funkce pro znalce.

[Vykook]

Na serveru mám ZFS(FreeBSD) a maximální spokojenost. Kdežto na virtuálu mám CoreOS s btrfs a je to bída. Občas to záhadně zpanikaří(naštěstí tam nejede nic důležitého a restart obvykle pomůže) a utilitky jsou jako drbání hřebíkem v uchu. Desktop nemám a na notebooku HFS+, ale už se vcelku těším na ten novej FS, co bude na podzim v macOSu.

[little.owl]

CoreOS s btrfs a je to bída

CoreOS od btrfs presel kvuli neustalym problemum zakazniku k EXT4 + OverlayFS.

[Vykook]

Já vím, ale není to nějak čas a nálada řešit, každopádně instalace s btrfs, nadále fungujou a jsou aktualizovaný.

[Aleš Kapica]

CoreOS s btrfs a je to bída

CoreOS od btrfs presel kvuli neustalym problemum zakazniku k EXT4 + OverlayFS.

Pámbů s námi a zlý pryč! Red Hell - nomen omen.

[pavlix]

Trochu mi uniká souvislost.

[Want]

To by bylo na delší vyprávění. Používám, i když by asi bylo víc na místě napsat - používal jsem, technologie od Red Hatu docela dlouho, ale poslední dobou mám pocit, že se jejich vývoj ubírá směrem k nepoužitelnosti: stávají se z nich velké, těžko pochopitelné molochy - něco jak MS Win. Dokud to funguje, je to fajn, ale když se objeví problém, tak se v tom šploucháš sám.

Jinak overlayfs používám dost dlouho na to, abych se řešení na něm postavených bál. Ne proto že by nebyly efektivní či nefungovaly, ale opět - komplikují řadu původně jednoduchých věcí. Rozjet je, to je mouška a trivka, ovšem údržba je peklo - proto také ta slovní hříčka.

[pavlix]

O které konkrétní technologii od Red Hatu je zde řeč? OverlayFS? V jakém přesně smyslu, případně šlo by to ozdrojované doplnit do anglické Wikipedie pro nás, co se chceme v tomto trochu dovzdělat?

[Aleš Kapica]

Pacemaker

[Aleš Kapica]

Jinak pokud jde o overlafs, tak to je samozřejmě skvělá věc, se kterou pracuji už dlouhé roky. Ovšem jak na co. Já ji používám kromě systémů v laboratořích při buildování, abych odfiltroval to co je potřeba k buildu od toho co vznikne při instalaci. Vím že s ním takovým způsobem, jak byl zmíněn (základní FS a pak nad ním hromada sendvičů) pracoval dříve docker. Jak je tomu dnes nevím, protože ho nepoužívám. Každopádně mi to řešení nepřišlo šťastné pro případ, že se něco na tom podkladovém FS posere. A fatálně rozbitou ext4 jsem zažil několikrát – na rozdíl od Btrfs.

[little.owl]

A fatálně rozbitou ext4 jsem zažil několikrát – na rozdíl od Btrfs.

Ja mam spise opacnou zkusenost, i kdyz nevidim zadny duvod pouzivat ext4 s ohledem na existenci xfs.

[Aleš Kapica]

A fatálně rozbitou ext4 jsem zažil několikrát – na rozdíl od Btrfs.

Ja mam spise opacnou zkusenost, i kdyz nevidim zadny duvod pouzivat ext4 s ohledem na existenci xfs.

U toho jsem také přišel nepěkným způsobem o data.. Naštěstí to bylo ještě v testovacím režimu, takže jsem to šupem přehodil na Btrfs a od té doby byl klid a mír.

[Jendа]

XFS nejde zmenšit (jako ne že bych zmenšoval FS třikrát denně, ale párkrát už se to hodilo - a kopírovat data tam a zpátky by byl opruz).

[little.owl]

Ano a souvisejici implementace pro ne neni ted priorita.

[lertimir]

XFS mě připadá výborný v případě, že opravdu musím mít zaručeno, že systém nespadne. Měl jsem poměrně nepříjemnou zkušenost, s použitím XFS na desktopu. V případě, že systém spadl, bylo mnoho práce dát dohromady, co bylo na diskích, a asi jednou jsem to dával jen ze záloh. Jednou mě to spadlo díky výpadku napájení, ale několikrát mne spadla desktopová aplikace (tak že pověsila systém, nějaká nedomluva s grafikou). Ve všech případech to dopadlo poměrně dost katastrofou pro XFS. Chápu to. Je to filesystém, který pro sou efektivitu má hodně informací v cache v operační paměti. Ale je fér podotknout, že v případě nějakých možných nestabilit, může být značně nebezpečný. A také je možné, že stav je jiný, událost byla před cca 10 lety. Nicméně možné nestability při práci v gravickém DE mohou jistě nastávat. Nedávno se mi pověsil desktop. Přehrával jsem video VLC playerem (nvidia grafika) a provedl několik rychlých posunů, a ve výsledku všechno zmrzlo, systém přestal reagovat na klávecnici, nebylo možné přepnout session i přestal odpovídat na síťovém rozhraní nefungovalo ssh a ani ping, Takže jiná cesta než tvrdý poweroff nebyla. Všechny disky a i SSD na systém je plně na btrfs, a přežil naprosto bez nejmenšího problému. Následně jsem pustil scruby a OK.

[little.owl]

XFS bylo po 2011, predtim nez to Red Hat pouzil v RHEL, vyrazne prepracovano a vylepseno a cela rada [okrajovych] situaci byla situaci pokryta. Stare zkusenosti z doby pred 2011 jsou do znacne miry pase.

[Aleš Kapica]

Moje zkušenost zase tak stará není - nejsou to ani dva roky.

[little.owl]

To by me zajimalo na cem to provozujete a v jake zatezi. Xfs je ted defakto diky RHEL a SUSE produkcni standard s sirokym nasazenim a velke problemy s tim proste nejsou. V praci mame xfs na diskovych polich v kapacite asi 1000TB, ktere jsou stale v konstatni zatezi - raw video data a simulace, zatim to drzi spolehlive pohromade.

[pavlix]

Tak použití v serverovně a použití na desktopu/laptopu jsou snad dvě naprosto odlišné věci, ne?

[Aleš Kapica]

Byl to jeden ze dvou fungl nových serverů od HP, pochopitelně v serverovně. Jak se nakonec ukázalo, po řadě testů se nakonec potvrdilo mé podezření na vadný řadič. Nicméně Btrfs i přes to dokázalo fungovat, jen bylo pomalejší.

Já tak velká pole jako vy neprovozuji, protože to nepotřebuji a nemám na to ani voný HW. Krom toho musím respektovat přání uživatelů a ti pod mediálním vlivem dnes chtějí mít ZFS.

Doma mám už několik let Btrfs, a už nějaký čas jede v raid1 s využitelnou kapacitou cca 7,5TB. Mohl bych mít i větší – stačilo by dokoupit SAS řadič a stávající disky nahradit za 5TB – to bych se dostal na 40TB, ale je to zbytečné, když i ten stávající prostor je zaplněn jen z půlky. Nicméně systém už dnes všude instaluji jedině na Btrfs.

[Aleš Kapica]

Mimochodem, zrovna u domácích NAS serverů, které si člověk postupně podle potřeby zvětšuje kapacitu z disků co má zrovna po ruce, nemá Btrfs konkurenci.

[Aleš Kapica]

V praci mame xfs na diskovych polich v kapacite asi 1000TB,…

V tom bych řekl že vězí i ten problém s Btrfs. O tom jaký se má použít FS na tak velkých systémech rozhodují konzervativci, co mají s Btrfs jen velmi malé zkušenosti. Logicky si tedy kryjou zadek tím, že použijí to, za co se jim zaručí poskytovatel distribuce.

Osobně bych si chtěl přinejmenším zkusit postavit cloudový systém na stejně výkoném HW, ale s jinými technologiemi, než se standardně používají. Pak by teprve bylo možné něco srovnávat. Jenže takovou možnost nemám. Zkoušel jsem to alespoň s tím co je, jenže v takovém prostředí, jaké jsem dostal k dispozici to bohužel bez totální přestavby nejde. Klíčový problém způsobovalo NFS, kterými jsou ty stroje vzájemně propojené. Dokud všechno jelo, ok. Jenže stačil jeden nedostupný stroj a to NFS zablokovalo IO operace na polovině nodů a to se pochopitelně někde musí negativně odrazit.

[Filip Jirsák]

Pro tyhle případy se hodí klávesa SysRq – pomocí s provedete sync, pak disky odpojíte (u) a restartujete (b).

[pavlix]

Nevím, jak u jiných, ale můj desktop (z hlediska použití) je ve skutečnosti laptop, a pokud se mi stane, že ho nechám ležet bez napájení, tak pak už SysRq nepomůže.

[Fluttershy, yay!]

To se ti neuspí?

[pavlix]

Popravdě se mi ani Gentoo ani openSUSE samo od sebe pří vybytí neuspávají na disk, přestože uspání na disk jinak funguje. Co je k tomu potřeba, aby to systém včas udělal? Jinak bych nebyl proti ani aby se to aspoň ozvalo jako to dělaly staré IBM laptopy, že bych si toho všiml dřív než to „chcípne“.

[Fluttershy, yay!]

Mám Ubuntu s nějakým tím desktopovým prostředím (Plasma, překopané Xfce) a tam si prostě zaškrtnu v dialogu pro správu napájení, že se to má při určitém stavu baterky uspat.

Jestli máš holé i3, asi se bude muset nastavit ručně… mezi prvními výsledky hledání mi vypadlo tohle.

[pavlix]

Jakou máš zkušenost s uspáním na disk v reakci na vybití stroje uspaného do RAM?

[Fluttershy, yay!]

To se mi stalo toliko možná jednou, když jsem laptop dal skoro vybitý do batohu a zapomněl ho tam na skoro týden. Nevzpomínám si, jak vypadal výsledek, ale zjevně jsem to přežil ve zdraví.

Jinak, uspání do RAM mám nastavené na hranici tuším 3 nebo 5 % kapacity baterky a když se to začne uspávat, nejde to přerušit a probudí se to, až pokud je zapojená nabíječka. To může být otravné.

(Pro úplnost, mám X200 s Ubuntu.)

[pavlix]

Díky.

[Filip Jirsák]

Psal jsem samozřejmě o těch problémech s grafikou, kdy uživatelské prostředí přestane reagovat a nejde se ani dostat do terminálu, ale jádro ještě žije. Při ztrátě napájení se počítač vypne, a pak opravdu nepomůže žádná magická klávesa. Nicméně zrovna u toho notebooku je řešitelné i to napájení, protože notebook o nízkém stavu baterie ví a má šanci systém včas hibernovat. Když někdo vykopne napájecí kabel nebo vypadne proud u počítače bez UPS, tahle možnost není, protože o těchhle událostech bohužel nechodí předem notifikace přes ACPI…

[lertimir]

Nezkusil jsem. zkusím pokud se stane příště. A možná nerozumím tomu, co se děje v jádře tak moc, ale moje představa je takováto. Pokud žije jádro, tak by jádro mělo obsloužit síťové rozhraní, nezávisle na tom že DE spadlo a řekněme na urovni DE se pomrvilo zpracování události z klávesnice a myši. Jádro by mělo odpovědět na síťový ping, a následně umožnit SSH login. Pokud na ping odpověď nedostanu a následně začnu dostávat odpovědi Destination Host Unreachable s položkou From sítového rozhraní notebooku, který jsem použil pro vzdálenné připojení, tak si myslím, že padlý stroj neodpověděl ani na ARP a pak neodpoví na nic na sítovém rozhraní. A podobně bych to viděl i na klávesnici, protože na úrovni jádra musím mít zpracování události z usb portu a následné zaslání k zpracování dále, ale pokud v jádru obsluha událostí není funkční, tak velmi pochybuji, jestli SysReq by zabralo. Jedině pokud bych dostal klávesnici do portu PS/2. Ten má skutečně samostatný hardwarový interrupt a měl by být schopen přetlačit i visicí systém.

[trekker.dk]

Jo, problémy s ovladačem grafiky většinou jádro rozbijou tak, že nefunguje vůbec nic. S tím zkusit SysRq nic nezkazíte, ale nic si od toho neslibujte - i když ten stroj není úplně vytuhlý, tak už to "u" má jenom tak 50% šanci na úspěch.

[pc2005]

Jinak nějaký ekvitalent sysrq_do_reset si může člověk přidat i sám do libovolného interrupt handleru.

Ale většinou když se zasekne grafika, tak se zasekne celej systém (třeba tím že grafika přepíše něco důležitýho, nebo se zasekne spinlock atd.). Ze spinlocku se obecně moc lehko dostat nedá (a nízkoprioritním přerušením klávesnice určitě ne).

[Filip Jirsák]

Pokud systém neodpovídá ani na ping, nebude nejspíš fungovat ani SysRq. Ale přeci jen reakce na ping je ještě o několik úrovní výš, než obsluha magických kláves – musí být správně nakonfigurovaná síťová rozhraní, musí to projít přes firewall.

[lertimir]

Právě, zabalil jsem to poté, co jsem se ze sítě k systému nedostal. Tím to řeším vždy nejdříve, když přestane reagovat. Našel jsem PS/2 to USB adapter a klávesnici přehodil do PS/2, což je zpracování na úrovni HW interuptu a pro příště nejdříve zkusim SSH odjinud a pak když nezareaguje, tak SysRq.

[Filip Jirsák]

Trochu mě děsí, že se vám to děje tak často, že už teď děláte přípravy na příště… To je fakt ten ovladač grafiky tak rozdrbaný?

[kralyk z abclinuxu]

Ovladače grafiky jsou děsně dodrbaný taknějak všeobecně. Aktuální laptop mám Intel + nVidia (kterou mám ale skoro pořád vypnutou), přechozí byl jen nVidia, problémy jsou/byly s obojím. V jedné verzi nVidia ovladačů byla např., pokud si to dobře vzpomínám, chyba, která způsobovala deadlock při alokaci v náhodných jiných aplikacích. Intelí drivery taky čas od času způsobí všelijaký vytuhnutí.

Delší dobu už jsem neměl zkušenost s AMD grafikama, ví někdo, jak jsou na tom se stabilitou ovladačů tam?

[little.owl]

Doma jedu na Radeon driverech a zatim zadne problemy jak na desktopu tak na laptopu. Jejich foss drivery jsou dnes z hlediska stability asi nejlepsi co mame. Na pracovnich laptopech mam Intel a situace je o dosti horsi - ted Intel i7 7600U Kabi Lake - a je to celkem PITA. Cekam na nejakou pasivne chlazenou kartu od Amd postavenou na GCN5 (Vega).

[Fluttershy, yay!]

klávesnici přehodil do PS/2, což je zpracování na úrovni HW interuptu

A je?

Pokud vím, tak už řádově 10 let to takhle nefunguje.

[Petr]

Apfs je dostupne uz od sierra, high sierra akorat prinasi do disk utility moznosti vyuziti apfs z gui. Sve macy uz mam vsechny na apfs, snad jenom zena s jejim neni. Podpora aplikaci mizerna (treba takovy google backup and sync apfs ignoruje a je jim fuk ze ten system je vice nez rok dostupny).

[Vykook]

Sem myslel, že to neumí zatím bootovat, ale je pravda, že jsem to zas tak moc neštudoval. Jako varování stačilo https://eclecticlight.co/2017/04/06/apfs-is-currently-unusable-with-most-non-english-languages/

[Petr]

Bootovat to umi, ty znaky jsou problem aplikaci, ne filesystemu. Ale chapu, ze kdyz clovek pouziva vicero ruznych jazyku a par debilne psanych aplikaci tak to problem muze byt. U me cestina, nemcina, nic z toho v mych aplikacich nedela potize. Pokud nepocitam to, ze nektere aplikace odmitnou s apfs delat cokoliv (treba google symc and backup si mysli ze je to networked volume a jelikoz to neni hfs+ tak se odmita bavit o cemkoliv s tim volume). Nastesti takovych aplikaci jsem ja videl minimum.

[Max]

Tam, kde mám SSD jedu btrfs.
Na serverech převážně ext4 (pro oracle a další služby/app), btrfs jen v užším případě, kde potřebuji snapshotovat
Na storage serveru ZFS.
Zdar Max

[MP]

Jak mas na storage se ZFS resenou replikaci? Resp., je rozumna cesta jak ZFS replikovat v realnem case? Nebot neco jako zfs-drbd-zfs asi neni idealni.

[Max]

Nemám, je to jen takový backup storage (cca 60TB SATA pole, asi 14x 2TB, 26x4TB, nebo tak nějak).
Zdar Max

[kralyk z abclinuxu]

XFS všude, kde můžu. Z mé zkušenosti má relativně dobrý výkon a zároveň je to nejrobustnější FS, jaký znám. Veškeré poruchy disků a jiné problémy přežil vždy lépe než ostatní FS.

Jedinou výjimkou je jedna pracovní stanice, kde potřebuju rychle vytvářet kopie velkého repo, tam používám ZFS.

[little.owl]

XFS všude, kde můžu. Z mé zkušenosti má relativně dobrý výkon a zároveň je to nejrobustnější FS, jaký znám. Veškeré poruchy disků a jiné problémy přežil vždy lépe než ostatní FS.

+1 Postupne jsem premigroval vse na xfs. David Chinner a jeho team odvedli dobrou praci.

[pc2005]

Chtěl jsem btrfs při poslední instalaci slackware zkusit, ale 14.2 měla ještě nekompletní podporu (ve všem), takže se nenainstalovala validně.

[Petr]

Co znamena ze se nenainstalovala validne?

[pc2005]

To už si nepamatuju. Buď instalace vůbec nezačla s tím, že nebyl nalezen filesystém, nebo nedokázala nabootovat. Ona je instalačka 14.2 stará rok a má v sobě 4.4 kernel. Brtfs je v ní myslím označenej jako experimentální.

[marbu]

Stabilní (ve smyslu diskového formátu) je btrfs už nějakou dobu:
$ git tag --contains 4204617d142c | head -1
v3.13

[jyrki]

jfs na desktopu i serveru, jen particii sdilenou s druhym systemem (BSD) mam naformatovanou na ext2

[zofrey]

Co je particie?

[Vykook]

Co asi?

[dfgsdfgdfg]

ffs

[mln]

Nad LVM mám btrfs ako systemovy volume a ext4 ako datove volumy. Už vyše rok bez problémov na obyčajnom pc aj notebooku s beznymi diskami. (debian stretch aj nedavno aj linux mint 17.1 s defaultnymi LTS kernelmi). Raid nepotrebujem, (a ak aj ano tak by som to riesil skor na urovni LVM), mam rad btrfs snapshoty.

Nechapem ludí ktorí tlačia btrfs na Raid napriek tomu že na btrfs webstrankach písu že to nie je stabilné/rosypali sa im dáta a potom hejtuju btrfs. RTFM na nich.

[Want]

Btrfs v raid1 je úplně o něčem jiném než md raid1, nebo raid1 v LVM. Replikují se skutečně obsazené datové bloky a chyby na fyzickém HW se projeví dřív, než data zmizí. Neználkové horují proti Btrfs, ale uniká jim, že místo protézy doporučují invalidní vozík.

[MP]

Nj, ale pokud btrfs v raid1 lze mountovat pouze v degraded ro modu a je problem vymenit vadny disk, kdyz je to slozene ze 2...to je pro produkci docela problem.

[Filip Jirsák]

A když to vaše „pokud“ neplatí?

[Aleš Kapica]

Tak je většinou problém mezi židlí a klávesnicí. Viz paralelní diskuze.

[ehm]

Na zálohy výhradně FAT32.

[Petr Tomášek]

LOL.

Na zálohy jedině tar přímo na zařízení

[Michael]

Chtěl bych se zeptat, kolik silent data corruption už ti to odhalilo (ideálně teda na počítači s ECC). Mně i několika dalším lidem z místních diskuzí zatím 0.

admin: jedná se o strojově generovaný spam, odkazy smazány

[vencour]

Zkuste když tak diskutovat v Dotaz: perspektiva reiserfs vs btrfs či zfs, případně Dotaz: jak rozdelit disky na server, jaký RAID a co pouzit btrfs nebo zfs.