Dotaz: XFS zhrouceni filesystemu - neopravitelne

[Lampa]

Pouzivame xfs defacto vsude, akorat s timto fs mame problem, kdyz na disku dojde misto, tak na 99% dojde k sesypani systemu. Pouzivame jej na zalohovani - inkrementalni zalohy pres rsync (hardlinky) - takze minimum souboru ale milionu inodu. A podle me v tom je ten problem. Pri pokusu o opravu xfs to sice se tvari ze neco opravuje, ale nic neopravi, navic to tvra neuceritelne dlouho - jedna se o 3TB a vetsi disky v HW raidu, ale i v SW, i ve virtualizovanem prostredi (vmware). Oprava disku vetsinou dopadne tak ze spadne (killne ji kernel, protoze sezere vsechnu pamet). I kdyz jsem daval parametry, ktere omezuji pamet pri xfs_repair (xfs_repair -v -t 60 -m 4096), tak to stejne nepomohlo, stejne xfs nedobehnul po nekolika hodinach. Jedna se o system Debian 8, Linux hades 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux. Ale problem se mi stal i na Debianu 9, Linux poseidon 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux.

nemate nekdo zkusenosti s timto pripadne nejake reseni ?

Diky

Odpovědi

[dustin]

Pro xfs_repair s miliony harlinků stačí do kompu připojit SSD a na něj dát souborový swap. Máme těch souborů pár set miliónů, sežere to < 100GB na SSD swapu a za několik hodin dojede v pořádku. Samozřejmě při větším poškození to stejně moc nepomůže, protože co s mraky souborů v adresáři lost+found...

[Lampa]

a jak dlouho to bezi. Jedna se totiz o zalohy mailu pro cca 3000 uzivatelu plna zaloha ma 3TB, inkrement denni je cca 2GB. Posledni xfs_repair trval asi 12 hodin a nic neopravil, swap jako soubor jsem taky zkousel delat, ale nevim jestli tak velky.

Problem je ze pred opravou ten disk sel pripojit, ale ted po oprave uz nejde pripojit

[dustin]

Velikost u nás jsem již psal, běželo to u nás myslím < 12 hodin. Je to backuppc v. 3, které deduplikuje pomocí hardlinků (dnes koule na noze bránící přechodu na ZFS). Pole normální SATA HDD raid10 asi 8 disků, swap na nějakém SSD Intelu přes SATA.

Swap nesmí být na HDD, to je příliš pomalé. Dneska bych již pro xfs_repair swap určitě použil NVMe na PCIe, otázkou je stáří tvého kernelu...

[dustin]

I když dnes to běží v serveru se 128GB RAM, takže by to dal bez swapu. To je mimochodem také cesta, DDR3 ECC paměť je velice levná...

[Lampa]

Jeden ten server je produkcni, takze to nemuzu udelat, ta zatez co to generuje je velka. SSD disky tam jsou, sice namountovane, ale muzu na nich udelat swap, ale jen pres soubor

No uvidime a zkusime to

[dustin]

Pokud je na tom poli více filesystémů a při xfs_repair současně pojede s jinou zátěží, obávám se, že si hodně počkáš.

Swap do souboru je OK, režie filesystému není velká. Jen musí být dostatečně velký, to je jasné.

[luky]

Pokud mate vice volnych disku, udelejte si swap na vsech, kernel je bude pouzivat paralelne.

[Peter Golis]

Nebolo by rýchlejšie to obnoviť zo zálohy?

[dustin]

Offline zálohy záloh, klasika... která bohužel nebývá standardem. Ale třeba výjimka potvrdí pravidlo

[Lampa]

Oni jsou to data, ktere se tak casto nevyuzivaji. Tak se techto dat zaloha nedela (jsou to videa), takze zaloha zaloh neni :)

Jenom me stve, ze se to stava opravdu defacto pravidelne, pokud dojde misto dojde ke zhrouceni filesystemu

[dustin]

Trochu si zareju - možná by šlo zařídit, aby tak často nedocházelo k vyčerpání místa.

[Lampa]

Ano, i to je, ale obcas se stane, ze z nejakeho duvodu nedobehnout zalohy, zustanou viset, ale data se nekopiruji, dalsi zaloha pak sezere vsechno zbyle misto

[lertimir]

Mě to připadá absurdní. Potýkat při současných cenách HDD s místem a riskovat takové průšvihy znamená, že management bud nemá informace (což je vina IT) nebo nemá zájem o bezpečnost dat (pak nemá cenu to řešit.) Levné jsou nejen disky ale i pole. Tohle nejsou pole na který jede kritická databáze, ale záloha a tak něco jako Synology RS3618xs musí stačit. Naskládám tam HGST Ultrastary v 12 TB nebo Seagate Goldy a mám 144 TB hrubé kapacity a když mám málo tak přidám jednu nebo dvě expanzní jednotky po 12 dalších discích. Celá sranda pod 200k a vystaráno na delší dobu.

[Lampa]

Jen jsem kouknul do specifikace, resp co tam meli u produktu napsano:

Podporované systémy souborů	BTRFS,FAT,HFS+,NTFS,ext3,ext4

extx - ne dojdou inody drive nebo pozdeji
NTFS - e-e
HFS+ - s apple fs nemam vubec zadne zkusenosti, nevi jak je na tom s vykonem, zatezi, atd...
FAT - nevhodny
BTRFS - nejsem si jiste jestli je dosti stabilni

Ale to jsou jen moje nazaroy, nexci se ady s nikym hadat. Pouzivam vsude xfs, minimalne ext2-4, ostatni fs vubec, nemel jsem zatim duvod. U techto systemu nejde ani tak o vykon, jako o stabilitu a schopnost nesezrat vsechny sytemove zdroje (pri pripadnem rsyncovani nekolika ruznych cilu)

[Aleš Kapica]

BTRFS - nejsem si jiste jestli je dosti stabilni

Pro některé lidi nebude zřejmě stabilní nikdy. Ale to není můj, nýbrž jejich problém.

[Lampa]

Co se tyce mista, tak to neni tak ze by doslo, cim vice mista bude, tim starsi ty zalohy tam zustanou. Takze je zase riziko ze zase dojde misto.

Z vlastni zkusenosti, koupil se novy server na zalohy, bylo tam dvojnasobek mista, najednou prisel od managementu pozadavek ze budou teda zalohy dvojnasobne dozadu. A hold nekdy se jim to nepodari vysvetlit, ze je potreba aby tam byla nejaka rezerva nebo nedejboze ze nekdo xce explicitne provest full zalohu, protoze dela nejake experimenty pripadne nasazuje novou verzi.

[lertimir]

Tipuji, že záloha je něco jako backuppc, který také má zálohovaný soubor jednou a vše ostatní jsou hardlinky. A z hlediska ext4 a hardlinků, skusil jsi při mkfs vydefinovat pomocí -N počet inodů na nějakou absurní velikost o které víš že nedojde. A z hlediska velikosti a dojítí prostoru, ano jakýkoliv prostor dojde, ale každé normální vedení musí jít přesvědčit, že efektivní hranice zaplnění prostoru je tak kolem 60%, pak je dostatečná rezerva na případné ulety, když něco začne data plnit. A za třetí btrfs stabilní je (pokud nepoužiješ jejich interní RAID5/6)

[msk]

Mne zas pripada absurdne aby sa zrutil fs z toho ze mu doslo miesto.

[lertimir]

Jinak XFS udržuje obrovské množství informací v operační paměti, takže nejen totální zacpání FS ale i tvrdý pád - (odpojení napájení při práci) může dostat FS do neporavitelného stavu (i když v posledních 2 letech se tahle odolnost významně zvedla)

[tomo_tn]

Ano XFS pouziva/ moze pouzivat write cache v RAM, v takomto pripade musite mat UPS pri pocitaci inak stacsi vypadok elektriny a je to v prdeli. Kludne ti vznikne nekonzistencia FS v radoch GB.

Doma mam este staru SGI pracovnu stanicu (O2) a ta ma reset tlacitko dosiahnutelne iba spinkou a musi byt stlacene dlhsiu dobu. Tiez to bolo koli XFS, proste nema rado nekonzistentne stavy. V praxi to fungoalo tak ze OS nabehol - nieje dovod mat subory otvorene inak ako RO, pre aktualnu robotu to vsak (nie vzdy) znamenalo sahnut na zalohu.

Osobne ale XFS roky pouzivam sice iba na domace pouzitie, ale v maximalnej spokojnosti. A priklanam sa k nazoru ze pri cenach HW plakat nad par TB kapacity je pozoruhodne.

[Peter Golis]

Pokiaľ tie dáta neisú zálohované, tak sú v dnešnej dobe bezcenné. SATA disk s kapacitou 3T stojí okolo 100€, a porovnaj si to s človekohodinami ktoré si na tú rekonštrukciu FS už minul.

Ako už bolo povedané, tak by som silno odporučil nadizajnovať dostatočnú diskovú kapacitu, a mať tie dáta aj v inej lokácii ak majú ovšem nejakú cenu pre firmu.

[Adolf Kernel]

odporucam premigrovat z XFS na JFS/ZFS

[dustin]

To se právě s armádou hardlinků dělá dost složitě...

[Lampa]

Proc zrovna tyto dva ? Vim ze nelze pouzit extx fs, proc dojdou inody na. Kdysi jsem pouzival reiserfs, ale ten je ted na tom docela blbe...

Je alokace inodu resena podobne jako u xfs ?

[pavele]

xfs snad neumí omezit max. velikost dat na disku? Nastavit na 80 % a nikdy nedojde k zaplnění disku.

[Lampa]

Nerozumim, jak omezit?

[a1bert]

quota,pquota?

[Andrej]

Čas na souborový systém hodný 21. století, že ano. Tohle téma se tu objevuje stále dokola a začíná to být nuda.

Proč se mořit se zoufalými hardlinky, když může člověk mít atomické snapshoty celých subvolume?

Souborové systémy z minulého století byly skvělé v minulém století. Zmínka o 3 TB a XFS je úsměvná. XFS pochází z dob 3 GB, ne 3 TB, a podle toho je navržený.

[Max]

Tvá úvaha má menší chybku. XFS se hodně vyvíjí a už je v něm myslím implementovaný i CoW. Viz Stratis.
Zdar Max

[Peter Golis]

A už sa vie kedy bude ten Stratis v Linuxe podporovať snapshoty, raid iný ako mirror, TRIM/DISCARD pre Flash Disky a hlavne aj checksumming na dáta? ZoL nemá TRIM/Discard, BTRFS bol odmietnutý RH, a Stratis zatiaľ nevyzerá že by bol vhdný aspoň na testovanie mimo GITu.

Niečo, čo to zvláda a je zdarma je ZFS na BSD. Možno to zvláda aj ReFS, ale ten nie je zdarma a nemám to v pláne kupovať.

[Max]

Stratis je/bude v RHEL8. TRIM umí a snapshoty také. Do jaké míry (na kterých všech vrstvách) mají zvládnutou kontrolu konzistence dat nevím.
Zdar Max
PS: to je ten důvod, proč provozuji v jobu jedno FreeBSD jako ZFS storage.

[ewew]

Link.

[dustin]

Jak souvisí hardlinky na zálohovacím stroji (tedy deduplikace) se snapshoty na zálohovaných strojích, které někde běží a rozhodně je nikdo nebude hromadně přeinstalovávat na jiný filesystém podporující snapshoty?

[Andrej]

Nijak. Proto je čas ty zastaralé zálohovací stroje nastavit tak, aby ve 21. století dávaly smysl.

Hint 1: Hardlink není deduplikace.

Hint 2: Hardlink na úrovni souborů není totéž jako CoW na úrovni jednotlivých bloků.

Hint 3: Hardlinky se týkají nanejvýš jednoho souboru. Subvolume taková omezení nemá, jedním ani druhým směrem, což je pro tazatelův případ celkem podstatné.

[lertimir]

To ale nesouvisí se souborovým systémem pro 21 století. Hardlinky vytváří aplikace na zálohování. Nevím s jakou aplikací to tazatel pracuje, ale např. backuppc provede abc zálohu xy systémů, ale ve výsledku je v zálohovaném prostoru pouze jedna kopie každého unikátního zálohovaného souboru a všechny odkazy v v jednotlivých zálohách jsou hadlinky na tuto jednu kolpii. pokud máš desítky systému desítky záloh a desítky až stovky tisích souborů na systému tak jsi na milionech hardlinků. A potřebuješ filesystem, který ti zálohu uřídí.

[pavele]

No a až zaplní libovolný souborový systém pro 21 století na 100 procent, tak se stane co?

Není jednodušší vyřešit příčinu než nabízet jiný FS?

[Aleš Kapica]

Nejprve to bude valit systém do paměti, než si toho všimneš. Pak je důležité nezmatkovat. Btrfs nabízí několik cest. Na rozdíl od hrůzy typu Ext4.

Je-li Btrfs zaprané až na plný knedlík, tak ti nedovolí nic ani smazat. Ale to se dá ojebat pomocí truncate. Stačí svrknout nějaký větší zbytečný soubor a jsi z pasti fenku.

Jinak ho můžeš remountnout, protože si drží vždycky nějakou rezervu – právě pro tento případ. A pak opět bude možné něco odmazat.

Pokud jsou na tom Btrfs nějaké snapshoty, tak není nic snazšího než jich pár zrušit.

Pokud nemáš co bys zrušil, tak uvolni krapet místa a udělej balancing s rekompresí datových bloků. Jak zjistíš – vždycky se dá nějaké to místo ještě vyždímat. Taky můžeš použít rmlint. A vůbec, klikni si na ten link a máš to všechno naservírované na jednom talíři.

[paul2no]

Proč vlastně btrfs (a asi i jiné CoW filesystémy) potřebují vlastně volmé místo pro smazání souboru? Nad tím jsem přemýšlel a důvod mně nikdy nenapadl.

[Aleš Kapica]

Protože než soubor smaže, potřebuje uložit do logu informaci co se maže.

Pokud jde o rekompresi, potřebuje alespoň tolik místa, aby tam mohl zapsat rekomprimovaný extent.

[alkoholik]

No ty kravo, to chci radsi zpatky do 20.stoleti.

[Max]

To se ti pak jednoduše může stát, že 4TiB volume s ext4 se nějak poškodí a oprava bude trvat dlouho s nejistým výsledkem. A nasazovat něco podobnýho na 40TiB volume bych se neodvážil. Tzn., že produkční systém bude kvůli taková ptákovině nedostupný třeba hodinu i více a FS pro nasazení na větší volume nebude na Linuxu moc k dispozici.
Jinak dnes je situace jiná, než před 15 lety. Na internetu je spousta informací, většinou to co člověk řeší, řešil už někdo před ním a lze hned dohledat řešení. Dále už by default existuje větší obeznámenost a čitelnější dokumentace (různé vymazlené wiki, dostupný bugtracking systém atd.).
Takže osobně nechci zpátky v čase, protože si myslím, že se věci zlepšují, a na více frontách. Dnes už většina moc core věci neřeší, protože všechno funguje by default. Když se teleportneme do doby 15 let zpět, tak vlastní sestavení jádra byla běžná věc a lidi si ho patchovali, aby mohli provozovat ReiserFS.
Zdar Max

[alkoholik]

Kdyz mam plny disk a kvuli smazani par souboru potrebuju sehnat admina, tak je to fs bez prominuti dost na hovno.

[dustin]

Prostě to ještě není dodělané, standardní porodní bolesti. Za pár let to bude jinak.

[Aleš Kapica]

Neumíš číst. Nicméně pokud jako user zasereš disk na 100% tak to znamená, že s vaším adminem nejspíš nebude něco v pořádku.

[lertimir]

Promiň, ale pokud někdo v současnosti, při současných cenách disků, dostupných informacích o chování FS, provozuje jakýkoliv systém tak, že se potýká s rizikem zaplnění FS na 100%, tak je idiot buď on, když neví, co činí, a nebo má ingnorantské šéfy a problémy si zaslouží. Buď on a nebo jeho šéfové.

Mám také disky zaplněné na 99,8%, ale to jsou disky v read-only režimu a když se do nich psalo tak jsem pečlivě zkoumal, jestli to co chci se na ně vleze. Produkční systém nemám nikde více než 75% a když to dosáhne 85% tak už jedou maily a SMS.

[MP]

Spocitej si, za jak dlouho zaplnis 50GB pri 300MBps. Jakou reakcni dobu ma monitorovaci system. Pak pridej reakci admina. Nedopocitas se.

Aneb, pouceni z proxmoxu, jak rozhodit node, ktere ma VM jako file image a ne lvm.

[lertimir]

50GB stojí čistě v HW disku 50Kč, pokud bych připočital diskové pole kolem, redundanci atd. tak budu na 10-20 násobku. Tahkže na 1000Kč max. Pokud někdo pracuje s datovými toky cca 300Mbit/s a má rezervu řádově 50GB dobře mu tak. Psal jsem tady, jak si za řádově 200kKč pořídim 144TB hrubé kapacity. Tedy 72TB v Raid1 což je cena 3Kč za GB. Jaká je hodnota dat, které tím riskuji že o ně přijdu. Jaké je hodiová hodnota práce admina, který se musí šolíchat s tím, aby se mu systém nezmrvil, když pracuje s tak malou rezervou? Jaká je hodnota práce admina, který bude zoufale řešit jak zachránit co se dá, když nastane problém. Pro mne mnohem větší než cena za HW, ve kterém mámmíto abych mohl uklízet. A když někdo jede na hraně kapacit dobře mu tak, ať si to užije (a možná i nechá zaplatit).

[trekker.dk]

Na rozdíl od hrůzy typu Ext4.

...kde je řešením prostě něco smazat.

[alkoholik]

Pst ty heretiku! Oni radeji neco jednodussiho.

[Aleš Kapica]

Příkaz truncate versus idiot. Seznamte se.

[alkoholik]

Na databazove soubory fakt ne..

[Peter Golis]

Ak niekto nepoužíva prealokáciu databázových súborov, tak si za to môže v plnej miere sám.

[trekker.dk]

Je to zajímavé, kolik lidí ochotně hájí systém, který je schopen sám sebe dostat do stavu, ze kterého nelze vybřednout jinak než za pomoci černé magie a usilovného googlení. Přitom by stačilo jednoduše zakázat další zápisy, pokud dochází místo.

[Peter Golis]

To sme sa nerozumeli. Ja nehájim FS ktorý sa dostane do nekonzistentného stavu pri jeho zaplnení. Nezaujíma ma či je táto limitácia len pri jednom FS, alebo či ju zo svojej povahy majú všetky FS s CoW alebo inými vychytávkami kde môže zlyhať oneskorený zápis (clustering, delayed allocation, ...)

Ja zatracujem správcov čo používajú thin provisioning na DB. A to už len kvôli fragmentácii. Možnosť straty transakcií kvôli zaplneniu miesta nie je chybou FS, ale zodpovedá zlému návrhu a absencii monitoringu a údržby. A to jak v prípade DB, tak aj FS.

[lertimir]

Míníš tu situaci, jak tazatel vlákna zaplněním XFS dostane systém do neopravitelného stavu? že by mu měl jednoduše zakázat další zápisy?

[trekker.dk]

To, že filesystém (nebo obecně úložný systém) předejde známým způsobům svého rozbití samozřejmě považuju za oprávněný požadavek na jakýkoliv fs.

[lertimir]

Požadavek to jistě oprávněný je. Na druhou stranu nejsem vývojář filesystému, abych byl schopen uargumentovat, jaká by byla cena za jeho splnění. Pouze si naivně dokážu představovat, že bych při požadavku na zápis musel kontrolovat, jestli už nejsem v situaci, kdy zápisem bych si mohl FS rozbít a tím vytvořit mnohem větší režii.

[tomo_tn]

Panacik XFS bol navrhnuty na superpocitace 3GB casto nebola ani len RAM systemu. Nieto este HDD.

https://en.wikipedia.org/wiki/SGI_Challenge Tieto stroje si ale XFS uzili viac menej okrajovo.

Origin 2000 je trocha ina liga. https://en.wikipedia.org/wiki/SGI_Origin_2000 introduced 1996 -- discontiuned 2002, max RAM 256GB

Samozrejme v kontexte roku 2019 su to uz "len" usmevne stroje. Ked ich ale porovnas s cimkolvek co bolo bezne dostupne v PC svete tak sa javia ako z ineho sveta. Prave navrh XFS bol na masivne paralelne nacitavanie dat z diskovych poli - rotacnych. Pre najnarocnejsich existovala este: https://en.wikipedia.org/wiki/CXFS

Kedze bol mieneny do server segmentu tak sa nejake vypadky elektriny jednoducho nepripustali. UPS + dieselagregat bol standard tam kde to bolo smerovane.

Takze tolko ku tvojim 3GB, najskor by bolo vhodne si o technologii volaco zistit potom tvrdit ako je naprd navrhnuta XFS naozaj nieje FAT16

[Peter Golis]

Tých 256G RAM mohol mať plne naložený Meta Router pre SGI Origin. Takto plne naložený Meta Router mal 64 nodov, každý mal 2xCPU a 16x256M ECC RAM. To dávalo dohromady 256G ECC RAM a 128 CPU.

Nuž, také niečo je stále mimo segmentu PC (Personal Computer). Ak sa mýlim, tak ma skús vyviesť z omylu.

[tomo_tn]

A? Tvrdenie bolo ze XFS je stavane na 3GB disky. Zjavne nieje, bolo navrhnute na masivne paralelne systemy a vysoku priepustnost.

[Peter Golis]

Nuž, masívne paralelné systémy s takými parametrami sú teda naozaj úsmevné stroje. Keby niečo také zvládol segment PC, tak by boli užívatelia v nemom úžase.

[Boban]

Vždyt to dávno umí, pokud teda PC segment chápeme jako x86 architekturu. Letos se těch 128 jader a směšných 256GB RAM vejde do toweru pod stůl. A za zlomek ceny toho SGI starouška.

[Peter Golis]

Poprosím link na motherboard do ktorého dá človek 512 CPU Procesorov a 256G ECC RAM, a aj na tower. Predpokladám že v tom toweri nemáš blade enclosure plne naložené s x86/64 servermi.

[Boban]

Psal jsem letos A psal jsem o 128 core v toweru, ne o 512 core CPU. Ty CPU budou AMD EPYC ROME. A deska bude podobná této: https://www.supermicro.com/Aplus/motherboard/EPYC7000/H11DSi-NT.cfm do které se dá v pohodě 2TB ECC RAM. Jinak tato deska s příslušnými EPYC CPU už dnes tomu stařečkovi výkonem konkuruje a to za cenu pár desítek tisíc dolarů, místo těch starých desítek milionů. A s těmi novými EPYC 2 bude ten výkon značně nad ním. Každý si pak může doma simulovat jadernou bombu jako to dělali na tom SGI.

Ale není třeba vůbec pochybovat, že právě segment PC (a Linux) vyhrál válku o superpočítače. SGI je mrtvé.

[vandrovnik]

RAM asi ano, ale ta procesorová jádra nevím nevím...

Např. https://www.smicro.cz/supermicro-h8qgi-ln4f-14217.html umí 4 procesory po 16 jádrech (a až 1 TB ECC RAM), ale to je pořád jen 64 jader.

[trekker.dk]

EPYC existují i s 32 jádry, pokud teda máte přebytečných 100 tisíc. Akorát jsem pro to nikde neviděl desku se 4 sockety. On by to možná byl trochu problém kvůli rozměrům, ta věc má osmikanálový řadič pamětí, vynásobte čtyřmi a máte v socketech pro procesory a paměti zabraného tolik prostoru, že se na tu desku už nic jiného nevejde.

[Peter Golis]

Ale 32*4 je stále len 128. O tom že Origin 3900 malo 512 CPU a 1T RAM ani nehovorím.

[Max]

Předřečník reagoval na tvojí první poznámku o 128 cpu a 256GB ECC, kdy je již podobná (128xCore a 256GB ECC) konfigurace možná v PC segmentu.
Z toho důvodu nechápu zmínku o 512 core systému s 1TB ram.
Zdar Max

[Peter Golis]

Pretože tomo_tn zatrolil o tom, že ním menovaný superpočítač napchá pod stôl. A z toho bol tento celý thread. Ostatní sa pridali s tým že tiež áno, ale stále nie.

I keď na druhú stranu, moderné smradfóny už zvyknú mať rovnakej cene ako notebooky lepšie parametre. Toľko k porovnávaniu.

[Andrej]

Hahaha. Tak mi dej vědět, až bude XFS mít subvolumes s atomickými snapshoty, vestavěný RAID — tedy skutečný RAID, ne pouze AID s iluzí redundance — a až na něm bude fungovat cp --reflink. Pak se můžeme bavit dál.

[trekker.dk]

vestavěný RAID

Musí i fungovat, nebo stačí takový stav, jaký má btrfs?