Systém souborů Btrfs - práce s vícero zařízeními

30. 1. 2014 | Luboš Doležel | Jaderné noviny | 5773×

Předchozí díly tohoto seriálu byly zaměřené na základy používání Btrfs jako jakéhokoliv jiného systému souborů. Btrfs ale nabízí řadu funkcí, které u alternativ nenajdete; jednou z důležitých věcí je podpora vícero fyzických zařízení současně. Btrfs není jen systém souborů; má i vestavěný mechanismus pro RAID. Tento článek se zaměří na to, jak to funguje a jak toho využít.

Obsah

• Úvod
• Ukázka s prokládáním
• Přidávání a odebírání zařízení
• Další úrovně RAID
• Konverze a obnova
• Závěr

Úvod

Existují dva hlavní důvody, proč byste se měli zajímat o rozprostření jediného systému souborů napříč více fyzickými zařízeními: zvýšená kapacita a větší spolehlivost. V určitých konfiguracích RAID může nabídnout lepší propustnost při některých zátěžích, i když vyšší propustnost bývá u uživatelů až na druhém místě. Pole RAID mohou být nastavena na řadu různých konfigurací („úrovní“), které mezi těmito parametry vyvažují. Btrfs nepodporuje všechny dostupné úrovně RAIDu, ale má podporu pro ty úrovně, které uživatelé používají nejvíce.

RAID 0 („prokládání“) je způsobem, jak spojit více fyzických disků do jedné, větší virtuální jednotky. Čisté implementace stripingu rozprostírají data napříč disky v přesně stanovených „pruzích“ (stripes); kvůli tomu musí mít všechny disky stejnou velikost a celková kapacita je násobkem počtu disků a kapacity jakéhokoliv z nich. Btrfs ale dokáže být o něco flexibilnější – podporuje režim spojování (nazývaný „single“), kde je možné mít disky odlišných velikostí. Teoreticky je možné do RAID 0 nebo pole „single“ spojit libovolné množství disků.

RAID 1 („zrcadlené“) vyměňuje kapacitu za spolehlivost; v poli RAID 1 dva disky (stejné velikosti) obsahují identické kopie všech dat. Selhání jediného disku může zlikvidovat celé pole RAID 0, ale RAID 1 v této situaci neztratí žádná data. RAID 1 budou při intenzivních zápisech pomalejší, jelikož všechna data je nutné zapsat dvakrát, ale mohou být při intenzivním čtení rychlejší, jelikož požadavky na čtení může obsloužit jakýkoliv disk v poli.

RAID 10 je prostá kombinace RAID 0 a RAID 1; alespoň dva páry disků jsou organizovány do dvou nezávislých zrcadlených polí RAID 1; data jsou pak zapisována za použití prokládání napříč těmito páry. (Pozn. red.: linuxový mdraid podporuje RAID 10 i s jediným párem disků.)

RAID 2, RAID 3 a RAID 4 se moc nepoužívají a Btrfs je nepodporuje. O RAID 5 se dá uvažovat jako o sadě disků s prokládáním s dodatečným diskem s paritou (v reálu bývají paritní data rozprostřena přes všechny disky). Pole RAID 5 o N jednotkách má úložnou kapacitu prokládaného pole o N-1 jednotkách, ale může přežít selhání kteréhokoliv jediného disku v poli. RAID 6 má dva paritní disky, čímž se zvyšuje prostor ztracený kvůli blokům s paritou, ale mohou se vám rozbít dva disky beze ztráty dat. RAID 5 musí mít alespoň tři disky, aby to dávalo smysl, zatímco RAID 6 vyžaduje čtyři. RAID 5 i 6 jsou na Btrfs podporovány.

Další zajímavostí je to, že Btrfs umí s metadaty zacházet jinak než s daty. Ztráta metadat může ohrozit celý systém souborů, zatímco ztráta dat souboru má dopad jen na daný soubor – což je sice stále nežádoucí, ale přece lepší. Metadata jsou na Btrfs obvykle ukládána duplicitně, i když se používá jediný disk. Administrátor může explicitně nastavit, jak jsou data a metadata uložena na daném poli a je možné je nastavovat odděleně: data mohou být jednoduše prokládána v režimu RAID 0, zatímco metadata mohou být na tom samém systému souborů uložena režimem RAID 5. A aby to byla ještě větší legrace, tak je tyto parametry možné měnit za běhu.

Ukázka s prokládáním

V minulém díle jsme použili mkfs.btrfs pro vytvoření jednoduchého systému souborů. Rozšířená verze tohoto příkazu pro vytvoření polí o více zařízeních vypadá takto:

mkfs.btrfs -d mode -m mode dev1 dev2 ...

Tento příkaz seskupí daná zařízení do jediného pole a vytvoří na něm systém souborů. Volba -d popisuje, jak se budou data ukládat; může nabývat hodnot single, raid0, raid1, raid10, raid5 nebo raid6. Umístění metadat se zase určuje pomocí -m; mimo hodnot dostupných u volby -d je tu i možnost dup (metadata jsou kdesi na systému souborů uložena dvakrát). Režimy ukládání dat a metadat se nemusejí shodovat.

Jednoduché pole o dvou discích s prokládáním dat byste tedy mohli vytvořit takto:

mkfs.btrfs -d raid0 /dev/sdb1 /dev/sdc1

Zde jsme určili prokládání u dat; výchozí volbou u metadat bude dup. Tento systém souborů připojíme příkazem mount jako obvykle. Jako jednotku obsahující systém souborů můžeme použít /dev/sdb1 i /dev/sdc1; Btrfs si ostatní disky v poli dohledá automaticky.

Příkaz df vypíše jen první jednotku v poli. Systém souborů o dvou discích v režimu RAID 0 s trochou dat by tedy například mohl vypadat takto:

# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       274G   30G  241G  11% /mnt

Více informací je možné získat příkazem btrfs:

root@dt:~# btrfs filesystem show /mnt
Label: none  uuid: 4714fca3-bfcb-4130-ad2f-f560f2e12f8e
    Total devices 2 FS bytes used 27.75GiB
    devid    1 size 136.72GiB used 17.03GiB path /dev/sdb1
    devid    2 size 136.72GiB used 17.01GiB path /dev/sdc1

(Podpříkazy pro btrfs je možné zkracovat, takže by šlo napsat i fi místo filesystem, budeme ale používat celé znění příkazů.) Tento výstup ukazuje, že data jsou rovnoměrně rozdělena mezi dva fyzické disky; celkové spotřebované místo (17 GB na každém disku) lehce překračuje velikost uložených dat. To ukazuje známou vlastnost Btrfs: objem místa uvedený příkazem df určitě neodpovídá objemu dat, který je možné na disk uložit. Zde mimo jiné vidíme vyšší režii kvůli duplikovaným metadatům; jak uvidíte později, odchylka mezi volným místem podle příkazu df a skutečností je u některých dalších režimů ukládání ještě větší.

Přidávání a odebírání zařízení

Jak už to tak bývá, ať už administrátor vytvoří systém souborů jakkoliv velký, časem to bude příliš málo. To je jednou z obecných pravd platných při administraci systémů. S Btrfs je naštěstí snadné takovou situaci řešit; přidání dalšího disku (říkejme mu /dev/sdd1) do výše popsaného pole je jen otázkou:

# btrfs device add /dev/sdd1 /mnt

Toto přidání je možné udělat během používání systému souborů – žádný výpadek se nekoná. Vypsání stavu změněného systému souborů odhalí následující:

# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       411G   30G  361G   8% /mnt

# btrfs filesystem show /mnt
Label: none  uuid: 4714fca3-bfcb-4130-ad2f-f560f2e12f8e
    Total devices 3 FS bytes used 27.75GiB
    devid    1 size 136.72GiB used 17.03GiB path /dev/sdb1
    devid    2 size 136.72GiB used 17.01GiB path /dev/sdc1
    devid    3 size 136.72GiB used 0.00 path /dev/sdd1

Systém souborů byl rozšířen o nové volné místo, ale na nové jednotce není žádné spotřebované místo. Proto se akuálně nedá mluvit o prokládaném systému souborů, i když nemusí být snadné to poznat. Nová data budou zapsaná na systém souborů budou rozprostřena přes všechny tři disky, takže zabrané místo nadále nebude vyvážené, pokud nezasáhneme. Pro vyvážení systému souborů je nutné spustit:

# btrfs balance start -d -m /mnt
Done, had to relocate 23 out of 23 chunks

Použité volby říkají, že se napříč polem mají vyvážit data i metadata. Vyvažování představuje přesouvání velkého množství dat mezi jednotkami, takže může chvíli trvat; zpomalí také přístup k systému souborů. Máte k dispozici podpříkazy pro pozastavení, pokračování a zrušení operace, pokud by to bylo potřeba. Jakmile je operace hotová, pohled na systém souborů vypadá trochu jinak:

# btrfs filesystem show /mnt
Label: none  uuid: 4714fca3-bfcb-4130-ad2f-f560f2e12f8e
    Total devices 3 FS bytes used 27.78GiB
    devid    1 size 136.72GiB used 10.03GiB path /dev/sdb1
    devid    2 size 136.72GiB used 10.03GiB path /dev/sdc1
    devid    3 size 136.72GiB used 11.00GiB path /dev/sdd1

Data nyní byla vyvážena (přibližně) rovnoměrně napříč všemi třemi disky v poli.

Zařízení je možné z pole odstranit příkazem jako:

# btrfs device delete /dev/sdb1 /mnt

Než je možné zařízení opravdu odstranit, tak je samozřejmě nezbytné přesunout všechna data uložená na tomto zařízení. Proto i provedení tohoto příkazu může trvat dlouho; na rozdíl od příkazu balance neumožňuje device delete operaci pozastavit nebo opětovně spustit. Samozřejmě platí, že příkaz neuspěje, pokud na zbylých discích není dostatek místa, kam by se vešla data z odstraňovaného disku. Operace selže i tehdy, pokud by odstranění disku znamenalo, že v poli bude méně disků, než je pro danou úroveň RAID nutné; kupříkladu nejde udělat to, že by v systému souborů RAID 0 zůstal jediný disk.

Pamatujte, že z pole je možné odebrat libovolný disk; žádný z disků nemá roli „primárního“. Proto je možné pomocí operací add a delete kompletně přesunout systém souborů Btrfs na jiné disky, a to bez výpadku.

Další úrovně RAID

Správa jiných úrovní RAID je podobná RAID 0. Pro vytvoření zrcadleného pole by například šlo spustit:

mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1

Při tomto nastavení budou data i metadata zrcadlena napříč oběma disky. Pro pole RAID 1 jsou nutné právě dva disky; tato pole mohou v podání nástrojů jako df opět vypadat zvláštně:

# du -sh /mnt
28G	    /mnt

# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       280G   56G  215G  21% /mnt

Zde df ukazuje 56 GB zabraného místa, zatímco du přísahá, že uložena je tam jen polovina dat. Vypsaná velikost systému souborů je také špatně, a to kvůli tomu, že ukazuje celkové volné místo bez ohledu na to, že každý blok bude zapsán dvakrát; kdokoliv, kdo se do systému souborů pokusí uložit takové množství dat, bude těžce zklamán. Podrobné a správné informace vám opět podá:

# btrfs filesystem show /mnt
Label: none  uuid: e7e9d7bd-5151-45ab-96c9-e748e2c3ee3b
    Total devices 2 FS bytes used 27.76GiB
    devid    1 size 136.72GiB used 30.03GiB path /dev/sdb1
    devid    2 size 142.31GiB used 30.01GiB path /dev/sdc1

Zde vidíme, že na každém z disků jsou uložena všechna data (plus nějaká ta režie).

Pole RAID 10 se dá vytvořit pomocí profilu raid10; tento typ pole vyžaduje sudý počet disků, a to alespoň čtyři. Zařízení je možné do aktivního pole RAID 10 přidávat – nebo odebírat – ale jen po párech. Pole RAID 5 lze vytvářet z libovolného množství disků, pokud jsou alespoň tři; RAID 6 vyžaduje disky alespoň čtyři. I u těchto polí je možné jednotky přidávat a odebírat za běhu.

Konverze a obnova

Představte si, že máme pole RAID 0 o třech discích a máme na něm trochu dat:

# mkfs.btrfs -d raid0 -m raid0 /dev/sdb1 /dev/sdc1 /dev/sdd1
# mount /dev/sdb1 /mnt
# cp -r /random-data /mnt

V tento moment může pole vypadat následovně:

# btrfs filesystem show /mnt
Label: none  uuid: 6ca4e92a-566b-486c-a3ce-943700684bea
    Total devices 3 FS bytes used 6.57GiB
    devid    1 size 136.72GiB used 4.02GiB path /dev/sdb1
    devid    2 size 136.72GiB used 4.00GiB path /dev/sdc1
    devid    3 size 136.72GiB used 4.00GiB path /dev/sdd1

Po vcelku obvyklém selhání disku dospěje administrátor k názoru, že redundance má přece jen smysl a že by tedy bylo mnohem hezčí, kdyby výše popsané pole používalo RAID 5. Bylo by pochopitelně možné pole odzálohovat, vytvořit nový systém souborů v režimu RAID 5 a nakopírovat zpět původní obsah. Toho samého ale lze docílit i bez výpadku provedením konverze za běhu:

# btrfs balance start -dconvert=raid5 -mconvert=raid5 /mnt

(Stránka o filtrech balance na wiki Btrfs a tento popis změny v patchi vám toho o příkazu balance povědí více než manuálová stránka btrfs.) Tato operace zase může trvat dlouho; dojde během ní k přesunu velkého objemu dat mezi disky a k vytváření kontrolních součtů pro všechna data. Až to všechno doběhne, tak bude administrátor mít pěkně vyvážené pole RAID, aniž by kdy musel systém souborů odpojit:

# btrfs filesystem show /mnt
Label: none  uuid: 6ca4e92a-566b-486c-a3ce-943700684bea
    Total devices 3 FS bytes used 9.32GiB
    devid    1 size 136.72GiB used 7.06GiB path /dev/sdb1
    devid    2 size 136.72GiB used 7.06GiB path /dev/sdc1
    devid    3 size 136.72GiB used 7.06GiB path /dev/sdd1

Souhrnná spotřeba místa se zvětšila kvůli přidání paritních bloků, ale uživatelé by jinak neměli převod na RAID zaznamenat. Redundantní konfigurace pochopitelně nezabrání selhání disků, ale umožní, aby takové situace byly řešeny s minimem obtíží. Představme si, že /dev/sdc1 ve výše uvedeném poli začne vykazovat známky selhání. Má-li administrátor k dispozici náhradní disk (říkejme mu /dev/sde1), tak je možné disky v poli prohodit pomocí příkazu:

btrfs replace start /dev/sdc1 /dev/sde1 /mnt

Pokud by to bylo nutné, tak můžeme zabránit čtení z odebíraného disku použitím volby -r, ale jen za předpokladu, že to tak jde udělat. Operaci nahrazování lze zrušit, ale ne pozastavit. Jakmile je operace hotová, /dev/sdc1 už nebude součástí pole a můžeme se jej zbavit.

Jestliže disk selže úplně, pak může být nutné pole připojit v degradovaném režimu (s volbou -o degraded). Mrtvý disk pak můžeme odstranit takto:

btrfs device delete missing /mnt

Slovo missing zde zastupuje disk, který by měl být součástí pole, ale aktuálně není přítomen. Náhradní disk pak jde přidat pomocí btrfs device add, po kterém by asi měla následovat operace vyvážení.

Závěr

Podpora vícero disků byla součástí návrhu Btrfs od samého počátku a související kód je v hlavní řadě ve stabilní podobě už nějakou tu dobu. Největší výjimkou jsou RAID 5 a 6, který byly začleněny do verze 3.9. Ohledně těchto úrovní se nevyskytlo příliš mnoho potíží, ale faktem zůstává, že daný kód je stále ještě mladý a mohou v něm číhat překvapení, na která uživatelé ještě nenarazili.

Vestavěná podpora pro pole RAID je jednou z klíčových funkcí v Btrfs, ale zde výčet pokročilých schopností Btrfs určitě nekončí. Dalšími z hlavních předností Btrfs jsou podjednotky a snapshoty; na ty se podíváme zase někdy jindy.

       

Komentáře

[petr_p]

V citovaných výstupech btrfs filesystem show není vidět, jaká úroveň pole se používá. Jakým příkazem se člověk dozví, jak jsou uspořádána data a metadata?

[Suchý čert]

# btrfs filesystem df /
Data, RAID0: total=1.31TiB, used=1.00TiB
Data, single: total=8.00MiB, used=7.25MiB
System, RAID0: total=16.00MiB, used=96.00KiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, RAID0: total=28.00GiB, used=5.25GiB
Metadata, single: total=8.00MiB, used=504.00KiB

[Aleš Kapica]

Použije příkaz

btrfs fi df /mount_point

[Filip Jirsák]

Předpokládám, že v případě RAID 5 je tedy možné s Btrfs úložnou kapacitu rozšířit pouhým přidáním disku do pole. Bude pak Btrfs postupně balancovat při běžných zápisech, nebo je vhodné i v případě RAID 5 přebalancovat data manuálně? Jde mi o to, zda při přidání 4. disku Btrfs zjistí, že má na disku 4 spoustu volného místa a bude nové věci zapisovat postupně na disky 1+4, 2+4, 3+4. Nebo bude pořád pravidelně střídat disky a zapisovat postupně na 1+2, 2+3, 3+4, 4+1?

[Kuba]

... Jde mi o to, zda při přidání 4. disku Btrfs zjistí, že má na disku 4 spoustu volného místa a bude nové věci zapisovat postupně na disky 1+4, 2+4, 3+4. Nebo bude pořád pravidelně střídat disky a zapisovat postupně na 1+2, 2+3, 3+4, 4+1?

Ahoj, sice nevim jestli to Btrfs bude delat automaticky jako mdadm ale nejak mi nesedej tvoje pocty pro ukladani dat u RAID5. Pokud neziju spoustu let v bludu, tak RAID5 by mel ukladat data zpusobem: 1,2,3 + 4 checksum (samoopravny kod) 2,3,4 + 1 checksum 3,4,1 + 2 checksum 4,1,2 + 3 checksum

viz.: http://cs.wikipedia.org/wiki/RAID#RAID_5

Nebo jeste spim a nechapu o cem se bavime

[Filip Jirsák]

Při zápisu na RAID5 se vždy zapisuje na dva disky do stejných sektorů najednou (pokud uvažuju triviální implementaci se stejně velkými disky) – do jednoho se zapíšou data, do druhého se zapíše XOR ze stejných sektorů ze všech disků. Data jsou sice zapsaná, jak píšete, ale zapisuje se jen na dva disky, z ostatních se při zápisu toho jednoho sektoru jen čte. Můj dotaz byl, zda se výběr toho, které budou ty dva disky, pravidelně střídají (což je třeba případ triviální implementace, kdy disk s kontrolním součtem je určen jako číslo sektoru mod počet disků – pak se při přidání nového disku musí vše přepočítat), nebo zda se při výběru kandidátů pro zápis upřednostňuje prázdný disk.

[Aleš Kapica]

Podle mých testů pouhé přidání disku nestačí. Vždy by měl za ním následovat balancing. V případě většího než minimálního počtu disků bych ho spustil pro jistotu i po vyhození disku.

[Filip Jirsák]

V případě častého zapisování ani ten balancing není potřeba, ne? Tím, že Btrfs používá COW, měl by po obrátce dat shodné s kapacitou pole být souborový systém vybalancovaný sám od sebe. Nebo je Btrfs po přidání disku v nějakém „degradovaném“ režimu a manuální balancování to pročistí? Jde mi o to, zda balancování dělá jen optimalizaci a nebalancovaný souborový systém je pro Btrfs normální provozní stav.

[jiri.one]

Myslíte si, že pro potřeby domácího NAS je lepší použít Btrfs raid0 případně single nebo spojovat oddíly pomocí LVM?

[Aleš Kapica]

Pro potřeby domácího NAS neuvažuj o nižší volbě než raid1.

[jiri.one]

Řeším si zálohy a o raid1 v žádném případě neuvažuju a ani tam moje otázka nesměřovala. Jde mi opravdu o porovnání LVM vs Btrfs raid 0 - výhody, nevýhody, výkon, ...

[Program]

Zálohy na RAID0? Výhody, nevýhody? To je jedno, stejně přijdeš o data...

[martin]

Vzhledem k tomu, že btrfs obsahuje jak filesystém tak RAID v jedné vrstvě, mělo by být při použití RAID volby single pro data a raid1 pro metadata na více discích různé kapacity možné dosáhnout toho, že při výpadku jednoho disku sice přijdeme o data na něm, ale zbytek dat a celý FS to přežije bez úhony. Takový scénář se může hodit na skladování hromady nedůležitých dat. Zkoušel to někdo?

[trubicoid2]

prej to balance jde pouzit i na jednom jedinym zarizeni, vi nekdo co to dela? neco s metadatama? nebo s volnym mistem?

[little.owl]

FAQ rika, ze jeden side effect je:

If there is a lot of allocated but unused data or metadata chunks, a balance may reclaim some of that allocated space. This is the main reason for running a balance on a single-device filesystem.

Prakticky jsem ale zadny benefit nepozoroval.

[Aleš Kapica]

O tom k čemu je dobrý balancing u Btrfs. Holt nezbývá než se opakovat.

• Je-li na zařízení alokováno hodně extentů, které jsou jinak poměrně nevyužité, lze jejich zpřeházením scelit volné místo, neboť během vyvažování dojde k efektivnějšímu uložení dat a metadat
• Na souborovém systému, který je nad blokovým zařízením u kterého došlo k chybě při replikaci (např. u RAID-1 kde umřel disk) to donutí souborový systém obnovit ztracenou kopii z metadat na aktuálně aktivním zařízení.

První bod by bylo možné uvést také pod jeden z předchozích příspěvků. Btrfs se samo od sebe nikdy nezoptimalizuje, ani neopraví, ale to ostatně ani klasický SW RAID. I ten vyžaduje nějaké skripty.

[little.owl]

Slo o benefit pouziti balance nad jednim diskem.

[Aleš Kapica]

První bod nebyl dostatečně jasný? Jinak balance umožňuje také konverzi extentu, tj. změnu typu Btrfs FS.

[little.owl]

Me by spise zajimalo co se snazite rozporovat na mem puvodnim prispevku.

[Aleš Kapica]

Ono mělo být účelem něco rozporovat? Tím, opakováním jsem měl na mysli pouze zkopírování textu, který jsem měl na wiki sem. Kdyby se původní tazatel obtěžoval trochu hledat, tak by se z té wiki dozvěděl k čemu je to dobré dřív, než otázku položil.

[little.owl]

Odpovidal jste mne, jinak diky za onen cesky odkaz, je to dobre zpracovane.

[little.owl]

Je tedy btrfs jiz production ready?

[Käyttäjä 11133]

Myslíš production at home, nebo production in enterprise? :)

[little.owl]

No, pokud prijde o data zamestnavatel, tak to je blbe, pokud ale ja doma, tak to je pr**er; z toho - pokud je to pouzitelne in enterprise, mozna, pripadne, bych to mohl pouzit i doma. Tedy?

[Vykook]

Prostě použij ZFS...

[Aleš Kapica]

ZFS je pro použití v linuxu z dlouhodobého hlediska mrkev. Pokud by se stalo součástí systemrescuecd, tak by se o něm dalo alespoň uvažovat.

[Max]

Já to nasadil na backup server s 16TB extermním polem. Předtím jsem to testoval na Debianu na 1TB poli a krom jedné chybky (nešli mazat snapshoty), kterou opravili v novější aktualizaci debian kernelu, jsem na nic nenarazil. Přežil jsem bez problémů i s full sežraným místem na hdd apod.
Používal jsem však jen k zálohám, tzn. rsync + snapshoty, nic víc jsem s btrfs neřešil.
Zdar Max

[little.owl]

Temporary scratch uloziste, btrfs, 4*3TB, raid10, OpenSUSE 13.1, uvidime za jak dlouho se to sesype.

[ZiGi]

ja btrfs pouzivam uz nejake dva roky na niekolkych notebookoch, sice iba ako single-disk ale zato aj s compresiou. Bol som velmi prijemne prekvapeny, ze aj ked sa sirili reci, ako chybaju nastroje na opravu, po zlyhani disku nebol probroblem vacsinu dat zachranit pomocou btrfs restore.

[xxxs]

dobre fungujuci fsck proti restore a vykopirovaniu dat na iny disk. to radsej zamakat ja na fsck, nie?

[Andrej]

Já ho používám od roku 2010 na všech svých strojích a takovéhle otázky mě vždycky náramně pobaví.

[little.owl]

Me taky pobavilo, kdyz spusteni defragment a balance najednou sestrelilo cele btrfs.