Dotaz: BTRFS zkusenosti, rady, upozorneni...

[k3dAR]

Sice obcas ve vlaknech o BTRFS mam ruzne narazky, ale na druhou stranu si uvedomuju ze ten system ma budoucnost a jeho vlastnosti jako COW a (skoro) neomezene moznosti snapshotu jsou vynikajici...
Timto bych rad od lidi co ho pouzivaji, jestli by nenapsali, idealne strucne a bez zbytecne flamewar, sve zkusenosti, postrehy na co si dat pozor, at jiz pozitivni tak negativni...
Ja mam zkusenost jen 1 negativni, ktera dost mozna vznikla tim ze jsem delal konverzi z ext4 na btrfs, chapu ze primej/cistej format by se mohl chovat normalne, ale stejne v to zatim duveru nemam...
Je v blizke budoucnosti ocekavane ze pujde nejak rozumne zjistovat dostupne volne misto? Ze budou opravne nastroje co opravdu opravi a ne ze (jako me) to oznami jen hromadu neopravitelnych corruptu? Ani me popravde tak nezajima subvolumes, bezne pouzivam LVM a s btrfs bych to bezproblemu pouzival dal a rozsiroval/zmensoval oddil klidne pres LV...
Diky :)

Odpovědi

[Want]

Talián to pochopil i při mé massa bob english cca během dvou dnů. Chce to pouze jediné: uvědomit si jak to funguje, podle toho nasadit a vyzkoušet.

K čemu se btrfs z principu nehodí: jako úložiště virtuálních disků.

Naopak znamenitě se hodí pro uložení souborů do kterých se moc nevrtá.

Aby mohlo fungovat dobře, musí mít dostatek fyzického prostoru po kterém může převalovat data.

Aby mohlo fungovat bezpečně, potřebuje víc disků a extenty v raid1 módu.

Pokud se ti objevují chyby je na 99% chyba na straně HW. Btrfs tě na to akorát upozorní dřív než jiný FS.

Pokud jde o zjištění volného místa. Prostuduj help. To že je něco nějak obsazeno, neznamená že s tím nejde ještě něco udělat. Tím nemám na mysli smazání dát, ale využití rekomprese a deduplikace datových extentů.

Není snapshot jako snapshot. Jinak to funguje u LVM a jinak u Btrfs.

[k3dAR]

dik za postrehy, nechci to zatim prave nasazovat abych si to overil v praxi, ale doslo mi ze kdyz uz pisu obcas narazky, ze by me proste zajimali postrehy lidi co to pouzivaji :)
muj problem urcite nebyl problem HW, jak sem psal je mozne ze slo o problem prevodu (nebo mas vice pozitivnich zkusenosti z vice prevodu z ext4?), protoze na danem HW s ext4 pretim, ani potom, nebyl zadnej problem :)
je tedy nebezpecne pouzivat pouze na 1 disku? resp. myslim vice nez treba ext4...
u volneho mista mi slo prave o to co pises, jestli je nejakej naznak ve vyvoji, ze by se mohlo volne misto v budoucnu zjistovat lepe, i za cenu ze by to trvalo dele nez proste "df -h" u ext4, tedy projel by se cely fs a zjistilo by se vyuzita deduplikace, oznamilo by to volne misto, i s tim kolik se da uvolnit (vypadl mi ted ta btrfs funkce/termin, pro "preskupeni/vycisteni/uvolneni_nepotrebneho") :)

[Aleš Kapica]

S ext4 mám pouze ty zkušenosti, že jsem po jeho nakopnutí našel většinu data na hromadě v adresáři lost+found, případně vůbec. Přijde mi, že vzhledem ke své povaze tenhle FS je schopen dlouhodobě skrývat narušená data, aniž by o tom člověk tušil.

Mnohem lepší zkušenost mám s ext3 a proto jsem ho upřednostňoval tam, kde bylo třeba používat soubory s virtuálními disky. Ovšem už delší dobu virtuální disky na lokálním souborovém systému nepoužívám, takže mám všude Btrfs.

Píšeš, že se ti chyby objevily při převodu. Přiznám se, že netuším co tím konkrétně myslíš, Pouhé překopírování souborů z ext4 na btrfs? Tam by k ničemu podobnému vůbec nemělo dojít, pokud nemáš vadnou paměť, která způsobí že se ti spočítá špatný checksum.

Bližší info se objeví zpravidla v tom co vypíše dmesg. Já se setkal pouze s jedním typem chyb, co vznikal právě u těch virtuálních disků tím, že do nich virtuál zapisoval data furt pryč a neseděla pak délka. U virtuálního disku je pouze jediné řešení - přelít ho do jiného souboru.

Na podobnou věc jsem narazil jednou i u logu. Tam to bylo jednoduché - truncate na soubor a pustit scrub. Většinu takových chyb odhalí právě scrub, proto by se měl v pravidelně spouštět. Běží na pozadí, takže nepředstavuje nějaký větší problém. Ty chyby zpravidla nejsou zas tak kritické, pokud zrovna nepotrefí nějaký systémový soubor, nebo zmíněný virtuální disk.

Je-li btrfs v raid1, tak už vůbec nejde o tragédii, protože je v případě systémového souboru k dispozici zdravá replika.

Pak jsem ještě narazil na chyby které způsobovaly odcházející SCSI disky, které občas vracely místo kontrolních součtů blbosti a tím rozbíjely Btrfs v raid6 módu – ovšem to už je delší dobu a byl to pouze test na zapůjčeném hardware, který jsem s díky vrátil a doporučil k věnování největšímu nepříteli vlastníka.

O příkazu df je všeobecně známo, že je pouze orientační a vůbec nic nevypovídá o skutečném objemu dat. To co bys chtěl je v reálu neřešitelné, protože systém nemá k dispozici křištálovou kouli, co by mu řekla kolik místa se uvolní rekompresí stávajících extentů.

Já to řeším tak, že mám by default systém namountovaný bez komprese a kompresi aplikuji, až když je opravdu zle. Druhotným efektem je vyšší výkon, protože se data v reálném čase nekomprimují a také je není nutné dekomprimovat.

Deduplikace je řešením pouze tam, kde se vyskytuje více shodných souborů (prefixy u PlayOnLinuxu např. adresáře pro virtuály, atp.)

[Heron]

Píšeš, že se ti chyby objevily při převodu. Přiznám se, že netuším co tím konkrétně myslíš

Řekl bych, že má na mysli btrfs-convert.

[marbu]

Jak už se tady psalo, btrfs-convert bych moc nedoporučoval v reálu používat. Jednou jsem si s tím hrál a zkoušel konverzi root filesystému z ext4 a na první pohled se zdálo, že je to ok, systém normálně nabootoval a fungoval, ale pak každý pokus o scrub skončil na kernel panic.

[Aleš Kapica]

No já hlavně nevidím jediný rozumný důvod k tomu, proč něco takového vůbec použít.

[k3dAR]

ano, pouzil sem btrfs-convert, z oficialniho baliku btrfs-tools, jak sem psal(a par lidi to zde potvrdilo) chapu ze to mohl byt zdroj problemu co sem mel, na druhou stranu, ten rozumny duvod je prave ten ze je to oficialni nastroj, kdyby slo o 3rd bastl tak chapu ze vhodnost je neni na miste, ale takto? proc to tedy autori btrfs napsali? proc je to soucast dokumentace? proc je to doporucenej nastroj na prevod? samozrejme chapu ze ciste mkfs je neco jineho (navic i s infem od Herona ze vysledek konverze neni ani totozny), ted navic koukam na ofiko wiki ze je tam zminka u prevodu ze prevod pri jadru >4 neni testovan a jsou informace o problemovosti, nicmene o tom me nastroj pred pustenim NEinformoval, i presto ze slo tehdy o posledni verzi a jadro 4.10(11?)...

[marbu]

Řekl bych, že ten nástroj vývojáři vytvořili s tím, že to ze začátku pomůže rozšíření btrfs. Ale bohužel není dnes ve stavu, že by spolehlivě fungoval. A obávám se, že věřit všem možnostem btrfs bez předchozí konzultace btrfs wiki se nemusí ukázat jako opodstatněné. Já jsem ten převod etx4 na btrfs osobně zkoušel hlavně ze zvědavosti, jestli to bude vůbec jěště fungovat a ukázalo se, že můžu potvrdit, co se na té wiki píše.

[k3dAR]

jasne, ja to chapu, reagoval sem na Alesovo "nevidím jediný rozumný důvod", napr. ja za 25let s GNU/Linuxem se nepamatuju FS, pro ktery bych musel studovat Wiki pro pouziti jasne daneho a od tvurcu FS dodaneho nastroje, samozrejme ze sem si prosel "man btrfs-convert" nez to pustil, tam ale zadne upozorneni ze s jadrem >4 to je problematicke nebylo, tim se dostavam k tomu co sem v jinejch vlaknech parkrat zminil, ze k btrfs je (s nadsazkou) potreba vystudovat "Vysokou skolu Btrfsackou", coz i kdyz je brano jako vyhrada, zaroven u BTRFS chapu ze je to proste urcita nutnost (viz treba to nepochopitelne chovani raid1 na 2x HDD pri vypadku jednoho), i proto sem zalozil tohle vlakno, aby se tu setkali ruzne informaci od lidi z praxe :)

[Heron]

samozrejme ze sem si prosel "man btrfs-convert"

V mém man btrfs-convert se hned v úvodu píše:

       btrfs-convert is used to convert existing ext2/3/4 filesystem image to a btrfs
       filesystem in-place. The original filesystem image is accessible subvolume named
       ext2_saved as file image.

           Warning
           If you are going to perform rollback to ext2/3/4, you should not execute btrfs
           balance command on the converted filesystem. This will change the extent layout and
           make btrfs-convert unable to rollback.

       The conversion utilizes free space of the original filesystem. The exact estimate of
       the required space cannot be foretold. The final btrfs metadata might occupy several
       gigabytes on a hundreds-gigabyte filesystem.

       If you decide not to rollback anymore, it is recommended to perform a few more steps to
       transform the btrfs filesystem to a more compact layout. The conversion inherits the
       original data block fragmentation and the metadata blocks are bound to the original
       free space layout.

       Due to different constraints, it’s possible to convert only filesystem that have
       supported data block size (ie. the same that would be valid for mkfs.btrfs). This is
       typically the system page size (4KiB on x86_64 machines).

           Note
           The source filesystem should be clean, you are encouraged to run the fsck tool if
           you’re not sure.

       REMOVE THE ORIGINAL FILESYSTEM METADATA

       By removing the ext2_saved subvolume, all metadata of the original filesystem will be
       removed:

           # btrfs subvolume delete /mnt/ext2_saved

       At this point it’s not possible to do rollback. The filesystem is usable but may be
       impacted by the fragmentation inherited from the original filesystem.

       MAKE FILE DATA MORE CONTIGUOUS

       An optional but recommended step is to run defragmentation on the entire filesystem.
       This will attempt to make file extents more contiguous.

           # btrfs filesystem defrag -v -r -f -t 32M /mnt/btrfs

       Verbose recursive defragmentation (-v, -r), flush data per-file (-f) with target extent
       size 32MiB (-t).

       ATTEMPT TO MAKE BTRFS METADATA MORE COMPACT

       Optional but recommended step.

       The metadata block groups after conversion may be smaller than the default size (256MiB
       or 1GiB). Running a balance will attempt to merge the block groups. This depends on the
       free space layout (and fragmentation) and may fail due to lack of enough work space.
       This is a soft error leaving the filesystem usable but the block group layout may
       remain unchanged.

       Note that balance operation takes a lot of time, please see also btrfs-balance(8).

           # btrfs balance start -m /mnt/btrfs

Tj. bude potřeba hodně místa a nelze to odhadnout dopředu, je dobré provést defrag, nejen pro spojení souborů, ale také pro změnu velikosti extentů a nakonec je dobré provést balance.

Myslím, si, že každého admina asi trkne, že to nebude jednoduchá operace (z hlediska toho, co ty tooly dělají, ne pro admina).

potreba vystudovat "Vysokou skolu Btrfsackou"

To je nutné u všech složitějších systému. Vždycky je dobré vědět, co to umí, co to neumí, jak se věci dělají, aby člověk nebyl překvapen.

[Aleš Kapica]

Ani se mi nechce vzpomínat, kolikrát mě vypekly ony "bezproblémové" ext systémy. K naprosté spokojenosti jsem používal reiserfs, nějaký čas i reiser4 a pokud jde o Btrfs tak jsem žádnou wiki nestudoval, jen jsem si jednu napsal, jelikož informace byly v té době velice kusé.

Nástroj typu btrfs-convert mi přijde principiálně nebezpečný, proto bych ho nikdy nepoužil a nevidím pro to ani ten rozumný důvod.

[Heron]

nebo mas vice pozitivnich zkusenosti z vice prevodu z ext4

Nejlepší převod na jiný typ fs je vytvořit nový fs a zkopírovat data. EXT4 na BTRFS sice konvertovat lze, ale fs, který tímto vznikne, není totožný s fs, který vznikne jako mkfs.btrfs. Ta konverze využívá toho, že ext4 má některé bajty (bloky, nebo jak to říct), rezervované a při konverzi na btrfs toho lze využít. Ale btrfs ukládá data na disk jinak než ext4. Tzn. fs vzniklý konverzí má data stále umístěná stejně jako na ext4 a jen má k tomu dodaná nějaká metadata "jako btrfs". Je to takový kočkopes, který jde možná (po odstranění ext4 subvolume, která tam po konverzi zůstane a teoreticky to lze převést zase zpět) setřepat následným spuštěním balance, ale na to zase musí být dostatek volného místa. Takže, jde to, ale... Nejlepší je prostě nový fs a nahrát tam ta data.

je tedy nebezpecne pouzivat pouze na 1 disku? resp. myslim vice nez treba ext4...

BTRFS má checksumy dat, takže pokud disk vrací špatná data, tak na to btrfs přijde. Ostatní fs (ext4, xfs), mají nově checksumy jen metadat, takže pravděpodobnost nalezení chyby není tak velká.

u volneho mista mi slo prave o to co pises, jestli je nejakej naznak ve vyvoji, ze by se mohlo volne misto v budoucnu zjistovat lepe, i za cenu ze by to trvalo dele nez proste "df -h" u ext4, tedy projel by se cely fs a zjistilo by se vyuzita deduplikace, oznamilo by to volne misto, i s tim kolik se da uvolnit (vypadl mi ted ta btrfs funkce/termin, pro "preskupeni/vycisteni/uvolneni_nepotrebneho")

Aha, takže zjištění volného místa není o volném místu ale o tom, kolik místa se uvolní, když se smažou nějaká data se sdílenými bloky. Netuším, něco šlo zjistit přes quoty (není potřeba žádnou quotu přiřazovat, jen aktivovat, on to oscanuje a něco umí zjistit).

[Josef Kufner]

Ty quoty se po aktivaci přiřadí automaticky a pak se přepočítá zabrané místo.

[k3dAR]

diky, myslel sem si to, navic sem si ted precetl ze to uz ani na jadru >4 autori nedoporucuji, takze pristi pokus s btrfs bude jiste uz jedine ciste mkfs :)

s tim volnym mistem, vychazel sem z toho co sem kde v minulosti zahledl a vzhledem k tomu co cetl jako reakce, tak uvazoval co by se mohlo zmenit, aby to bylo realnejsi, samozrejme ze z praxe to neznam, takze nevim jak kdy proc a co to fakticky zobrazuje/nezobrazuje, ale treba priklad j je jeden z tech co me proste zarazi...

[Heron]

ale treba priklad j je jeden z tech co me proste zarazi...

j používá na vlastní riziko raid5, což je problematický kus kódu a je to na stránkách btrfs wiki jasné napsáno. Na základně toho bych žádné závěry "něco to neukazuje správně" nedělal.

Osobně, při znalosti toho jak btrfs pracuje a ukládá bloky, bych ani funkční raid5 nepoužil.

[j]

2Want: Tady spis jde o to, ze to neumi rict kolik je volnyho mista v ruznych raid rezimech + komprese, a proste ti to reportuje soucet vsech disku, coz je holej nesmysl. Autori se vymlouvaj ze je to slozity, pricemz se po nich defakto jen chce, aby reportovali minimalni dostupny misto. Ze nedokazdou odhadnout jak moc bude fungovat komprese, kdyz si ji zapnes, je pomerne jasny.

[Aleš Kapica]

Já ti nějak nevím. Tohle je někomu málo?:

strojA :~# btrfs fi usage /srv
Overall:
    Device size:                 488.28GiB
    Device allocated:            468.13GiB
    Device unallocated:           20.15GiB
    Device missing:                  0.00B
    Used:                        251.67GiB
    Free (estimated):            209.98GiB      (min: 199.91GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,single: Size:432.01GiB, Used:242.17GiB
   /dev/sdb      432.01GiB

Metadata,DUP: Size:18.00GiB, Used:4.74GiB
   /dev/sdb       36.00GiB

System,DUP: Size:64.00MiB, Used:80.00KiB
   /dev/sdb      128.00MiB

Unallocated:
   /dev/sdb       20.15GiB
strojA :~# btrfs device usage /srv
/dev/sdb, ID: 1
   Device size:           488.28GiB
   Data,single:           432.01GiB
   Metadata,DUP:           36.00GiB
   System,DUP:            128.00MiB
   Unallocated:            20.15GiB

StrojA je virtuál, jehož virtuálním diskem je kontejner v Cephu – proto je také v Btrfs single mode. A strojB je můj notebook se dvěma SSD disky v Btrfs raid1 – o tom, jak jsem na ně přehazoval data jsem tu psal, takže si lze hravě zjistit, jak dlouho to takhle používám.

strojB :~# btrfs fi usage /
Overall:
    Device size:                 465.77GiB
    Device allocated:            465.77GiB
    Device unallocated:            2.11MiB
    Device missing:                  0.00B
    Used:                        419.89GiB
    Free (estimated):             20.78GiB      (min: 20.78GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              430.30MiB      (used: 0.00B)

Data,RAID1: Size:228.85GiB, Used:208.07GiB
   /dev/sda1     228.85GiB
   /dev/sdb1     228.85GiB

Metadata,RAID1: Size:4.00GiB, Used:1.87GiB
   /dev/sda1       4.00GiB
   /dev/sdb1       4.00GiB

System,RAID1: Size:32.00MiB, Used:44.00KiB
   /dev/sda1      32.00MiB
   /dev/sdb1      32.00MiB

Unallocated:
   /dev/sda1       1.05MiB
   /dev/sdb1       1.05MiB
strojB :~# btrfs device usage /
/dev/sda1, ID: 7
   Device size:           232.88GiB
   Device slack:              0.00B
   Data,RAID1:            228.85GiB
   Metadata,RAID1:          4.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.05MiB

/dev/sdb1, ID: 8
   Device size:           232.88GiB
   Device slack:              0.00B
   Data,RAID1:            228.85GiB
   Metadata,RAID1:          4.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             1.05MiB

[j]

Jo, to je nekomu malo ...

Overall:
    Device size:                  21.83TiB
    Device allocated:                0.00B
    Device unallocated:           21.83TiB
    Device missing:                  0.00B
    Used:                            0.00B
    Free (estimated):                0.00B      (min: 8.00EiB)
    Data ratio:                       0.00
    Metadata ratio:                   0.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID5: Size:11.39TiB, Used:11.33TiB
   /dev/mapper/crypt_sda           3.80TiB
   /dev/mapper/crypt_sdb           3.80TiB
   /dev/mapper/crypt_sdc           3.80TiB
   /dev/mapper/crypt_sdd           3.80TiB

Metadata,RAID5: Size:20.62GiB, Used:18.75GiB
   /dev/mapper/crypt_sda           6.88GiB
   /dev/mapper/crypt_sdb           6.88GiB
   /dev/mapper/crypt_sdc           6.88GiB
   /dev/mapper/crypt_sdd           6.88GiB

System,RAID5: Size:96.00MiB, Used:800.00KiB
   /dev/mapper/crypt_sda          32.00MiB
   /dev/mapper/crypt_sdb          32.00MiB
   /dev/mapper/crypt_sdc          32.00MiB
   /dev/mapper/crypt_sdd          32.00MiB

Unallocated:
   /dev/mapper/crypt_sda           1.65TiB
   /dev/mapper/crypt_sdb           1.65TiB
   /dev/mapper/crypt_sdc           1.65TiB
   /dev/mapper/crypt_sdd           1.65TiB

A ted mi rekni, kolik tam je mista ..., a co teprv kdyz to pripojim pres sambu ...

/dev/mapper/crypt_sda 23442082144 12181444056 7174989256  63% /mnt/d

Jo aha, mam hadat, a prepocitavat to podle poctu disku a pak si jeste strelit od boku na aktualni kompresi.

[Aleš Kapica]

No já nevím. Kokunul jsem na to, celkem to zabírá cca 32TiB je to Btrfs raid5, takže každý extent + 2 repliky, tudíž podělit třemi no a máš zabraný prostor (~11TiB), který je třeba odečíst od těch 21,83TiB takže bych to viděl aktuálně na nějakých 10TiB volných. Každopádně to ale vypadá u tebe nějak divně. Nejspíš to bude tím, že tam máš ten btrfs v raid5 který má své mouchy, nebo je to tím že to máš nad nějakým kryptovaným prostorem či co a btrfs tak nemá přístup k některým informacím. Každopádně mi takové použití přijde jako těžká paranioa.

[vandrovnik]

Btrfs dělá raid5 tak, že pro každý extent vytvoří 2 repliky? Normální raid5 by měl fungovat tak, že pro každé dva bloky má třetí paritní, tj. pro uložení 2 TiB dat jsou potřeba 3 TiB místa.

[Aleš Kapica]

Raid u Btrfs není normální raid. Už to tady několikrát zaznělo. Nehrabu se v těch věcech natolik, abych studoval jak to funguje v kódu, ale z čistě empirického hlediska mám pocit, že tomu tak je.

Ostatně, proč ne. Na rozdíl od raidu na úrovni blokových zařízení replikuje Btrfs pouze potřebná data, žádné smetí.

[j]

R56 funguje obdobne jako klasickej R56 - min 3/4 disky, vypadek 1/2 z N a samo to pouziva paritu, ovsem to co si predved vejs je presne to, co ma pocitat FS = vedet kolik ma disku, vedet jak je organizovanej raid a vedet kolik bloku je teda volnych pro data (= v pripade R5 proste odectu 1/N volny kapacity), a to je presne to, co by mel zobrazovat df (coz je presne to cislo, ktery ti potazmo zobrazi samba).

Navic ty disky nemusej bejt stejne velky, klidne muze bejt kazdej jinej = s kalkulackou v ruce pocitat.

BTW 32TB tezko je to 4x 6tka disk = 24 hruby kapacity (respektive tech 21.8). Ve skutecnosti by tam melo bejt +- 5TB volno, ale reportuje to nejakych 6.7TB. A to je presne to, co je proste spatne. Samo, mozna se tam vejde 10TB ... kdyz to bude v textovych souborech ktery se dobre komprimujou. Ale to me celkem nezajima. Me zajima, kolik se tam vejde zarucene.

A samo, cim vic mas mista tim vetsi ten rozdil je. Predstav si R6, a predstav si rekneme 10x 10 disku. Kdyz na nich nic nebude, bude ti to reportovat dostupnych 100TB, ale ve skutecnosti tam bude jen 80TB ...

[Aleš Kapica]

Tvoje starosti na mou hlavu. Spíš bych se pozastavil je-li nezbytně nutné generovat takové kvantum dat.

[k3dAR]

i kdyz jcko casto ulitava na vulgarizmech a casto pise zbytecne demagogicke kraviny, zrovna tady je to presne o cem sem mluvil(/myslel), jestli je nejaka sance (=pracuje se na tom, nebo se to aspon nezamitlo jako zbytecne, tak jako se tvaris ty) ze to btrfs do budoucna zlepsi, ty si doporucoval ze si to muze uzivatel snadno spocitat, chapes tu ironii? proc by to tedy snadno nemohl spocitat automaticky btrfs nastroj pred jeho zobrazenim volneho mista? ;)

[j]

Muzes mi vysvedlit jednu vec? Proc seme teda lezes a plkas takovyhle blaboly kdyz zjevne o veci nevis lautr nic?

[Aleš Kapica]

Byl to jen můj odhad na základě zkušenosti s raid1. Btrfs raid56 jsem zkoušel zhruba před rokem a něco, a bylo to rozbitý podobným způsobem co popisuješ ty. Navíc jsem se podrobněji podíval na to jak to funguje a takové nasazení mi přijde zcela zbytečné.

Jak už jsem napsal jinde a v jiné diskuzi - je to opensource, takže pokud vám něco chybí tak si to doprogramujte, nebo zaplaťte někoho kdo to udělá za vás.

A pokud je u tebe blábol, že je na místě se pozastavit nad tím, je-li nutné generovat velké kvantum dat, tak se nemáme dál o čem bavit. Blbostí je plný net.

[Vantomas]

Neprobíhá na tom filesystému deduplikace? To by mohlo zapříčinit proč to ukazuje víc volného místa.

[Petr]

Takze kdyz tam budu chtit zapsat random data tak mam smulu protoze soudruzi s ndr pocitaji s tim ze jsem normalni a zapisuji jenom zdrojaky? Rikam si ze btrfs a jeho ficury - porad lepsi a lepsi.

[j]

Ale to nema nic spolecnyho s deduplikaci. 4 disky v R5 == 3/4 x pocet volnych bloku je volny misto. Tecka. Jenze system tvrdi, ze tam je 4/4 x pocet bloku. Kdyby to bylo 5 disku je to samo 4/5 atd.

Uplne stejny voloviny to bude samo vypisovat na R1. Tam ti to misto 1/2 bude vypisovat 2/2 ...

Ten dlouhej, btrfs vypis je spravne, ukazuje pocet volnych bloku na jednotlivych discich, ale co je spatne, je to, jak to vnima system a system pouziva df, ktery zobrazi prostej soucet, coz je spatne.

Jinak receno, spatne je to cislo, ktery btrfs predava ven.

A jediny co se kolem toho doctes jsou pindy na tema ze "to je slozity" ... protoze "komprese a sdileni bloku a ...". Jenze to je neco, co nikoho nezajima. Widle ti taky na komprimovanym disku nezobrazujou, kolik se tam (mozna) vejde, ale ukazujou ti, kolik se tam vejde zcela urcite. Ze tam pak nakopirujes GB dat a ubyde jen 1/2GB prostoru je uz vec uplne jina.

Pricemz system jako takovej s tim nic delat nemuze, on nevi jak sou data organizovany, ale btrfs to vi, takze to muze zcela primitivne a trivialne spocitat. A samozrejme ze na takovymhle FS pak proste budes mit fyzickou kapacidu disku trebas 1TB ... ale dat tak muzes mit klidne 100TB ... protoze reflink.

[vandrovnik]

Ona ale situace může být složitější a takhle snadno to většinou dopočítat nepůjde. Budete mít třeba 3 disky o velikostech 4 TB, 1 TB a 1 TB, volné místo na nich dejme tomu 3,5 TB, 0,5 TB a 0,5 TB, raid 5. Podle Vašeho výpočtu by to vycházelo na volné místo (3,5+0,5+0,5)*2/3 = 4,5*2/3 = 3 TB, ale ve skutečnosti to bude méně, protože systém musí garantovat, že data a k nim příslušející paritní info nebudou na stejném zařízení. Jak dělají raid 5, když je těch zařízení třeba 10, to netuším - mám dojem, že i u "normálního" raid 5 jsou různé varianty (buď je vždy jen 1 paritní disk, nebo je třeba 1 paritní na každé 2 datové apod.). Když o tom přemýšlím, nedivím se, že se jim nechce to programovat

[lertimir]

Neblázni. Takhle to nejde mít. Nemůžeš mít RAID5 na ničem jiném než na stejných velikostech. V každém místě (bloku / stripu) musíš mít na X discích x datových bloků/stripů a jeden paritní celkem x+1 stripů. Jinak je to něco jiného než RAID5 (a level 5 na rozdíl od levelu 4 má ten paritní disky pro různé oblasti jiný. Takže v tvém případě mužeš mít RAID5 o velikosti 2TB na dvou 1TB diskcích a na 1TB oddílu z 4TB disku a 3TB bez parity. Když bys měl RAID5 na 10 discích tak je 9 datových a jeden paritní. (s tím obrovkým rizikem, že když disk z pole padne a při rekonstrukci do nového disku se najde ve zbylém poli chyba tak padne celé pole.)

[vandrovnik]

No vymyšlený příklad, co jsem uvedl, je opravdu v reálu k ničemu, byl jen na ukázku, že z volných bloků nejde snadno dopočítat to volné místo. Jak přesně dělá btrfs ten raid5, nevím - jen jsem tady mnohokrát četl, že se vše odehrává po souborech, nikoliv blocích (bylo zmiňováno, když se probíral raid1).

[lertimir]

Ale RAID 1 je něco úplně jiného než RAID 5. V RAID 1 máš zaručeno, že máš dvě kopie dat. Žádná parita nebo něco podobného. Pouze přímé dvě kopie dat. A to pak můžeš dělat buď na blokové rovině (což je klasický případ mdraidu) nebo na souborové rovině, což dělá btrfs. A třeba, když bys měl 3 disky (stejné) btrfs v RAID 1 tak si lehce dokážu představit, že tam budou 3 kategorie souborů. první bude umístěna na disku 1 a zároveň 2, druhá na disku 2 a 3 a třetí na disku 1 a 3. každý soubor bude na dvou místech a celkové kapacita bude 1/2 součtu všech disků. Podobně to dopadne i s nestejně velkými disky, pokud pro ně platí trojúhleníková nerovnost v kapacitě disků tedy a+b>c pro libovoné přiřazení písmen.

[dustin]

To rozhození na různé disky dělá btrfs na úrovni souborů, nebo bloků, ve kterých je soubor uložený?

[lertimir]

Nevím. Jak píšu jinde nepoužívám na něm RAID. To byl jen obecný pohled na základě toho, co jsem ze zdejší diskuse získal. Ae Andrej ti asi odpoví.

[vandrovnik]

Pokud by od všeho měl "originál" plus dvě repliky, tak by to byla spíš obdoba klasického raid1 na třech zařízeních, což asi nebude.

[Peeter]

Proč prostě df nad BTRFS nevrací worst case hodnotu? Lidi by spíš tolerovali, když se jim na zaplněný disk něco vejde, než když to píše 30% free, ale zapsat tam nic nejde.

[j]

Do tohodle stavu se nedostanes, dostanes se do stavu, ze tam posles data ktery se tam vejdou, a pri rekneme 70% prenosu ti to padne nahubu s tim, ze neni misto.

Ono ti to totiz po 100% zaplneni uz bude i realne reportovat 0. 30% z 0 je totiz porad 0.

[Aleš Kapica]

Záleží jaká data se tam posílají, a jestli se s tím diskovým prostorem zároveň něco nedělá.

Typicky takový problém nastává, když se někdo pokouší přesunout nějaký velký soubor (např. image virtuálu), a na disku není tolik místa, aby se tam vešly obě dvě verze. Protože není přesun jako přesun. Ale chápu. Že pro vás to jsou pouhé bláboly, takže nemá cenu nic dál vysvětlovat.

[Jendа]

2x kompletní ztráta dat (corruptnutí FS do stavu, kdy scrub projde bez problému, ale přístup k souboru hodí "corrupt leaf", fsck to zrušil tak, že už to nešlo namountovat vůbec), 1x naražení na to, že RAID-1 ze dvou disků lze v degradovaném režimu namountovat RW jednou a pak už namountování odmítne (totální wtf, je tam prostě čítač, který to pak nedovolí, netuším, co dalšího tomu má bránit), 1x dostání do stavu, kdy před každým mountem byl potřeba zero-log, několikrát vznik souboru, k němuž přístup vrátil I/O error (bez zalogování čehokoli) a rebootem se to spravilo.

Pak takové provozní drobnosti jako že mount trvá minutu nebo že po pár měsících denního používání těch „skoro neomezených snapshotů“ metadata zabrala pár set giga a bylo potřeba udělat balance -musage=25, který na Athlonu X2 a RAID5^* z běžných desktopových disků běžel dva týdny.

Je v blizke budoucnosti ocekavane ze pujde nejak rozumne zjistovat dostupne volne misto?

btrfs fi df mi zatím přišlo v pohodě.

^* trolly, kteří mi začnou říkat, že mám používat RAID5 vestavěný v BTRFS, odkazuji na oficiální status page, kde se píše následující:

RAID56 Unstable write hole still exists, parity not checksummed

[Aleš Kapica]

2x kompletní ztráta dat (corruptnutí FS do stavu, kdy scrub projde bez problému, ale přístup k souboru hodí "corrupt leaf",

Tipoval bych, že tou dobou už byly data dávno v háji, zůstaly jen metadata. Co to bylo za disk – ­SSHD?

1x naražení na to, že RAID-1 ze dvou disků lze v degradovaném režimu namountovat RW jednou a pak už namountování odmítne

Jo. Věřím tomu, že tohle je nepříjemný lapsus, který bych nečekal. Já zatím mrtvý disk za podobné situace nenahrazoval. Btrfs v raid1 jen se dvěma disky mám pouze ve svém notebooku. A když jsem potřeboval přesunout data (druhý disk byl v boxu, takže abych mohl dát nový, tak jsem ho musel nejprve odstranit), tak jsem si vypomohl pomocí loop zařízení.

Pak takové provozní drobnosti jako že mount trvá minutu nebo že po pár měsících denního používání těch „skoro neomezených snapshotů“ metadata zabrala pár set giga a bylo potřeba udělat balance -musage=25, který na Athlonu X2 a RAID5* z běžných desktopových disků běžel dva týdny.

Jo, nikdo nejsme dokonalý. Vytvoření a smazání snapshotu je hračka a trvá opravdu jen chvilku. Bohužel si jen málokdo uvědomí, že to je pouze jedna polovina úkolu. Fyzické odstranění je limitováno možnostmi blokového zařízení, takže pokud jde o pomalý rotační disk a velké množství malých souborů, či nedejbože snapshotů, tak to holt trvá – kór na obstarožním procesoru s malým množstvím paměti.

Je totiž nutné si uvědomit, že při odstraňování snapshotů řeší Btrfs které extenty jsou zbytečné a které se používají u jiných subvolume. Což pochopitelně představuje zátěž na procesor.

Btrfs v raid5(6) v reálném nasazení mi moc smysl nedává. Zvyšuje se tím počet výpočetních operací, a řeší to pouze situaci, že by chcíply dva disky dříve, než se stačí data z toho prvního vyreplikovat na ty disky zbývající.

Přijde mi, že úplně nejlíp se Btrfs cítí když má k dispozici více menších a rychlejších disků, než když má málo disků pomalých a velkých. Z toho důvodu jsem si domů pořídil box na 12x 2,5 palcových disků. Nemají sice obří kapacitu, vyžadují další řadič navíc, ale jsou tišší, míň žerou a pokud by některý z nich chcípnul, tak se mnohem rychleji data zreplikují jinam, protože jich na něm není uloženo moc.

[dustin]

Přijde mi, že úplně nejlíp se Btrfs cítí když má k dispozici více menších a rychlejších disků, než když má málo disků pomalých a velkých.

To platí skoro pro každý raid, ne?

[Aleš Kapica]

Nehovořil jsem o raidu, ale o souborovém systému.

[dustin]

Raid si btrfs vytváří interní, ne? Jak jinak by jeden fs běžel na více discích?

Každý raid má rád co nejvíce menších disků (spindlů), než jen pár velkých oblud.

[Aleš Kapica]

Btrfs si žádný interní raid nevytváří. Není to LVM, ani nadstavba nad MD raidem. Raid tomu začali říkat nejspíš proto, že se tato funkcionalita svými důsledky nasazení raidu podobá. Jinak jde o distribuci extentů takovým způsobem, aby se nestalo že se (v případě raid1) na jednom fyzickém zařízení ocitnou současně oba extenty. V případě raid56 na dvou.

Z hlediska této logiky je tedy jasné, že při použití dvou velkých zařízení to nedopadne dobře, když jedno z nich půjde do kopru a včas se nevymění. Data jsou sice zachována, ale FS nemůže fungovat tak jak má, protože mu k tomu chybí fyzické zařízení. Je-li těch disků více, tak podobná situace nastat nemůže a navíc, jsou-li menší, se v případě výpadku neobnovuje moc dat. Jen takový objem, jaký byl na disku uložen. Opět – čím víc menších disků, tím méně dat na každém z nich.

[dustin]

Princip je stejný - rozdělení jednoho filesystému na více disků současně. Takže platí úplně stejně: více menších disků = větší výkon, rychlejší obnova. Jestli se tomu říká raid nebo bůhvíjak je z tohoto pohledu úplně jedno.

[Aleš Kapica]

Není stejný. U HW i SW raidu na úrovni blokového zařízení se ti replikuje i smetí. U Btrfs ne.

[Josef Kufner]

Právě že ten princip stejný není, jen se to snaží řešit stejný problém.

[dustin]

Ano, problém to řeší rozdělením na více disků. Proto více menších disků = větší rozložení zátěže, větší výkon, rychlejší zasynchronizování. Úplně stejně u btrfs i mdraidu.

Ale je to jedno, každý to chápe...

[j]

Ehm ... tys nikdy R5/6 neprepocitaval ze? Vseobecne se totiz velice nedoporucuje, prave z duvodu rychlosti prepoctu, pouzivat vic nez 5/6 disku v jednom raidu. I pri tomhle poctu muze prepocet trvat klidne nekolik dnu (v zavislosti na provoznim zatizeni). I proto se mimo jiny kazdy trochu normalni pole snazi tyhle situaci predejit, a za vyuziti spare udelat mirror vadnyho disku driv, nez pojde.

Vubec nemluve o tom, ze vic disku == nasobeni poctu zavad a razantni narust pravdepodobnosti, ze pojde vic disku zaroven.

[k3dAR]

na https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices ctu "Btrfs supports raid0, raid1", tak bud to je raid1 (kteremu nevadi vypadek N-1 disku a stale je readwrite) nebo jestli je to neco jako raid1 ale nechova se tak, tak se tomu nema tak rikat aby to nematlo uzivatele, ale treba asraid1 ;)

[Petr]

A kde je tedy ten “limit” pro spravnou velikost disku pro btrfs? Neni 1,44MB floppy moc? U me v praci generujeme o 3800% dat vice nez v roce minulem, tudiz stavet neco na 1tb discich jenom proto ze se z toho btrfs posere nemuzeme. Doma mam narust dat za posledni rok o 30tb, zase je pro me btrfs primarne nevhodne protoze se pri 8tb discich posere pri prvnim problemu?

[Heron]

Velikost disku je nutné brát vzhledem k jeho rychlosti (a tím i tedy času nutného na recovery). Velikost disků roste, rychlost sice taky, ale mnohem pomaleji. 100MB/s uměly i 300GB disky (jistě i menší). Dnešní 4TB disky umí 200MB/s. (+- autobus) Kolik zvládá 8TB disk nevím, ale přes 400MB/s to nebude. Takže je ještě pomalejší (vzhledem ke kapacitě) než ten 4TB disk.

300GB disk se přečte do hodiny. 4TB disk za 5.8h. Jedná se o dolní odhady.

Nehledě na to, že sekvenční rychlost se snižuje, nejrychlejší je na okraji disku, odkud se začíná číst, směrem do středu klesá. Klidně i na 50MB/s. Takže ty časy pro zkopírování celého disku ještě porostou.

Random access je ještě horší. Tam se rychlost disků nemění a spíš klesá. 7200 rpm umí cca 0.5MB/s a umělo to už v době 80MB disků v roce 1998 (s láskou vzpomínám). Dnešní disky s různými rpm (5400, 5900) jsou na tom pochopitelně hůř.

Takže je dobré si stanovit, kolik času na recovery chci a podle toho zvolit velikost a dle kapacity pole i počet disků.

A ne, 1.44MB to fakt není, nejmenší alokační grupa BTRFS je 1GB a je dobré jich tam mít víc než jen jednu.

[j]

Ve finale ti tyhle cisla sou knicemu, pole budes chtit taky vyuzivat provozne. A pak skoncis u jedinyho cisla ktery je opravu zajimavy - pocet IO/s. Zadnej mechanickej disk neda vic nez 200 (neco kolem 180-200 davaj 15k disky). Na kapacite nesejde.

Pochopitelne vetsi disk = delsi doba, ale viz nekde vejs, vic disku = vetsi pravdepodobnost selhani vice disku zaroven.

[Heron]

Pak takové provozní drobnosti jako že mount trvá minutu nebo že po pár měsících denního používání těch „skoro neomezených snapshotů“ metadata zabrala pár set giga a bylo potřeba udělat balance -musage=25, který na Athlonu X2 a RAID5* z běžných desktopových disků běžel dva týdny.

Přiznám se, že při téhle kritice mě vždy napadne zeptat se na to, jak dotyčný řešil ty nekonečné snapshoty před tím.

Protože tady se bavíme o něčem, co na minulých FS udělat vůbec nešlo, protože podporu pro tento typ snapshotů nemá.

Pokud bychom se bavili třeba o LVM, zkoušeli jste někdo co se stane, když tam máte třeba 6 snapshotů? Já jo. Napsal jsem si ansible playbook, který má za úkol aktualizovat OS v několika KVM virtálkách a před tím si udělá LVM snapshot (který se odleje na zálohovací stroj), potom upgrade, testy a nakonec se ten snapshot měl smazat. Měl jsem tam chybu, staré snapshoty se neodstraňovaly a po šestém snapshotu load vyletěl na 200 a všechno čekalo na IO. Nechal jsem to doběhnout, za pár hodin ok. Bez LVM snapshotu úkol na pár desítek sekund.

UFS na FreeBSD snapshoty taky podporuje, ale rovnou v manu je napsáno, že: Every filesystem can have only up to 20 active snapshots. Nezkoušel jsem.

BTRFS fs, který má desítky tisíc snapshotů, prostě funguje. Se žádným jiným fs tohle neuděláte. A to, že mazání trvá, no upřímně řečeno, kdyby ty soubory tam byly skutečně nakopírované (máme k disposici několika PB úložiště a zabráno 0.1%), tak to mazání snad trvá ještě déle.

[Petr]

Tak ja mam na zfs na nekterych poolech snapshoty kazdou hodinu a ze by to nezvladalo jsem nepostrehl...

[Heron]

Tak jasně. Myslel jsem na nativní fs na linuxu. Na ZFS mám taky pár tisíc snapshotů to jede ok. U ZFS bohužel nelze se snapshoty a datasety pracovat tak jak se subvolumy u btrfs. Nelze tam zapisovat a po clone zase původní snapshot a tím ani původní dataset nelze smazat. Není to nezávislé jako u btrfs.

[Vykook]

Myslel jsem na nativní fs na linuxu.

Jako třeba UFS?

[Heron]

Jo, přesně ten, proto je taky ta věta uvedena slovy: UFS na FreeBSD.

[Jendа]

Ano, je pravda, že ostatní řešení na snapshoty, příp. snapshotované zálohování (rdiff-backup), na tom nejsou lépe.

Pokud bychom se bavili třeba o LVM, zkoušeli jste někdo co se stane, když tam máte třeba 6 snapshotů?

Jo, chvíli to jelo a pak mi začali lidi říkat, že je ta Samba najednou nepoužitelně pomalá

[j]

Stejnej problem budes mit s vmwarem a jejich snapshotama, vsude v manualech ti pisou, ze je nemas nechavat dlouhodobe. Kdyz je zapomenes, tak jednak budou giganticky a druhak je budes mazat desitky hodin (diskovy pole s par desitkama tisic IO na fiberu ...).

[Heron]

Ano a vmware občas zařve, že chce provést disk consolidation. Jednou se nám stalo, že po konsolidaci byl disk ve stavu pořízení prvního snapshotu někdy rok a půl nazpět. Ano, nemám rád vmware.

[Max]

Mno, to se mi ještě nestalo, ale vyděsil jsi mně.
Co se mi ale stává je, že konsolidace neproběhne, skončí třeba timeout, nebo to zařve, že soubor je používán jiným procesem. Zálohy jedu ve Veeamu a ten má done.
Občas jsem musel řešit konsolidaci jen v offline režimu (vypnout vm, provést konsolidaci a zase zapnout).
Celkově mi VMWare přijde prapodivný, možná je to tím, že mám menší rezervy ve výkonu, nebo nevím.
Zdar Max

[Heron]

Celkově mi VMWare přijde prapodivný, možná je to tím, že mám menší rezervy ve výkonu, nebo nevím.

Tak vmware je zářným případem toho, o čem jsem psal. Když to funguje, tak ok, ale když se to pokazí, tak je to opravdu důkladně pokažené.

Zažil jsem ještě dobu, kdy vmware vcenter běžel jen na widlích (na nějaké free verzi mssql). Katastrofa. Potom udělali linux verzi, kde to běželo na nějaké free verzi ibm db2. A mělo to limity, jako že max 50 virtuálek apod. (Psal jsem o tom zde.) Dneska už je tam postgresql. Jestli náhodou neexistovala ještě nějaká verze s Oraclem fakt netuším, ale nepřekvapilo by mě to. Nevím, co je přesně důvodem pro tu databázovou turistiku, ale tento styl vývoje mě teda nenaplňuje důvěrou. Spíše to je to do zlaté fólie zabalené hovno. Uvnitř smrad, ale navenek to nesmí být poznat. Něco jako Zimbra. Z venku to vypadá že to funguje, vnitřní implementace je katastrofa.

[j]

Vo tomhle kramu mi ani nemluv, sme to museli dat na samostatny zelezo, prakticky o vykonu jednoho vitualizacniho stroje, aby to vubec nejak fungovalo ... a zaroven aby to nesejmulo vykonostne vsechno, co s tim zrovna sdili HW ...

[Max]

Mno, máš recht, já mám verzi 6.0, plně opatchovanou, a je to líný jak sviň. Chystám se přejít na 6.5, zda se to nezlepší, ale pokud by se to nezlepšilo, tak mi zbyde jen ten webový ksicht, který se nechová stále moc obstojně (občas něco dělám pro jednu fy a ty mají 6.5 Free ESXi a dělá to třeba i ve FF bordel při editaci VM apod.).
Zdar Max

[Heron]

Poslušně hlásím, že ani verze 6.5 na tom není o nic lépe. Pomalé, je nutné dělat rituál s prohlížeči. Nic se nezměnilo.

[j]

Viz Heron, nezlepsi se vubec nic, je to porad stejny. 6.5 mame. Kolega to pravidelne patchuje na vyssi verze s naivni nadeji, ze se neco zmeni. Je to dokonce spis naopak, pravidelne resi, ze to bleje hromadu erroru ... aby se na supportu docet, ze "to je OK, to muzete ignorovat" ... lol.

BTW: Ad snapy, s tema je to jeste vetsi prca, oni maji natvrdo nastavenou v tom svym kontejneru velikost bloku, prej 10MB, takze pokud budes mit 100MB realnych zmen na disku v "sektorech", tak vmware snap bude mit klidanko 10GB+. Uzasny specielne pokud bys to chtel pouzivat pro zalohovani rozdilovych dat. Coz mimochodem presne takhle dela Veam.

[marbu]

Já jsem před pár lety používal lvm thin volumes jako storage backend pro libvirt virtulálky, a míval jsem desítky snapshotů a fungovalo to v pohodě. Akorát to byl dost hack, protože přímo podpora v libvirtu na to nebyla. On je rozdíl mezi LVM1, LVM2 a lvm thin pool snapshoty.

[j]

Me by spis zajimalo, kdo resi minutovej mout. Jo kdyby to bylo 1/2 hodiny, tak to stoji za hovor ... Mam tu HW kde jen post trva dyl nez 1/2 hodiny ... mam tu tiskarnu, ktera startuje 20 minut ... ale minuta?

[Aleš Kapica]

Jednou se mi stalo, že jsem mountoval Btrfs oddíl cca 8 hodin. Pěkně mi z toho lepilo u zadku. Ale nakonec to dopadlo dobře. Bylo na něm jenom cca 10 tisíc snapshotů, které nebyly před restartem úplně odstraněné.

[dustin]

Takže když se z nějakého důvodu restartne server, mohu si třeba pár hodin počkat na mount btrs?

[Heron]

Nevím o co šlo v Alešově případě, ale mě se na počátku hraní s btrfs stalo, že jsem nechal odstranit asi 20tis snapshotů a hned potom jsem chtěl daný stroj vypnout. umount trval, protože čekal na dokončení odstranění snapshotů.

Jako, to je prostě vlastnost. Úplně stejná vlastnost, jako když u db používající binární logy nastavím tyto logy poměrně velké, při vypnutí zvolím fast, tak při opětovném startu ta db začne provádět "recovery" (zapracování) těchto logů do datových souborů. Taky se na to musí čekat. Už jsem čekal i půl hodiny. Případně to může provést při shutdownu, takže se půl hodiny bude čekat na vypnutí.

Už i XFS se nemountuje hned. Zavedli checksumy (metadat), tyto checksumy se kontrolují při každém mountu, takže už jsem si pár minut počkal i na xfs.

Na ZFS mám už asi moc datasetů, takže freebsd při bootu se taky na chvíli zastaví a zobrazuje narůstající počet aktuálně připojených datasetů.

Ale fakt nevím, proč bych to měl řešit.

[marbu]

... odkazuji na oficiální status page, kde se píše ...

Tato status page je asi nejdůležitější odkaz v této diskusi, rozhodně doporučuji projít a zvážit, které vlastosti btrfs chci nasadit a pak si to pořádně vyzkoušet.

[trubicoid2]

... balance -musage=25, který na Athlonu X2 a RAID5^* z běžných desktopových disků běžel dva týdny.

... btrfs fi df mi zatím přišlo v pohodě.

bohužel i obsazené místo se z nějakého důvodu neuvolňuje a je potřeba dělat balance -dusage=xx a to taky trvá strašně dlouho

jak to řešíte ty duasge/musage? v cornu jednou za měsíc?

scrub taky trvá strašne dlouho, nevím proč. stejné disky s mdadm nebo zfs mají scrub několikrát rychleji

trolly, kteří mi začnou říkat, že mám používat RAID5 vestavěný v BTRFS...

tím to není, měl jsem vestavěný RAID5 a bylo to taky pomalé, teď mám vestavěný RAID10, bohužel ta pomalost convert a scrub je to asi vlastností btrfs

[Jendа]

jak to řešíte ty duasge/musage? v cornu jednou za měsíc?

Když se mi zdá, že začalo podivně docházet místo, tak to spustím.

scrub taky trvá strašne dlouho

Mně scrub jede velmi rychle.

[trubicoid2]

scrub done for bla-bla-bla
        scrub started at Sat Oct 14 04:23:45 2017 and finished after 22:17:39
        total bytes scrubbed: 11.33TiB with 0 errors

to mi přijde pomalu, jen 148MB/s, přitom to jsou 4x4TB disky a třeba mdadm jede téměř 500MB/s

[Aleš Kapica]

Tak si používej md raid a neotravuj.

Promiň že jsem tak příkrý, ale už mě vytáčí jak se tady pořád jedni a ti samí lidé točí jak na obrtlíku, aniž by ty jejich plky měly nějakou vypovídací hodnotu. Buď si to mají vyzkoušet a sem přijít až budou mít problém se kterým si neporadí, nebo si mají používat to co jim vyhovuje. Btrfs jim nikdo nevnucuje, ovšem pokud šilhají po jeho výhodách, tak je míč na jejich straně. Já jsem chtěl o tom něco vědět, tak jsem si ty informace co mne zajímaly našel, s některými se i podělil a to mi stačí. Pokud někomu chybí nějaká "fíčura", tak ať si ji doprogramuje. Kód je otevřený. Když jsem s Btrfs začínal, tak ani zdaleka nebyly možnosti pro zjištění informací o datech na něm uložených jaké jsou dnes.

Na vojně platilo jedno heslo: voják se stará, voják má. Tohle ponaučení dnes zřejmě mnoha lidem schází.

[trubicoid2]

no to je dobrá odpověď, fakt :) já dlouho hledám, proč je ten scrub tak pomalej, několikrát pomalejší než madam a také několikrát pomalejší než zfs, což jsem měl předtím

buď mám ten problém jen já, nebo je to ostatním fuk

jen mám trochu obavy, že kdybych dal btrfs nad mdadm, tak bych jednak musel dělat scruby dva a ten scrub btrfs by se ani nemusel nutně zrychlit

[Aleš Kapica]

Mě osobně to je fuk. Běží to na pozadí a pokud mám podezření, že by někde něco snad mohlo blbnout, tak se čas od času nakouknu do dmesgu, jestli se neobjevila nějaká chyba.

[trubicoid2]

no možná scrub i convert všem běží pomale, prostě jsem to srovnal s tím, co jsem měl dřív a když běží scrub téměř den místo osmi hodin tak to skoro nemá cenu pouštět každý týden z cronu

pro zajímavost, jakou máš rychlost scrubu ve srovnání s rychlostí čtení disků? dobrý odhad disku je Extended self-test routine recommended polling time v smartctl -a

[Heron]

Scrub neběží sekvenčně. mdadm může ty disky číst sekvenčně a porovnávat bloky na obou diskách v případě mirroru (nebo celý strip vůči paritě v případě paritních raidů), scrub pracuje s obsazenými bloky a kontroluje jejich chechsumy vůči metadatům, které mohou být na jiném místě disku nebo na jiném zařízení. Smart long test též pracuje sekvenčně (a to navíc přímo na úrovni firmware disku). Toto porovnání nedává vůbec smysl.

Navíc scrub běží na pozadí, není potřeba u toho sedět, takže až doběhne, tak doběhne.

[trubicoid2]

tak to asi bude, proto je to pomalejší

divné je, že zfs scrub jel rychle, srovnatelně s tím sekvenčním čtením, přitom princip je stejný, nějak si přednačte metadata?

jinak jasně, běží na pozadí, ale dělá to prodlevy

[Heron]

O ZFS toho příliš nevím. Četl jsem něco málo o tom, že ZFS je navržen jako hierarchický SLAB (a tuším že snad přímo od autora slab alokátoru pro paměť - ano, podle wiki je tomu tak), takže formát dat na disku bude dost odlišný od formátu jiných fs. Tj. taky důvod, proč ZFS nemá žádné nástroje na realokaci dat na poolu (defrag nebo ekvivalent balance), tedy kromě možnosti ten soubor přeuložit znovu.

[trubicoid2]

Aha, tak teď je mi to jasný, díky. Já myslel, že musím mít něco špatně nastavený, nebo že to je nějaká chyba :)

Ještě jak jsi nakous defragmentaci, já si všiml, že defragmentace bohužel zruší deduplikaci. Tedy po defragmentaci mi dost stoupne zabrané místo. To se myslím neblaze projeví taky na snapshotech. Je tedy asi potřeba po defragmentaci pustit znova deduplikaci, ne? Používám duperemove -drh --hashfile=/var/tmp/root.sqlite /. Ten hashfile se bohužel pokaždé musí mazat, i když je to pak pomalejší. Jinak posledně deduplikované a defragem rozpojené soubory budou ignorovány.

No a co potom ty dlouho trvající balance? To pouštět asi jako poslední? Nemají snad vliv na fragmentaci a deduplikaci bloků? Můj pocit je, že nakonec uklidí volné místo, které se těmi předchozími operacemi zhoršilo.

[Heron]

Ještě jak jsi nakous defragmentaci, já si všiml, že defragmentace bohužel zruší deduplikaci.

No to je celkem logické. Pokud je jeden datový blok součástí více souborů, tak je nemožné všechny soubory defragmentovat a tedy mít všechny bloky všech souborů jako souvislé. Tohle prostě není možné.

Totéž se týká i snapshotů (opět různé souboru sdílejí stejné bloky). Tuším, že se pokusili udělat snapshot aware defrag, tedy aby to spojovalo pouze bloky, které jsou odkazované pouze jednou nebo je celá skupina bloků odkazována stejně z různých souborů, ale jak to dopadlo nevím.

Obecně je hrozně těžké mít fs založený na "poolu bloků", kdy jednotlivé bloky mohou být sdíleny napříč mnoha souboru (a dokonce mít datové bloky různých profilů, tedy nekomprimované, komprimované různými algoritmy) a potom ještě dosahovat defragmentovaných souborů.

No a co potom ty dlouho trvající balance?

Nevím o čem mluvíš. Za normálních okolností se rebalance vůbec pouštět nemusí. Dřív (ale tj tak 3 roky nazpět - sorry, verzi btrfs/jádra si fakt nepamatuju) jsem pouštěl balance s filtrem dusage=0 (tedy balance pouze prázdných bloků). Bylo to z toho důvodu, že btrfs občas neuvolňoval volné alokační skupiny. dusage=0 proběhlo zpravidla velmi rychle. Jenže toto je vyřešeno a dneska se to pouštět nemusí.

Takže na toto bych se teda rovnou vyprdnul, pokud se teda nejedná o nějaký hodně specifický případ použití fs nebo se neřeší nějaký specifický problém.

[trubicoid2]

jasné

ad balance: no třeba teď mám na rootfs na ssd

btrfs fi df /
Data, single: total=24.00GiB, used=17.62GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=2.00GiB, used=459.61MiB
GlobalReserve, single: total=62.77MiB, used=0.00B

je vidět, že je zabráno jakoby 7G dat navíc a 1.5 metadat navíc, když udělám btrfs balance start -dusage=99 / a btrfs balance start -musage=99 /, tak se to zlepší

Data, single: total=18.00GiB, used=17.62GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.00GiB, used=457.23MiB
GlobalReserve, single: total=60.36MiB, used=0.00B

no ale nevím, jestli to není jen o pocitu :) někdy to teda pomůže, když dojde místo

[Heron]

To je jen o pocitu. BTRFS stejně leží na celém daném blokovém zařízení.

balance dělá to, že ty alokační grupy dává blíž k počátku. Krásně je to vidět na případu zmenšení btrsfs. Zmenšení na určitou velikost nedělá nic jiného, než že grupy, které jsou za určitou hranicí (tj novou velikostí fs), přestěhuje k počátku disku. Tj pokud tam žádná data nejsou, tak zmenšení proběhne okamžitě.

Pokud se před zmenšením provede kompletní balance, tak balance všechny grupy setřepe na počátek disku (což samozřejmě trvá) a potom je možné ten fs okamžitě zmenšit až na velikost toho total (+ něco navíc, pochopitelně).

[trubicoid2]

takže se to jen setřepe k začátku? tak to je opravdu zbytečné dělat

a normální systémové df hlasí kterou hodnotu? já měl za to, že ten total a tím convert si vlastně uvolním místo

[Aleš Kapica]

Systémové df dřív vracelo úplné blbosti. Teď už, tedy alespo u mne vrací info o obsazení víceméně správné.

[Vantomas]

Když už se tu rozjíždí tahle diskuse, jak je to s blokováním mezi scrub/balance a vytvoření snapshotu?

Nasadil jsem si btrfs na úložiště s 2x 3TB disk, kde jsem spustil nextcloud, pomocí btrbk tam vytvářím pěti minutové snapshoty, které mají životnost asi 2 dny a pak jsou postupně nahrazovány za týdenní a měsíční. Takhle to provozuji asi rok a na začátku jsem se vykašlal na to, abych dal do cronu scrub/balance. Teď aktuálně jsou ID subvolume 130000 a víc.

Pár týdnů zpátky jsem si říkal, že by bylo fajn začít s údržbou, už přesně nevím zda jsem spustil balance nebo scrub, ale nechal jsem to něco dělat. Druhý den jsem zjistil, že je loadavg asi 150 a v procesech jsem našel visící btrfs procesy vytvářející snapshoty. Procesy jsem sprostě pokilloval, zastavil scrub/balance a počkal asi půl dne, než se to vzpamatovalo. Soubory z filesystému jsem zkusil odkopírovat jinam, zda jsou živé nebo mrtvé a údržbu zase odložil na později. Vše se tváří funkčně a tak to žije svým životem dál.

Teď aktuálně mám v plánu vyhodit z cronu btrbk, spustit balance , který by měl všechny zbytky po starých snapshotech vyčistit a údržbu zautomatizovat. A tak mě tedy zajímá, zda musím řešit, že během scrub/balance musím blokovat btrbk, které vytváří snapshoty nebo to může spolu koexistovat a moje situace vznikla jen díky tomu, že to bylo tak dlouho bez údržby.

[chinook]

Jak to tu čtu, tak nevím jestli do toho jít. Zrovna sestavuji produkční server a chci tam mít BTRFS, má s tím někdo zkušenosti? Nebo mám použít LVM, tak jak to mám na serverech již asi 10let?

[j]

Ja pouzivam ten nestabilni R5 a proste mi to uz par let funguje.

[DIK]

...btrfs používám cca 4-5 let a problémy jsem zaznamenával ze začátku na starších jádrech, resp. starší implementací btrfs. V současné době btrfs provozuji na několika serverech, na solidním hw s dostatkem ram, cpu power a hw raidu 10 a jako backup server a kvm hypervizor, zatím bez problémů... pravda nic kritického. Snapshoty jsou pro backup super, třeba milióny souborů odstraníte okamžitě prostým smazáním snapshotu. (cp -reflink je taky super) Všude mám zaplou lzo kompresy. Podle některých, pokud máte rychlé cpu tak lzo komprese (ne zlib) může zvýšit rychlost, asi kvůli sníženi IO operací na device, nevím, nezaznamenal jsem... Jako distro používám z historických důvodů Centos 7. Dneska bych pro file btrfs server použil ubuntu kvůli modernějšímu kernelu. Jinak rychlost je někde mezi %50 - %80 mé oblíbené ext4, znát to je u virtuálek a databází. Pokud se k btrfs chováte rozumně, necháváte 100-200Gb volného místa, nepoužíváte dedup a sw raid tak se nemáte čeho bát. DIK

[Aleš Kapica]

…nepoužíváte dedup a sw raid tak se nemáte čeho bát.

No, tohle doporučení mi přijde zhruba srovnatelné s doporučením, že pokud si ho před souloží vyhoníte a navíc ukousnete koule, tak se nemusíte bát že partnerka otěhotní.

[DIK]

ok, offline dedup je použitelný, jak je na tom online dedup v současné době netušm, v době kdy mě zajímal jsem nenašel použitelné řešení nebo to btrfs neuměl, už fakt nevím..

btrfs používám protože: - bezproblémová konverze ext4 -> btrfs - použitelný up/down resize partišny, na virtuálky super - fungující add/delete device - komprese (na txt souborech je to opradu znát, třeba maildiry) - použitelné snapshoty mounpointů (peklo s ext4 + lvm fakt nechci) a na úrovní souborů ! (pro backup je kombinace rsync + snapshot výborná) - pro mé úlohy je výkon dostačující, na SSD je to celkem raketa - a samozřejmně btrfs dávám tam kde to má smysl

Sw raid jsem nikdy na linuxu nepoužíval, mám k němu nedůvěru, možná zbytečně...

DIK

[Aleš Kapica]

Nevím jestli si rozumíme. Myslíte softwarový md raid, nebo softwarový raid co dělá Btrfs? Je totiž mezi nimi dost zásadní rozdíl.

[DIK]

oba.... prostě nevěřím, že se sw raid úspěšněji popere se situací, když mu pod rukama klene hardware (neskončí to zátuhem OS) než hw raid, u kterého je IMHO procento úspěšné recovery vyšší. Vycházím z vlasních zkušeností a lidí okolo mě...

[Aleš Kapica]

Tomu se říká blažená nevědomost.

[Heron]

LZO je rychlejší než disk (teda pokud to nejsou nějaké ultrarychlé ssd), takže u komprimovatelných dat zvyšuje propustnost disku. Tj příklad, pokud disk dá 100MB/s, data jsou komprimovatelná na 50%, tak efektivní rychlost je 200MB/s. Jak moc to funguje na obecných datech v praxi nevím, já komprimaci používám pouze u dat, kde se to dá očekávat (maildiry apod.) Na druhou stranu ZFS má LZ4 zapnutou by default. Tam to nechávám a někde extra zapínám gzip-9.

[Heron]

Timto bych rad od lidi co ho pouzivaji, jestli by nenapsali

Zde: https://www.heronovo.cz/category/linux/systemy-souboru/btrfs/

idealne strucne

Tak to se asi nepovedlo

na co si dat pozor

Na chování při výměně disků v případě multidevice. Tj nutnost jít do degraded režimu, tam to pořešit a jít zpět.

Je v blizke budoucnosti ocekavane ze pujde nejak rozumne zjistovat dostupne volne misto?

Nevím, co tím myslíš. Volné místo zjistit jde.

Ze budou opravne nastroje co opravdu opravi a ne ze (jako me) to oznami jen hromadu neopravitelnych corruptu?

Netuším v jakém případě to nastalo. Některé věci opravit nejdou u žádného fs a upozornění je jediná věc, co to může udělat. V případě BTRFS multidevice raid1 ale jde ty soubory přečíst z jiného zařízení, protože btrfs ví, která data jsou v pořádku (na rozdíl třeba od mdadm).

Ani me popravde tak nezajima subvolumes

No to je chyba, protože popravdě btrfs nemá žádný smysl používat jako fs starého typu. Žádné výhody to nepřináší. BTRFS má výhody právě v možnosti udělat si kdykoliv libovolný počet snapshotů subvolume, do těch dále zapisovat, dělat jejich další snapshoty a takto si vytvářet strom různých stavů dat; send / receive apod; libovolné promazávání subvolume bez ohledu na to, z čeho vznikly a co vzniklo z nich.

bezne pouzivam LVM a s btrfs bych to bezproblemu pouzival dal

Kravina. Žádné výhody, jen nevýhody. LVM snapshot není zapisovatelný. Pokud dojde místo na VG, tak snapshot prostě zmizí a není.

[a]

LVM snapshot není zapisovatelný.

LVM snapshot zapisovatelný je. lvm2 samozřejmě.

[Petr]

Ptas se kvuli nasazeni na svuj domaci pocitac kde mas existujici zalohu a nesere te obnovovat data, nebo se ptas kvuli firemnimu storage pro treba 100+ lidi kde downtime je proste nepripustny a stoji ve finale prachy? Kdyz neco nekam nasazuji, doporucuji, vzdy to zkousi, doma (pokud to jde). Btrfs jsem zkousel na svym testovacim linuxovym stroji, mam v nem 8x2tb sata disky. Prvni napad byl raid 6, pak raid 5, pak raid 1. Ve vsech konfiguracich se mi podarilo dostat fs do stavu kdy jsem prisel o data. Ano, nechoval jsem se k tomu slusne, ale to je zivot, nikdy nevis kdy ti selze ramka nebo cpu. Na jednom disku btrfs dela to co ma, i kdyz prace s obrovskym mnozstvim malych souboru je utrpeni. Obdivuji ideu btrfs, ale porad kdyz vidim ruzne faily na netu, tak si rikam ze snad i ext2 byla spolehlivejsi nez btrfs. Moje volba i pro domaci storage byla zfs, jinak na desktopech mam apfs a v praci na storage je zfs, ve virtualech ext4.

[j]

Mno ... a zkousel si stejny veci delat s jinejma FS? Kdyz budu chtit zaridim ztratu dat na libovolnym filesystemu.

[chinook]

Je to bezpečný FS? Na stránkách debianu mají varování:

Compress=lzo might be dangerous.

Quotas and qgroups are still broken and are implicated in filesystem corruption

a pak doporučení:

Do not use compression. That said if one wants to test this functionality then zlib seems to have fewer issues than lzo. Do not use quotas/qgroups.

Zrovna tyto všechny funkce potřebuji a bez ních už pro mě tolik záživné btrfs není.

[lertimir]

Spíše je otázka proč v současnosti kompresi? Cena diskové kapacity je proti ceně procesorové práce výrazně výhodná. Navíc díky kompresi parametry (čas komprese, kompresní poměr) záleží na typu dat a špatně se odhaduje. Navíc většina velkoobjemových dat jako foto video audio mají vlastní účinnější kompresní algoritmy než obecné komprese založené na entropii a ta data se nezmáčknou.

[chinook]

To je asi pravda. Čím dál více přemýšlím, že na mail nechám kompresy a zbytek serverů dám na LVM, které je osvědčené. BTRFs mně podle různých zdrojů přijde nestabilní. Použiji na zálohy, kde více využiji snapshoty.

[Heron]

Může to zvýšit propustnost. Já používám lzo pro přenosy po síti (doma stále jen 1Gbps) navíc s výhodou na SSD, kde trimované bloky vrací samé nuly. Takže lzo je rychlejší než síť a oseká daný image o prázdné bloky (ty se velmi rychle "čtou", pochopitelně dobře komprimují, takže se fakticky na disku přeskakují).

To platí i pro programy, které si místo sparse file vytvářejí skutečné soubory ale (skoro) plné nul. Při použití rychlé komprese se tohle prostě smrskne a žádný čas to nestojí.

A jsou data některých programů, které jsou sice objemná, ale velmi dobře komprimovatelná. (Zdravíme třeba katalog LightRoomu nebo některé savefile u her.)

[trubicoid2]

jak to lzo po siti pouzivas? nejak pri btrfs send nebo treba trubka s lzop

[Heron]

Když třeba potřebuju udělat zálohu ntb. Boot do rescue cd, potom:

cat /dev/sda | pv | lzop | nc server port

na serveru

nc -l -p port > soubor.lzo

(pv proto, abych viděl, kolik už je toho disku přečteno)

Btrfs send posílá jen obsah souborů (+ metadata), takže tam se volné místo do streamu vůbec neposílá. Tam to spíš proženu přes pixz -9 (pokud to teda nespěchá a chci to jen uložit).

[trubicoid2]

aha, dobrý, není lepší použít ssh, to kontroluje integritu, kdežto nc ne, ne? akorát to je asi pomalejší

místo pv jde pak asi použít progress, to pustíš v jiné konzoli

[Heron]

Lze použít cokoliv. nc, připojit si nfs, sambu, sshfs, přímo pipe přes ssh apod.

progress

Pěkné. Neznal jsem.

[trubicoid2]

koukám, že lzop si ukládá checksum, pokud se nevypne -F nebo --no-checksum, takže nc asi nevadí

[lertimir]

Tohle dělám bootem do clonezilly a odesláním obrazu disku na ssh. mužeš použít v ní pigz, což je paralelní gzip na všech jádrech.

[trubicoid2]

pokud nemáš jader víc jak cca 16, tak pigz bude v kompresi pomalejší než jednovláknový lzop/lz4

a v dekompresi je to ještě horší, pigz není paralelní a lzop/lz4 bude mockrát rychlejší

[j]

Pocti si jak to funguje na btrfs (a i jinde) komprimujou se jen soubory, ktere komprimovat lze, ty ktere nelze se nechaji tak. Testuje se to tusim na 1. MB souboru. Kazdej soubor pak ma priznak ze je/neni komprimovanej. Takze pokud na ten disk davas nekomprimovatelny veci, je uplne jedno jestli kompresi zaplou mas nebo ne, protoze se stejne nepouzije.

[Petr]

Pockej, btrfs nekomprimuje bloky ale soubory? Seriozne?

[j]

btrfs funguje (skoro) ve vsem na urovni souboru a ne bloku. Sak to muzes klido mountnout s kompresi a pak bez komprese, nicemu to nevadi. Komprimovany soubory zustanou komprimovany az do ty chvile, kdy je preulozis.

https://btrfs.wiki.kernel.org/index.php/Compression

There is a simple decision logic: if the first portion of data being compressed is not smaller than the original, the compression of the file is disabled -- unless the filesystem is mounted with -o compress-force.

[k3dAR]

dekuji vsem za reakce a omlouvam se za pripadne nereagovani, kazdopadne opravdu diky za vse, vse sem cetl a ulozil do pameti :)
zaroven diky vsem ze se to nezvrhlo v nejakej zbytecnej flamewar, ale v realne technicke informace, ci technickou diskuzi :)

[k3dAR]

jinak pokud by nahodou sel kolem Andrej (ktereho si ac to z naseho "popichovani" casto neni znat) celkem vazim(tedy az na jeho zbytecne narazky na deb distra) a vim ze BTRFS pouziva, jestli by take neprispel s nejakejma poznatkama, zkusenostma z praxe, ci na co si dat poroz :)