Nekorektní chování BTRFS

[Petr Branik]

BTW ZFS to samy, nad 80% jde vykon dolu.
Mam podezreni, ze i kdybych mel 1 PTB a zbyvalo by 200 TB, stejne to bude kvicet a zacne to zpomalovat.

Koupil jsem si 14TB, chci si tam ulozit 14TB !

Ja tohle zkousel a u takhle velkych poli je to lepsi nez 80%.

[Reklama]

[RDa]

Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.

Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.

FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.

[Trident Vasco]

Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.

Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.

FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.

U ZFS dochazi pouze ke zpomaleni. U jakkehokoliv CoW filesystemu stejne musite kolem tech 90% nejak resit. Daji se nastavit quoty (ktere jsou skutecne hard) nebo zvol volumy s definovanou velikosti kde dostanete jako uzivatel natvrdo pres tlamu. Jako co ocekavate od COW filesystemu? Muzete si hrat s recordsize,logbias nebo resit kompresi na potlaceni efektu. To je ale asi tak vsechno protoze CoW tady nejde vypnout.
Je to jako kdyz nekdo chce jezdit F1 s tirakem. Kazda vec ma sve pouziti a sve specificke zpusoby ovladani. Pokud nemuzu zajistit nejaky buffer na FS na operace tak holt jak uz je tu zmineno asi mam spatny FS a pouziji jiny.
ZFS je FS primarne pro storage ktery si mate dale efektivne nasekat a spravovat tak aby se nedosahlo limitu. Na storagich se obvykle dostavate do uzkych pokud mate zaplnenost nad nejakou definovanou hodnotu prestanou fungovat urcite vyrobcem standartne podporovane akce.
U Btrfs to tez nebude jine, i kdyz lze narozdil od ZFS CoW kompletne vypnout pres nodatacow.

BTW: Prispevky tohoto typu tu ma clovek tak alespon 2x rocne. Proc mi jde ZFS na raspberry pi tak pomalu. Neco ve smyslu: Kdyz jsem si tam pridal nad to mdraid a mam pod tim i lvm2 tak je to horsi. Reseni neni drbat nevhodnou technologii az do krajnich mezi. Reseni je pouzit ji vhodnym zpusobem nebo vymenit.

[RDa]

Spis nez nodatacow v terminalni fazi bych zmenil a degradoval RAID level z 6 napr. na 5, pro data ktera nejsou vyslovene kriticka (a clovek ma beztak kopii v zaloze), coz je jednodussi, nez pridavat dalsi disk a provest rebalance (to by byla volba, pokud by HW mel volne pozice.. nema, takze nemuzu jednoduse provest ani upgrade na vetsi disky jako replace po jednom, zachodu).

Ale tohle u BTRFS nejde ta zmena udelat per-adresar nebo per-subvolume bohuzel. To ZFS to je myslim lepsi, ne?

[Trident Vasco]

Spis nez nodatacow v terminalni fazi bych zmenil a degradoval RAID level z 6 napr. na 5, pro data ktera nejsou vyslovene kriticka (a clovek ma beztak kopii v zaloze), coz je jednodussi, nez pridavat dalsi disk a provest rebalance (to by byla volba, pokud by HW mel volne pozice.. nema, takze nemuzu jednoduse provest ani upgrade na vetsi disky jako replace po jednom, zachodu).

Ale tohle u BTRFS nejde ta zmena udelat per-adresar nebo per-subvolume bohuzel. To ZFS to je myslim lepsi, ne?

Ne ZFS je na tom stejne ne-li hur. Treba u raidz je treba proste pri nove strukture vyrobit novy pool. U OpenZFS tusim 2.2 uz je k dispozici experimentalni funkce na rozsireni poolu.
Odebrani z poolu -> "RAIDZ Remove" nejde, neni ani v experimentalni fazi a v nejblizsi dobe se teprv zazne s implementaci. A jelikoz se tu nejedna o startup frikuliny tak implementace mozna zacne az v nasledujicich letech.
Remove/add lze v pohode jen u mirroru a add u stripe
Nebo se placnete pres kapsu a koupite si treba SitApp :-) Pripadne zcela zmenite vrstu nad ZFS a pouzijete ho jen jako node backend pro distribuovany fs.

[Reklama]

[Tomáš Crhonek]

Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.

[RDa]

Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.

84TB pole hlasilo 129 GB volneho mista.. chtel jsem ulozit jedno PDF... urcite nemelo 129GB ale spis 129KB. A o to me slo - ze nejen ze hlasene informace o volnem miste byla zcela neodpovidajici, ale dopadlo to kernel panicem (nastesti resitelnym, skrze par obskurnich prikazu a restartovanim NFS).

Po rebalance a manualnim "garbage collectingu" se to umoudrilo.

Z jakeho duvodu by mel clovek neverit volnemu mistu v DF prikazu? To popira zaklady logiky.. vidim volno, chci ho vyuzit.

Apropo - uz jsem Tomasi poslal ty disky co lidi od vas nakoupili?

[LolPhirae]

Tedy měl jsem za to, že nepoužitelnost údajů z df je tak nějak obecně známá u souborových systémů typu zfs a btrfs...

[Trident Vasco]

Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.

84TB pole hlasilo 129 GB volneho mista.. chtel jsem ulozit jedno PDF... urcite nemelo 129GB ale spis 129KB. A o to me slo - ze nejen ze hlasene informace o volnem miste byla zcela neodpovidajici, ale dopadlo to kernel panicem (nastesti resitelnym, skrze par obskurnich prikazu a restartovanim NFS).

Po rebalance a manualnim "garbage collectingu" se to umoudrilo.

Z jakeho duvodu by mel clovek neverit volnemu mistu v DF prikazu? To popira zaklady logiky.. vidim volno, chci ho vyuzit.

Apropo - uz jsem Tomasi poslal ty disky co lidi od vas nakoupili?

To nepopira zaklady logiky. To popira zaklady znalosti o COW systemech s kompresi,deduplikaci a snapshoty. Popira to take porozumeni dokumentaci.
Na zjisteni volneho mista na btrfs pouzivejte btrfs nastroje - btrfs filesystem df
Na zjisteni volneho mista pouzivejte zfs nastroje - zfs get used,avail,refer.
A poctete si zde:
https://docs.oracle.com/cd/E19253-01/819-5461/gbchp/index.html

Pouzivat df na btrfs/zfs je jako pouzivat v linuxu ifconfig a stezovat si ze pulku sitovych veci na tom nemuzu nastavit. Kazda vec ma svoje nastroje. Ano mohu v pripade nouze docasne pouzivat nastroj omezeny a nepresny, musim si ale byt vedom jeho limitaci. Dnes take nediagnostikujete auta nastroji z roku 1920.
Kazdy nastroj ma nejaka sva omezeni a nejaky okruh uziti kdy je vhodny a kdy mene vhodny.
Zkuste se vice zamerit na cil a ne na nastroj v tomto pripade.

[RDa]

COW nema nijaky magicky vliv na "free space" uz z principu (cow ma vliv leda na usage / celkovou velikost, pokud se pouzva sdileni bloku a deduplikace ci komprese).

Chybejici garbage collecting a defragmentace (dohromady a la vacuum) byl ten zdejsi problem + neschopnost FS driveru spravne obslouzit sve dve domeny (meta vs data), kdy jedna branila druhe ve vyuziti.

Link neni relevantni, nemam ZFS, nemam vice filesystems v poolu, nemam snapshotem zamcene data o kterych nevim.


// btw s ifconfig-em si vystacim taky - a to i v roce 2025 .. nevim jako proc pouzivat nejaky nesmyslny nabobtnaly tool a la systemd, pro jednoduche veci jako nastaveni IP (a imho "ip" je porad malo, kdyz clovek do sitariny musi nadale vrtat pres resolvconf a dalsi veci).

[Trident Vasco]

COW nema nijaky magicky vliv na "free space" uz z principu (cow ma vliv leda na usage / celkovou velikost, pokud se pouzva sdileni bloku a deduplikace ci komprese).

Chybejici garbage collecting a defragmentace (dohromady a la vacuum) byl ten zdejsi problem + neschopnost FS driveru spravne obslouzit sve dve domeny (meta vs data), kdy jedna branila druhe ve vyuziti.

Link neni relevantni, nemam ZFS, nemam vice filesystems v poolu, nemam snapshotem zamcene data o kterych nevim.


// btw s ifconfig-em si vystacim taky - a to i v roce 2025 .. nevim jako proc pouzivat nejaky nesmyslny nabobtnaly tool a la systemd, pro jednoduche veci jako nastaveni IP (a imho "ip" je porad malo, kdyz clovek do sitariny musi nadale vrtat pres resolvconf a dalsi veci).

Souvisi protoze to prinasi dalsi vrstvu komplexity. To o free space je velmi odvazne tvrzeni ktere bych veril mozna vyvojari fs u jednoducheho fs kde je CoW jako jednoducha deterministicka pridana feature i po 15ti pivech. Napr. u XFS. U BTRFS a ZFS (no dobre tam umim trochu debugovat) vubec netusim rychle a do 5 minut co se deje s metadaty, kde moje data jsou, co se deje kdyz je soubor ve stavu open a jak se chovaji "in transit" mezi jednotlivymi operacemi.
A nedozvedel jsem se to ani na "advanced / expert" skoleni ke storagim. Musite byt hardcore vyvojar.

A tim spis pokud si nejaky kabrnak pouzije experimentalni feature.

BTW: Jsou operacni systemy kde vetsinou s ifconfigem a par konfiguraky navrch vystacite. Ale linux to uz davno neni. Bez ethtoolu a ruznych servisnich utilitek na sitovky se neda fungovat. Routovacich tabulek a policy uz se nam taky namnozilo...

[CPU]

s ifconfigem a par konfiguraky navrch vystacite. Ale linux to uz davno neni. Bez ethtoolu a ruznych servisnich utilitek na sitovky se neda fungovat. Routovacich tabulek a policy uz se nam taky namnozilo...

No ano a proč to neudělat ještě lepší? Proč těch toolů nepřidat ještě 25...to je můl vlhký sen, abych na provedení jednoduchých úkolů potřeboval dva doktoráty. Tady je vidět, jak Linux uvnitř pomalu hnije.

A pokud df není schopno vrátit správnou hodnotu volného místa, tak má vrátit chybový kód.

[Filip Jirsák (forum)]

No ano a proč to neudělat ještě lepší? Proč těch toolů nepřidat ještě 25...to je můl vlhký sen, abych na provedení jednoduchých úkolů potřeboval dva doktoráty. Tady je vidět, jak Linux uvnitř pomalu hnije.

Ty v Linuxu dávno zastaralé utility jsou dvě: ifconfig a route. Nová je jedna: ip. Takže i podle toho vašeho měřítka „počet utilit“ je balík iproute2 lepší.

(Pak má také tu výhodu, že na rozdíl od ifconfig/route vždy funguje, ale zdá se, že tohle kritérium pro mnohé není podstatné.)

[RDa]

A pokud df není schopno vrátit správnou hodnotu volného místa, tak má vrátit chybový kód.

Ano, napr. tak, jak to dela u inode usage (df -i ... vraci 0 / 0 / 0 pro btrfs)

Alternativne by to mohlo vratit toleranci jako GPS ... free: 128GB ±32GB :D

@Trident Vasco - vlastne vim proc nepouzivam by default btrfs filesystem df ... protoze:

- ten komp kde je BTRFS je jako NAS, a sdili to storage pres NFS. Takze na klientovi by onen prikaz nefungoval a je tam jen df

- pokazde namisto df pouzivat "ssh host btrfs filesystem df /mnt/neco" ... a hledat v tom je trocha meh. Ne nadarmo je "df" tak zkraceny.. protoze to potrebujes porad.

- a pak - az by bylo vice ulozist, tak to poustet rucne pro vsechny pro rychly prehled stavu?

- apropo "btrfs filesystem df" nezobrazi volne misto.. musis si ho spocitat (Data, RAID6: total=75.88TiB, used=75.73TiB), snad tam jde alespon vypnout

A cely to je dost blbe zas, o 2 nasobek:

Kód: [Vybrat]

$ df -h /mnt/neco/
Filesystem        Size  Used Avail Use% Mounted on
host:/neco  102T   77T  367G 100% /mnt/necovs

Kód: [Vybrat]

btrfs fi df /mnt/neco
Data, RAID6: total=75.88TiB, used=75.73TiB

echo $(( ( 75880 - 75730 ) * 1024 / 1000 ))
153vs

Kód: [Vybrat]

$ btrfs fi usage /mnt/neco
    Free (estimated):            366.87GiB      (min: 252.50GiB)
    Free (statfs, df):           366.84GiB

Takze je volne misto ono FREE z btrfs filesystem usage, nebo ten rozdil z btrfs filesystem df ?

Pokud to mensi z df.. tak proc je FREE o stovku GB vetsi a kam se to misto podelo??

Vysledek je totiz, ze btrfs filesystem df je spatne - jsou tam stovky GB nealokovane, takze tebou doporuceny btrfs filesystem df nerika kolik toho muzu ulozit, ale kolik toho bylo smazano v ramci soucasnych alokaci. Dalsi volne misto je tady:

Unallocated:
   /dev/mapper/sed_sde1   34.29GiB
   /dev/mapper/sed_sdk1   34.32GiB
   /dev/mapper/sed_sdq1   34.32GiB
   /dev/mapper/sed_sdn1   34.32GiB
   /dev/mapper/sed_sdb1   34.32GiB
   /dev/mapper/sed_sdh1   34.32GiB
   /dev/mapper/sed_sdt1   34.29GiB
   /dev/mapper/sed_sdw1   34.29GiB

A tohle unallocated misto zobrazuje df rozhodne verohodneji ( 34.3 * (8-2) = 205.8 unallocated + 153 freed = 358.8 )

[rmrf]

Podle mých zkušeností df nad btrfs sice dřív ukazoval špatné výsledky, ale to už je dávno odstraněno. Používám df úplně běžně. Ale zato btrfs filesystem df nepoužívám. btrfs filesystem usage mi přijde mnohem přívětivější. A ty údaje se od běžného df skoro neliší.