Vyjádření SUSE k souborovému systému Btrfs

Společnost Red Hat s vydáním Red Hat Enterprise Linuxu 7.4 oznámila ukončení podpory souborového systému Btrfs. Bude to mít vliv na podporu Btrfs v linuxových distribucích SUSE Linux Enterprise? Odpověď v příspěvku na blogu SUSE: Kdyby Brazílie, jeden z největších producentů hovězího masa, oznámila, že přestane produkovat ryby, ptali byste se, zda Peru, jeden z největších světových producentů ryb, přestane produkovat ryby? Pravděpodobně ne. Stejně je to s Btrfs. Btrfs je a nadále zůstane výchozím souborovým systémem v SUSE Linux Enterprise [reddit].

24.8.2017 11:11 | Ladislav Hagara | Zajímavý článek

Komentáře

[little.owl]

Nevim, podstatne veci nebyly adresovany. Podle me btrfs ve stavu jakem je/bylo nikdy nemelo byt vubec akceptovano do 'stabilniho' kernelu a LinusT se tady bohuzel choval nestandardne. Jedna vec se musi ZFS nechat - behem vyvoje nedostali uzivatele svych verzi do situace, kdy by mohli prijit o sva data.

[cezz]

Tak nejake problemy tam boli a teoreticky si mohol o data prist, ale pravda nie v takom rozsahu ako BTRFS. Kazdopadne to bola pre mna z tohto pohladu pomerne jasna volba. Zalohy sice clovek musi robit tak ci tak, ale obnovovaniu par TB dat sa radsej vyhnem.

[trekker.dk]

Podle me btrfs ve stavu jakem je/bylo nikdy nemelo byt vubec akceptovano do 'stabilniho' kernelu a LinusT se tady bohuzel choval nestandardne

To je blábol. U filesystémů a ovladačů zařízení dlouhodobě platí, že se do stabilní řady přidávají, i když nejsou vhodné pro produkční nasazení - pokud se nejedná o kód ve špatném stavu a bez vyhlídek na údržbu a vylepšení. Důvodem je, že pokud je používáte, je to jenom vaše rozhodnutí a nemá to negativní vliv na ostatní uživatele.

[kralyk z abclinuxu]

No tak od toho je označení (EXPERIMENTAL) v make menuconfig, ne?

[Sten]

Btrfs také bylo označené jako experimental v době, kdy nebylo zrovna stabilní. Stejně tak řvalo mkfs.btrfs.

[little.owl]

To je blábol. U filesystémů a ovladačů zařízení dlouhodobě platí, že se do stabilní řady přidávají, i když nejsou vhodné pro produkční nasazení - pokud se nejedná o kód ve špatném stavu a bez vyhlídek na údržbu a vylepšení.

Ne, btrfs dostal vyjimku, kdy cilem bylo mu pomoci ve vyvoji. Zadny jiny filesystem nebyl vpusten v tak mizernem do stavu. Staci se podivat do dokumentace v release 2.6.30:

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review.

Takovy kod normalne zustava ve vyvojove vetvi dokud neni trochu pouzitelny a nove funkce se pridavaji, az kdyz existujici jsou stabilizovane, a novy kod je nesmi rozbit. Ted, osum let pozdeji, btrfs jiz oficialne neni experimentalni, a presto plno fuknci je stale "neprodukcnich" a mesice oficialne rozbity kod raidu 5/6. Jednoduchy test jakym byla tato chyba objevena jen ukazuje, ze btrfs team v podstate svuj kod poradne netestuje a kod neni rozumne rewiev-ovany a ja skutecne doufam ze tohle neni standardni situace - protoze jink bych uz vecer bootoval FreeBSD.

[trekker.dk]

Ne, btrfs dostal vyjimku, kdy cilem bylo mu pomoci ve vyvoji. Zadny jiny filesystem nebyl vpusten v tak mizernem do stavu.

Tak citujte tu výjimku.

Zadny jiny filesystem nebyl vpusten v tak mizernem do stavu.

A co Ext4? Nebo přesněji ext4dev, který v mainline byl do doby, než ho prohlásili za dostatečně stabilní a přejmenovali na ext4?

[little.owl]

Tak citujte tu výjimku.

Musel bych to dohledat, ale bylo to zrejme z tehdejsich diskuzich. Btrfs byla odpoved na hrozici ZFS od Sun, kdy ostatni velci hraci jako Red Hat, SUSE, Fujitsu ci HP chteli mit alternativu v kernelu, viz treba clanek zde. Komicke to cist opet po letech.

A co Ext4? Nebo přesněji ext4dev, který v mainline byl do doby, než ho prohlásili za dostatečně stabilní a přejmenovali na ext4?

Ext4 vzniknul jako zpetne kompatibilni extension ext3, a diky tomu byl od prvniho commitu velmi dobre pouzitelny. Ext4 tedy existuje jen proto, ze Linus opatrne odmitl udelat takove zmeny na existujicim ext3 a tak vznikl novy fs, viz. treba vlakno zde. To se proste absolutne neda srovnavat.

[lertimir]

Tak citujte tu výjimku.

Musel bych to dohledat, ale bylo to zrejme z tehdejsich diskuzich. Btrfs byla odpoved na hrozici ZFS od Sun, kdy ostatni velci hraci jako Red Hat, SUSE, Fujitsu ci HP chteli mit alternativu v kernelu, viz treba clanek zde. Komicke to cist opet po letech.

Nicméně to všechno se dá pochopit. Chápu, že velcí hráči chtěli mít alternativu, chápu i rozhodnutí začlenit jej do kernelu, byť v té době to bylo více politické než odborné rozhodnutí. To co ale nechápu, proč za 8 let vývoje s zájmem a podporou velkých hráčů, to není plně funkční.

[little.owl]

To co ale nechápu, proč za 8 let vývoje s zájmem a podporou velkých hráčů, to není plně funkční.

Zejmena kdyz tu uz mame krome ZFS, Appli APFS a Microsofti ReFS, ktere sice papirove nejsou tak impozantni, ale za kratsi dobu se dostaly do [temer] produkcniho stavu.

[lertimir]

Nebo, když Reiser dokázal udělat tak dobré fs v podstatě jako one-man-show. (možná to, že je to magor s tím souvisí )

[fin]

Reiser není magor, ale oběť spiknutí. On fakt není ten, kdo vraždil. Zjisti si fakta.

[trekker.dk]

Tak až to dohledáte, tak dejte vědět. To tvrzení o ovladačích a filesystémech se za posledních pár let několikrát objevilo na LWN a u těch předpokládám, že ví, o čem mluví.

[little.owl]

V principu to tak je, to nepopiram. Jen tvrdim, ze Linus tehdy vyrazne slevil ze svych kriterii a neocekavejte, ze budu nekdy schopen najit jeho citaci. Tehdy nikdo asi neveril, ze ani po osmi letech to bude, bohuzel, jeste v soucasnem stavu.

[Petr Tomášek]

ed, osum let pozdeji, btrfs jiz oficialne neni experimentalni, a presto plno fuknci je stale "neprodukcnich" a mesice oficialne rozbity kod raidu 5/6.

No a? Ostatní funkce jsou stabilní dost. Jen to asi chce důraznější dokumentaci toho, co je stabilní a co experimentální.

[Petr]

Stabilni? LOL. Nedavno se tady rozebirali potize tohodle Beta FS a zkus se podivat treba na https://btrfs.wiki.kernel.org/index.php/Status nebo https://btrfs.wiki.kernel.org/index.php/Gotchas . Me oblibene: "when you do device removes on file systems with a lot of snapshots, it is unbelievably slow ... took nearly a week to move 20GB of FS data from one device to the other using that method" "a balance on 2TB of data that was heavily snapshotted - it took 3 months" "try to avoid having more than 8 snapshots due to the overhead" "when I have to do balances ... I delete all the snapshots and allow a few months for the balance to finish" Tomuhle rikas stabilni? Vzdyt to ani neumi vymenit disk kdyz ma chybne sektory. A kdyz ti nahodou zdechne disk v raid1, tak dostanes trvale read only. Tohle je horsi nez beta.

[xkucf03]

Stabilni? LOL. Nedavno se tady rozebirali potize tohodle Beta FS…

GNU/Linux používám už dost dlouho a co si tak pamatuji, tak bouřlivé diskuse o souborových systémech se vedou odnepaměti a snad u každého FS se objeví někdo, komu to ztratilo data nebo totálně rozbouralo systém.

[little.owl]

Zadny jiny FS nebyla takova tragikomedie, snad krome nekterych "killer features" ReiserFS.

[Petr Tomášek]

Moc do toho taháš pocity.

[kralyk z abclinuxu]

Tak ono po těch letech (částečně) falešných nadějích ten pocit zklamání IMHO je na místě...

[Petr Tomášek]

Problém pocitů je, že dělají svět čenobílý.

[kralyk z abclinuxu]

Nemyslim si, že nutně. Osobně pro mě je fíčura č. 1 filesystému jeho spolehlivost / robustnost. Možná jsem moc konzervativní, ale tohle je pro mě nutná podmínka, kterou nemůže vyvážit žádné množství dalších fíčur (jako snapshoty/COW atd.), jakkoli jsou třeba užitečné. Btrfs jsem považoval od začátku za zajímavý projekt, bohužel ale stále z mého pohledu nesplňuje tu základní podmínku, takže ho nenasazuju, to je celé.

[little.owl]

Možná jsem moc konzervativní, ale tohle je pro mě nutná podmínka, kterou nemůže vyvážit žádné množství dalších fíčur

To neni konzervatismus, ale zdravy rozum.

[j]

Myslis jako trebas NTFS u M$ ... kde si jen tak zacnou pouzivat nedokumentovanej priznak? Coz pak vede ke zmrveni dat, protoze si stejnej priznak uz pouziva nekdo jinej (protoze proc ne, kdyz se nepouziva ze ...)?

[kralyk z abclinuxu]

NTFS nepoužívám / vůbec mě netankuje.

[little.owl]

To neni o pocitech, pokud jde o moje data zajimaji me spise fakta.

[Petr Tomášek]

Podle toho, jak se ale vyjadřuješ ve svých příspěvcích, to nedělá moc dojem, že by sis lámal hlavu s fakty.

[pavlix]

Od někoho jiného by ta kritika možná dávala smysl... :)

[kralyk z abclinuxu]

"killer features" ReiserFS.

Pun intended?

[Petr Tomášek]

BTRFS používám na to, co umí dobře a při normálním používání to stabilní je. Na RAID používám RAID.

Pleteš si stabilitu s podporou pokročilých funkcí a se známými (a deterministickými) chybami.

[Petr]

Takze btrfs pouzivas na jednom disku s jednim oddilem bez snapshotu, bez raidu, bez vseho ostatniho co nabizi? To muzes klidne nahradit dernymi stitky... treba snapshoty pouzivam bezne a nemit system ve kterem bych mel moznost mit kazdou hodinu snapshot by bylo pro me jako nemit moznost mit ruce. To same komprese - diky kompresi mam read ze storage daleko rychlejsi a obcas se to hodi. A i kdyz se to nedoporucuje, tak mam zaplou dedup na nekterych poolech, protoze to dava smysl (a ram neresim). Zaklad btrfs je patrne funkcni, ale to co lidi od nej ocekavaji a co jsou jeho killer features je proste nedodelane a nedoladene.

[Petr Tomášek]

Jak kde. Někde používám btrfs nad md-raidem a se snapshoty. U věcí jako je router používám btrfs nad jedním zařízením.

[Sten]

Ale dostali. Třeba při výpadku proudu se až do nedávna ZoL umělo dostat do stavu, kdy mount vyvolal panic, protože neumělo rollback nekompletní transakce.

[trekker.dk]

ZoL nebo ZFS? Přece jenom je to rozdíl.

[little.owl]

Hadam, ze ZFS je designovano pro nasazeni v systemech, kde pravdepodobnost vypadku napajeni systemu je extremne mala. To srovnavat s btrfs, ktere se stale jeste rozpada i za normalniho chodu bez selhani HW a jadra OS opravdu nejde.

[anonym]

ZFS bylo designovano tak aby nikdy (krom pripadu umrti vetsiho poctu disku nez je redundance) neztratilo data ktera potvrdilo zapsana. Vypadek proudu v libovolny moment nevyjimaje. Drtiva vetsina poskozenych ZFS je zpusobena disky ktere nerespektuji cache flush/write barrier, a vesele potvrdi zapis dat ktera jsou jen v cache. Tohle bohuzel dela netrivialni mnozstvi 'consumer' disku, protoze pak vypadaji rychlejsi nez jsou.

pro porovnani, btrfs stale obsahuje write hole, coz je znamy problem klasickych RAID systemu (pri vypadku behem zapisu se poskodi data 'pobliz', bez moznosti obnovy). ZFS tohle vyresilo pred 10 lety.

[t]

pouzivam ho uz roky a nasadzujem ho v domacom pouziti, kde sa da, hlavne na raspberry. Jednoduche snapshoty a rollbacky, online komprimacia, lepsia podpora sd kariet a ssd diskov, akurat kvoli swapu treba este stale davat lvm alebo swap na zvlast particiu. V zaciatkoch sa mi stalo, ze sa mi pokazil btrfs, ale od vyssej verzie (uz neviem ktorej) to ide paradne. Zial, na enterprise riesenie btrfs nie je vhodne.

[kralyk z abclinuxu]

Moc se RedHatu nedivím, btrfs IMHO doposud nikdy moc nejevilo známky, že by se dal nějak moc očekávat posun od experimentálnosti ke stabilitě a spolehlivosti. Což u filesystému není moc dobré znamení, zejména vzhledem k tomu, že už je ve vývoji taky nějaký ten pátek...

[jk]

Kdyby Brazílie, jeden z největších producentů hovězího masa, oznámila, že přestane produkovat ryby, ptali byste se, zda Peru, jeden z největších světových producentů ryb, přestane produkovat ryby?

zajímavé, že aktivity SUSE a Red Hatu přirovnávají k neudržitelnému hospodářství bezohledně devastujícímu životní prostředí.

jaké důsledky z té reflexe vyvodí?

[trubicoid2]

nesouvisí to s umělým masem od Billa Gatese?

[Petr Tomášek]

Bez ohledu na brazilské sado-maso je dobře, že tu btrfs vedle ext4 i vedle ZFS a vedle dalších méně rozšířených FS je. A jsme rád, že tu je někdo, kdo do vývoje btrfs existuje a jsem rád za funkce, které btrfs nabízí, přestože nejsem žádný zanícený propagátor tohoto systému jako jediného správné FS...

[vencour]

Dovolil jsem si udělat anketu, jaký filesystém preferujete.

[Peter Golis]

No bóže. Tak má RH zmluvu s MS že bude podporovať deduplikáciu len na jednom FS. Tým FS nebude BTRFS, ale NTFS, a bude to v MS kontajneri pod ktorým budú bežať akože linuxové veci.

[Petr Tomášek]

Myslím, že jsi uhodil hlavičku na hřebíček.

[Peter Golis]

Ďakujem za ponuku. Ale ja radšej Myristicca Fragrans ako Eugenia caryophyllata.

[Pan_Filuta]

Deduplikace na Windows nebude možná jen v NTFS jako tomu je nyní, ale už je venku beta Win Server 2016 kde je možná deduplikace v REFS.

[Jana J.]

Jenom podotknu, že ve skutečnosti deduplikace v NTFS není. Samotný filesystem ji neumí. V reálu to funguje tak, že deduplikovaná data jsou v databázi NAD tím filesystemem, v jednom z podadresářů pod "System Volume Information". Drobná chyba je pak v tom, že pokud se při havárii FS (třeba při vypnutí stroje natvrdo) databáze poškodí, máte data v čudu a chkdsk si toho vůbec nevšimne, chyby se objeví až při pokusu daná data přečíst. Takže na deduplikaci ve Windows pozor...

[Peter Golis]

Pre prípad zlyhania FS sú predsa zálohy, občas aj s archiváciou. Podľa potreby.

[Filip Jirsák]

Jenže to musíte nejprve vědět, že FS selhal. Což je trochu problém, když „chkdsk si toho vůbec nevšimne“.

[Peter Golis]

Človek nepotrebuje kontrolu disku na to aby si uvedomil že dáta ktoré používa sú "pokazené". Kontrola FS je len jedna z možností ako takéto dáta identifikovať.

[Jana J.]

Chci vás vidět, jak na fileserveru s několika miliony souborů řešíte po X dnech stížnosti uživatelů, že nemůžou přečíst soubory, které delší dobu nepoužívali a teď se do nich chtějí podívat. Protože na aktivní soubory se deduplikace ve výchozím stavu neaplikuje.

[Peter Golis]

Ďakujem, riešil som to. Ale chkdsk alebo fsck takéto chyby v prípade silent data corruption neobjaví ak súborový systém sám nerieši checksumming a podobné cudzie slovíčka. Mimochodom, podobné srandičky sa dajú očakávať aj pri napríklad ramsonware.

[Filip Jirsák]

Ano, pokud se na to nepřijde při preventivní kontrole, je to ten druhý případ, o kterém psala Johanka: „chyby se objeví až při pokusu daná data přečíst“. A to je pak pěkný průšvih, protože máte starou zálohu a k tomu aktuální data, která jsou částečně dobře a částečně špatně. A jediné, co s tím můžete dělat, je pokusit se ručně „zmergovat“ tu zálohu s aktuálními daty.

[Peter Golis]

Pokiaľ tie dáta pravidelne nečítate pri zálohe, tak máte niekde v návrhu dosť veľkú chybu. Pevne verím že tú chybu nemáte nazvanú incremental forever. Vtedy by ste boli aj s Johankou tam, kde to opisujete.

[Filip Jirsák]

I čtení při pravidelném zálohování je čtení – a i takové čtení proběhne až nějakou dobu po poškození dat, a mezi tím je právě ta doba, kdy se zapisují nová data do poškozeného systému.

[Peter Golis]

To je žiaľ, bežné riziko. Ak chce človek používať FS ktorý nemá samozáchranné mechanizmy, tak je to jeho problém. A ak dodávateľ nechce podporovať FS s samozáchrannými mechanizmami, tak je to problém nákupcu.

[Jana J.]

Čímž se obloukem dostáváme zpět k tématu mého prvního příspěvku v tomto vlákně: bacha, deduplikace NTFS ohrožuje vaše data, můžete o ně přijít a kontrolní mechanismy vás na to neupozorní.

[Peter Golis]

Čím sa dostávame k tématu môjho prvého príspevku v tomto vlákne. Redhat nebude predsa plytvať ľudskými zdrojmi na podporu deduplikácie mimo NTFS.

[Heron]

Hmm, tato diskuse mě trochu připomíná dotaz vedle v poradně na SSD, kde opět někdo nezapomněl přispěchat s tím, že SSD jsou nespolehlivá a že by je nikdo neměl používat. Tj. taky takový urban legend.

Kdysi jsem o SSD napsal, že i kdyby to chcíplo den po záruce, tak se to sakra vyplatilo (ta rychlost proti HDD). O BTRFS bych mohl napsat totéž. I kdyby to "po záruce" přišlo o data, tak všechny ty COW vlastnosti se sakra vyplatily.

Za těch no už skoro 7 let jsem o data s BTRFS nepřišel. Naopak, díky snapshotům mám konzistentní zálohu klidně každých 10 minut (snap, rsync na zálohovací server). Díky vlastnostem snapshotů, kdy každý snapshot je samostatně zapisovatelná subvolume (a lze ji dále snapshotovat) mám ulehčenou práci, protože kdykoliv něco dělám nad větším objemem dat, tak si nejenom můžu pořizovat snapshot po každém příkazu, ale taky se kdykoliv můžu vrátit do libovolného bodu, a tam si ověřit třeba alternativní postup. Taková binární správa verzí. Zdarma.

[Jana J.]

Nojo, ale rozbíjí se to na RAIDu. Ostatní FS ne, takže je to špatně.

[MP]

Tak dame zfs nad hw raid a uvidime, jak dlouho se nerozbije ;)

[little.owl]

Kdyby to byl jen raid, tak by to nebyla az takova tragedie.

[Petr]

Dobry, co takhle udelat raid1 v btrfs se dvema disky, pak jeden disk fyzicky vzit a zkusit pak pridat novy disk misto toho co jsi vzal? Ze to btrfs nerozchodi a mas 1 device raid RO? Ano, znama chyba. Ze se serou data s raid 5/6 je taky znama chyba. Takze sice btrfs ma neco jako raid, ale vicemene nefunkcni. Jeste furt jsou to urban legends? Poridim si SUV ale ma svetlou vysku 10cm a vykon 2 kone. Sice mi vyrobce tvrdi, ze je to to nejlepsi vozidlo pro me ucely, ale to ze nejdou vymenit kola se ignoruje a ze se neda pouzit na to co od suv ocekavam je taky moje chyba. ;)

[Heron]

Dobry, co takhle udelat raid1 v btrfs se dvema disky, pak jeden disk fyzicky vzit a zkusit pak pridat novy disk misto toho co jsi vzal? Ze to btrfs nerozchodi a mas 1 device raid RO?

Ano, o tomhle jsem psal třeba tady. O data se nepřijde, nový disk lze přidat, ale musí se to odmountovat.

Ze se serou data s raid 5/6 je taky znama chyba.

raid56 nikdy nebyl označen jako hotový, pokud tuto vlastnost někdo používá na vlastní riziko, neměl by si potom stěžovat, že přišel o data. Spíše by měl napsat bugreport s popisem, jak tomu došlo.

Takze sice btrfs ma neco jako raid, ale vicemene nefunkcni.

Mě ten nefunkční raid funguje už 7 let.

[trekker.dk]

O data se nepřijde, nový disk lze přidat, ale musí se to odmountovat.

No, asi se shodneme, že tohle je raid1 na hovno

[j]

To jiste ... ale porad lepsi nez ZFS, ktery jak uz bylo zmineno chcipe nad HW raidem a to vcelku pravidelne, kdezto problemy s raidovanim na BTRFS jsou jen za jisty konstelace okolnosti (a HW raid tomu nevadi vubec).

[cezz]

Nejaky link by nebol?

[Filip Jirsák]

RAID s hotswapem je samozřejmě lepší, než RAID bez hotswapu, ale i RAID bez hotswapu je pořád výrazně lepší, než žádný RAID. Ale mohli bychom se shodnout na tom, že používat degradovaný RAID1 s jedním diskem jako by se nic nedělo není dobrý nápad. A když ten RAID používáte po dobu rekonstrukce způsobem „něco se děje“ (tj. ideálně aplikace nezapisuje data, o která nechcete přijít), to odmountování zase tolik nevadí, ne?

[xkucf03]

Tenhle pohled chápu, ale na druhou stranu: to riziko může být v mnoha případech přijatelné. Jaká je šance, že ti odejde i druhý disk, než stihneš vyměnit první? Pokud není ze stejné série nebo se liší dobou používání, tak s největší pravděpodobností oba disky selžou v jinou dobu. Nějaké malé riziko tu samozřejmě je.

A můžeš být v situaci, kdy je lepší systém udržet v provozu i za cenu rizika, že bys to přinejhorším musel obnovovat ze záloh a/nebo o část dat přišel. Zvlášť pokud je to systém, který poskytuje nějakou službu, většinou čte a málo zapisuje. Třeba si představ nějaký zpravodajský portál – výpadek by byl problém, ale risknout ztrátu posledních dat tak hrozné není – autorům bys řekl ať si od všeho drží kopii u sebe a přinejhorším to tam vloží znovu. Pak bys při výpadku přišel leda komentáře čtenářů – ale i ty by šlo zachránit třeba logováním na reverzní proxy nebo logováním v aplikaci a odesíláním logů po síti jinam.

Mimochodem na Btrfs bys mohl udělat snapshot, ten odzálohovat a průběžně pak dělat snímky a ty inkrementálně odesílat po síti na spolehlivější disk – tím by byl systém bez výpadku a zároveň bys nepřišel o data (maximálně o rozdíl mezi posledními snímky). Ale k tomu by právě bylo potřeba, aby ten RAID nespadl do RO režimu.

[Filip Jirsák]

Jaká je šance, že ti odejde i druhý disk, než stihneš vyměnit první? Pokud není ze stejné série nebo se liší dobou používání, tak s největší pravděpodobností oba disky selžou v jinou dobu. Nějaké malé riziko tu samozřejmě je.

Zároveň je ten disk v době rekonstrukce mnohem zatíženější – musí se z něj přečíst celý obsah, a pokud nad ním dál běží aplikace, musí se z něj přečíst dvojnásobek toho, co normálně.

A můžeš být v situaci, kdy je lepší systém udržet v provozu i za cenu rizika, že bys to přinejhorším musel obnovovat ze záloh a/nebo o část dat přišel.

Jak jsem psal, RAID s hotswapem je samozřejmě lepší, než RAID bez hotswapu. To ale neznamená, že RAID bez hotswapu je k ničemu. Navíc pokud vím, celá ta operace, kterou je nutné udělat s btrfs, je odpojit souborový systém, připojit v degradovaném režimu, vyřadit disk z RAIDu, a znovu odpojit souborový systém a připojit v normálním režimu. To je kratší odstávka, než reboot kvůli aktualizaci jádra.

[Heron]

Dostupnost se dá řešit i jinými způsoby, než "vždy dostupným blokovým zařízením" (což řeší raid). Služba, která nikdy nesmí vypadnout by měla běžet na více strojích a být schopná přežít výpadek celého stroje. Odchází i další komponenty, nejen disky - v jednom serveru nám odešel jeden ze dvou zdrojů, jelo se dál, ale po montáži a zapnutí nového zdroje se celý server vypnul a už jej nebylo možné zapnout - odešla společná část obou zdrojů.

Tedy zrovna ten zpravodajský portál může běžet na x strojích s tím, že není nutné, aby jednotlivé stroje byly extrémně spolehlivé, takže i ten disk tam může být třeba jen jeden. Jednou za pár let se vymění, nainstaluje image a sesyncují se data. Nebo se vymění rovnou celý stroj. Což může být rychlejší, než čekání na resilvering nějakého "robustního" pole. (Kde pole může být tak "robustní", jako se nám stalo s jedním HW řadičem, kdy po vložení disku výměnou za vadný, to pole ten nový disk prostě začalo používat. Bez resilveringu. Pochopitelně všechna data v tahu.)

Odejít může cokoliv, odejít může i duální zdroj a duální řadič disků, tedy pokud je vyžadována maximální dostupnost služby, je nutné to stejně řešit jinak.

[xkucf03]

Služba, která nikdy nesmí vypadnout by měla běžet na více strojích a být schopná přežít výpadek celého stroje.

Provozovat službu (aplikaci) na více strojích je většinou celkem jednoduché – problém je s provozováním úložiště na více strojích resp. je to složitější.

Odejít může cokoliv, odejít může i duální zdroj a duální řadič disků, tedy pokud je vyžadována maximální dostupnost služby, je nutné to stejně řešit jinak.

Může to být replikovaná databáze, clusterový FS, blockchain… Ale vždy bych začínal jednoduššími řešeními – RAID je základ a aplikaci není potřeba nijak upravovat, aplikace si ani nemusí všimnout, že nějaký disk odešel a byl mezitím vyměněn.

BTW: Btrfs používám (kvůli snapshotům a zálohování) a jsem za něj rád, ale pár věcí mi tam pořád chybí – problém je hlavně když chci mít šifrovaný disk a RAID – dneska mám většinou MD RAID, LUKS, LVM a Btrfs. Na jednu stranu je to dobrý unixový přístup, kdy každý komponenta/vrstva řeší to svoje a ostatní od toho abstrahují, ale na druhou stranu to nevyužívá potenciálu, který ten souborový systém má – Btrfs neví, že jsou pod ním dva fyzické disky a nemůže z toho těžit. Mohl bych sice udělat dva šifrované disky a ty dát do Btrfs RAIDu, ale pak by se všechna zapisovaná data musela šifrovat dvakrát.

[Heron]

clusterový FS

To je podle mě nejúchylnější věc vůbec. Jedno blokové zařízení sdílené x servery a nějak řešené zamykání (většinou ještě navíc mimo tu blokovou vrstvu). Problém to nijak neřeší a jen odsouvá, protože stáje je nutné to jedno blokové zařízení mít na x serverech a řešit sync mezi nimi.

To už je mnohem lepší nápad distribuovaný fs, kdy jsou data rozprostřena na více uzlech (ideálně rovnocenných).

Ale vždy bych začínal jednoduššími řešeními – RAID je základ a aplikaci není potřeba nijak upravovat

Nejsem si jist, zda bych to nazval jednodušším řešením. Bohužel se setkávám přesně s tímto přístupem - aplikace je posvátná kráva, na tu se sahat nebude a vy nějak zařiďte, aby: to používalo x procesorů, x strojů, aby se to dalo bezvýpadkově migrovat, aby se to odstínilo od výpadku sítě, aby to nevědělo o změně storage apod. Přitom hromada věcí se dá řešit jen jiným návrhem aplikace.

[trekker.dk]

Ale mohli bychom se shodnout na tom, že používat degradovaný RAID1 s jedním diskem jako by se nic nedělo není dobrý nápad.

Ani ne. Od toho tam ten druhý disk je, abych nemusel dělat odstávku kvůli výpadku disku.

A když ten RAID používáte po dobu rekonstrukce způsobem „něco se děje“ (tj. ideálně aplikace nezapisuje data, o která nechcete přijít), to odmountování zase tolik nevadí, ne?

No jestli považujete "žádný přístup" k fs za skoro to samé jako "aspoň read-only, když už nic lepšího není", tak prosím. Já jako člověk se zkušenostmi s produkčního provozu něčeho, co zákazníci platí ze svého a ne z daní, to ovšem za skoro to samé považovat nemůžu.

[Filip Jirsák]

Od toho tam ten druhý disk je, abych nemusel dělat odstávku kvůli výpadku disku.

Jenže při výpadku disku tam ten druhý disk není. Ten druhý disk tam je proto, aby ten výpadek byl co nejkratší. Pokud někdo chce riskovat, samozřejmě může provozovat systém dál i na degradovaném RAIDu.

No jestli považujete "žádný přístup" k fs za skoro to samé jako "aspoň read-only, když už nic lepšího není", tak prosím.

Proč žádný přístup k FS? Když přepínáte souborový systém do read-only režimu, musíte ho remountovat, když ho přepínáte zpět do režimu zápisu, musíte ho opět remountovat. Když přepínáte btrfs do degradovnaého režimu, abyste mohl vyjmout vadný disk, musíte ho remountovat, a když ho po vyjmutí disku chcete vrátit do nromálního režimu, musíte ho opět remountovat. V obou případech musíte souborový systém dvakrát remountovat – nějak v tom nevidím ten zásadní rozdíl.

[trekker.dk]

Pokud někdo chce riskovat, samozřejmě může provozovat systém dál i na degradovaném RAIDu.

Tolik vaše teorie. Musí se nechat, že s teoriemi máte docela plodné období. Do praxe se sice moc netrefujete, ale tím se nenechte odradit.

[MP]

Vcera jsem na jednom produkcnim stroji udelal pekny kiks...mam na serverech molly-guard pro ochranu pred vzdalenym restartem a nejak jak jsem byl zamyslen, tak jsem server na dalku vypnul a nevsiml si cekajiciho molly-guard na potvrzeni. Nasledne jsem vyndal postupne 4 disky ze 4 (btrfs raid10), nez jsem si vsiml, ze ten server stale bezi. Server jsem natvrdo vypnul a dal disky zpet a cekal co se bude dit. Oprava nekolika orphaned souboru a jelo se dal, btrfs pole to prezilo bez problemu. A to se tam neustale zapisuje neco do db/rrd souboru.

[trekker.dk]

Kdysi jsem o SSD napsal, že i kdyby to chcíplo den po záruce, tak se to sakra vyplatilo (ta rychlost proti HDD).

A bylo to podložené nějakými počty, nebo je to vaše urban legend?

[j]

Jedinej problem s SSDckem je ten, ze te pred chcipnutim nijak nevaruje. U disku mas slusnou sanci, ze (v desktopu) zacne trebas cvakat ... ale jeste porad precte data.

V serverovym zeleze je to zcela sumafuk, tam mas HW raid a kdyz chcipne tak ho proste vymenis. Ekonomicky pak vubec nema smysl resit, protoze 200IO HDD vs 20 000IO (pomalyho) SSD ... Co je pravdepodobnejsi, ze chcipne nekolik (ze stovky) disku (a slozi se cely pole) nebo ze chcipnou 2 ze 2 SSD?

[Sten]

SSDčko to většinou zahlásí přes SMART. HDD taky, ještě než začne cvakat.

[j]

Kdykoli mi cokoli chciplo tak SMART nehlasil vubec nic co by stalo za hovor. Dokonce v pripade SSDcka zrovna mam jedno takovy polochciply na stole. Kdyz se zrovna pripoji, tak je SMART naprosto OK, ale ono se tak ze 60% vubec nenajde. Na druhou stranu mam HDD, kde SMART pinda na nektery z tech cisel ... a ten disk v presne tomhle stavu bezi a bezi ... uz 5+ let.

[kralyk z abclinuxu]

Většina mechanických HDD, které mi selhaly, žádný zvuky nedělaly.