Dotaz: Btrfs - metadata

[Honza]

Zdravim, řešil jsem problém vytížení PC až na load 30 a zjistil jsem, že se to děje až po připojení btrfs disku (md raid6) cca 8T , mount trvá cca 1-6 minut a celý systém průběžně zatuhává. HW problém by být neměl. Zkusil jsem btrfs a něco našel, ale i po opravě se nic nezměnilo. A teď jsem si všiml, při příkazu btrfs fi df /mountpoint se dozvím, že data 6T a metadata 2T - neni to moc ? Na jiným disku mám 0,5T a metadata 3G.

Dají se metadata nějak redukovat ?

Dík

Honza

Odpovědi

[Michal]

A zhorsuje se to postupem casu? Pokud ano, tak tohe jsem uz videl. Pomohlo az vykopirovat data a udelat ciste btrfs.

Pokud to neni jen na hrani, tak doporucuji zvazit nasazeni nejakeho production-ready FS.

[Honza]

no to jsem nechtel psat vsechno - ano zhorsuje , ted to zrovna kopiruju a preformatuju to (to mi napadlo este nez jsem se zeptal tady). Je to doma uloziste na data od image disku , pres video , zalohy .......

[Dotaz]

Nebylo to vytvářené přes btrfs convert? Přes to vytvořeny fs se mi taky zboril

[Honza]

myslim, 6e jo. Nejak si matne vzpominam, za sem to snad i zase daval zpatky a zase konvertoval, ale pak to jelo ok.

[Andrej]

Pokud to neni jen na hrani, tak doporucuji zvazit nasazeni nejakeho production-ready FS.

Tohle je odpověď z roku 2009? Nebo trolling pro zábavu? Nebo další zbytečný FUD? Facebook taky není production-ready, když používá Btrfs? Pravda, možná je Facebook „na hraní“, ale jinak ta analogie hrubě nesedí.

Podle téhle „logiky“ by byl jediný production-ready FS ZFS, že ano. (Protože production-ready FS by měl mít (přinejmenším) (1) checksumy dat i metadat, (2) vestavěný RAID (tedy skutečný RAID, ne pouze AID bez R), (3) atomické snapshoty, (4) copy-on-write atd. Tohle splňují pouze Btrfs a ZFS. A ZFS má jistý chronický problém s licencí. Takže…)

Ještě bych se rád zeptal, který filesystém (kromě ZFS) tedy je production-ready (a podle jaké definice)… Snad ne Ext4 [2009] [2012] [2015] [2018] s architekturou z dob 10-gigabytových disků, který nemá ani jednu z výše uvedených vlastností? To nebude ono. Jiné možnosti?

[Jendа]

při příkazu btrfs fi df /mountpoint se dozvím, že data 6T a metadata 2T

No asi hlavně kolik z toho je free a kolik used. Jinak jo, je to dost. Pro představu na 6TB FS kam se každý den rsyncovalo asi 8 virtuálek a pak se dělal snapshot měla metadata asi 400 GB, z toho většina free - pomohlo balance metadat -musage=20.

Zdravim, řešil jsem problém vytížení PC až na load 30 a zjistil jsem, že se to děje až po připojení btrfs disku (md raid6) cca 8T , mount trvá cca 1-6 minut a celý systém průběžně zatuhává.

Mrkni do iotopu jestli běží nějaký clean nebo tak něco.

Píšeš úložiště images - čekal bych, že to je způsobené fragmentací a CoW malinkých bloků. Vypni CoW. Pokud ho ale potřebuješ, tak to máš blbý.

[Andrej]

až po připojení btrfs disku (md raid6)

Jestli to správně chápu, jedná se tedy o AID6 (nikoliv RAID6) vytvořený přes zastaralý mdadm a na tom Btrfs? Aniž bych se pokoušel spekulovat, proč je ten filesystém rozbitý, jen poznamenám: Taková konfigurace se nedoporučuje. Filesystémy vhodné pro 21. století (Btrfs, ZFS) mají opravdový RAID vestavěný v sobě, a to z mnoha velmi dobrých důvodů.

Berličky typu mdadm (nebo novější dmadm provázaný s LVM) implicitně vytvářejí pouze AID bez R. Není tam žádná skutečná redundance. (Příklad: AID po náhodném (low-level) přepisu jednoho z disků (při zachování headeru) zničí všechna data. Skutečný RAID (Btrfs, ZFS) takový průšvih ustojí, pokud je v redundantní konfiguraci. Podobně je tomu u silent data corruption a dalších typů selhání disků — AID vrací náhodná data, RAID konzistentní data (nebo taky nic, jsou-li všechny repliky poškozené a/nebo chybí příliš mnoho kousků dat+parity).)

Ano, vím, že existuje dm-integrity, ale to je voser navíc, který je třeba explicitně nastavit a který poskytuje jenom 1 výhodu / řeší jenom 1 problém, zatímco všechny ostatní výhody/problémy neposkytuje/neřeší.

Tady je znamenitý blogpost na dané téma, který by měl být povinná četba. (I přesto, že autor nakonec úplně přestal používat Btrfs a zůstal u ZFS.)

[Honza]

ano, je to 5 4T disku v (r)aid6 , potom pres cryploluks sifrovani , na cryptooddile LVM2 a pak btrfs. ale ten je jen jeden z mnoha jak btrfs, tak i jinych. Teda mam uz cca 15 let fungujici (z raid 5 jsem menil na 6 a pak menil dizky z 1T , 2T a nakonec 4T). Je to domaci server , kde jsou videa , zalohy , zalohy image, kdyz opravuju disk atd. neni to nic firemniho. A jednu virtualku W10 na ucetnicvi.(a par dalsich virtualek linuxu)

Vim, ze by to asi nahradil ZFS a nejaky unix NAS , ale to bych musel koupit horu pameti. Ted tam mam 16G , z toho 4G pro DOM0 a zbytek pro virtualky.

[a1bert]

co ti ukazuje:

btrfs fi us /mountpoint
btrfs de st /mountpoint 
uname -a

[Honza]

Příloha:

• btrfs.txt (1093 bytů)

Bylo to puvodne na debianu 8 , ted je to na alpine linuxu.

[Honza]

Metadata,single: Size:1.29TiB, Used:882.81GiB

asi se to nejak meni v case, ted je system stabilni , load 1.2 , ale bylo to vic.

[a1bert]

mas tam malo volneho mista, jakej ma ten svazek "usecase"?

ten load ktery si pozoroval byla zrejme interni balancing metadat (proto kleslo obsazeni metadat z 1.2T na 800M), ale porad to neni uplne koser, obzvlaste pokud data na svazku casto menis. Pokud dobre pocitam mas cca 2% volneho mista oproti doporucovanym 10-15% https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Balancing

ja bych tam zkusil neco pomazat, propripade pridal docasne nejake nove blokove zarizeni a zkusil nejaky rucni balancing (nejdrive prazdne chunky: -dusage=0 pak -musage=0 a nakonec -musage=50), mohlo by to uvolnit nejake misto,

kazdopadne s takhle starym jadrem muzes skoncit v nejakem neprerusitelnem (balance cancel) loopu ze ktereho se dostanes pouze rebootem + balance=skip parametrem mountu, aby po restartu nepokracoval v balancingu takze se priprav i na tuto eventualitu

pokud svazek neni jen nejake odkladiste a je aktivne pouzivan, urcite budes muset dodrzovat doporucene "volne misto", nebo alespon pravidelne balancovat, jinak se casem dostanes do stejneho stavu...

(o tom ze btrfs nad lvm/dm raidem neni dobry napad uz psali jini...)

(rotoval jsem na btrfs zaznamy z bezpecnostnich kamer a mel jsem podobne problemy, nakonec jsem to vyresil zmenou na "hloupy" FS, ktery muzu zaplnovat do 100% aniz bych se o nej musel starat)

[Honza]

malo mista ..... jsem mu pres LVM dal 1T , pustil na nej btrsfsck (mel chyby), a jeste ho promazal. Na tomhle konkretnim disku jsou zalohy dat z domova - teda je tam zaloha ucetnictvi - nic, a pak vse od cca 97 roku , teda kdyz jsem si delal nove PC , data sla sem, image instalacek, rekl bych ze je to uloziste, kde se data moc nemeni. Jedine, prave proto, ze uz nekolik let se odhodlavam, ze si v tech datech udelam poradek, tak tam byl pustenej dedup , ale tak 3 roky zpet.

Zvlastni - ale uz od zacatku, pokud v mc chci mazat soubor - treba 500m , tak to trva treba 10 sec. U ext4 to byva hned. U presunu v ramci svazku taky. Mam zaply compress=lzo

[a1bert]

ja tam volny 1TB nikde nevidim:

Free (estimated): 141.68MiB (min: 141.68MiB)

pridej tam nove blokove zarizeni (btrfs device add)

[Honza]

ten system mel cca 5T a ja mu jeden pridal. Ted ma cca 6. Co to misto zaplnilo netusim.

[a1bert]

no jelikoz tam mas 5T jen v datech (bez meta) tak bych nejdrive zjistil co to zaplnilo ...

Data,single: Size:4.98TiB, Used:4.98TiB