Het BTRFS ervaringen topic

[Anthirian]

_JGC_ schreef op maandag 3 augustus 2020 @ 01:39:
[...]

Dat is niet de schuld van btrfs.

Redhat bouwt zijn Enterprise versies op zwaar aangepaste kernel versies. RHEL8 is op basis van 4.18, welke geen longterm release is, mogen ze zelf onderhouden. Btrfs wordt ontwikkeld op git master en bugfixes worden gebackport naar eerdere ondersteunde versies. Redhat mag dat dus zelf doen, en dat komt nog bovenop hun eigen kernel aanpassingen. Als ze daar niet de kennis voor in huis hebben wil je dat niet als feature aanprijzen in een enterprise distributie lijkt me.

Klopt, dat wilde ik ook aangeven met mijn post. RHEL heeft dit aan zichzelf te wijten.

EDIT: dit was overigens desbetreffende discussie: https://news.ycombinator.com/item?id=14907771

[ Voor 6% gewijzigd door Anthirian op 03-08-2020 10:22 ]

[Q]

Keeper of the Keys schreef op maandag 3 augustus 2020 @ 06:57:
[...]


Ik wilde minder abstractie lagen over elkaar leggen maar als btrfs geen goede optie blijkt dan zou het best kunnen dat het LVM+fs wordt.

/Edit - Er is een patch geschreven voor btrfs/zfs snapshots in GlusterFS maar die is kennelijk nooit gemerged en doodgebloed

Ik denk dat er niets mis is om gewoon LVM te gebruiken, zeker als dit 100% door GlusterFS gesupport wordt.

[Mars Warrior]

Zijn er hier nog mensen die al wat langere tijd ervaring hebben met BTRFS icm Docker?

Ik heb die combi uitgeprobeerd op een klein Fujitsu bakje met enkel een SSD erin, maar dat levert dus op alle Docker & database volumes een CPU load van ruim 30% op.

Nu heb ik COW niet uitgeschakeld, wat wel had gekund natuurlijk, maar ik ben voor die server weer terug naar het aloude ext4, en dus ook weer terug naar < 1 % CPU load.

Het nut van BTRFS ontgaat mij dus om docker containers/data/volumes/binds met BTRFS te doen en te snapshotten, want deze CPU load is onacceptabel.

Backup wordt dus op de bestaande manier met Duplicati gedaan.

[menn0]

De situatie;

Had 4 hdds btrfs in een bananpi met icebox case.
1,5 tb x3
14tb x1

Nu wiilde ik de 14 tb die voor 6tb vol stond in een ander systeem zetten.
De 3 1,5tb schijven waren voor ongeveer 3GB gevuld.

Ik dacht dat ze JBOD zaten in het systeem en ben met btrfs delete devid 1, devid 2 de 1,5tbs aan het verwijderen.

Toen wilde ik dev 3 (laatste 1,5tb) schijf verwijderen en kreeg ik de melding dat het niet kon omdat het een RAID1 opstelling betrof.

Ok dat wist ik niet meer, maar goed, even doorpakken met het volgende commando;

code:

btrfs balance start -f -sconvert=dup -mconvert=dup -dconvert=single /STORAGE

Dit ratelt nu al lekker 2 dagen,
Achteraf, was er nou iets wat ik beter had kunnen doen? Had ik een soort van balance of actie kunnen uitvoeren waardoor ik veel sneller de system en meta data en 'echte' data van de laatste 1,5tb naar de grote schijf had kunnen moven?

Ik begrijp overigens ook niet helemaal hoe de data toen zo slecht verdeeld was over de schrijven, data op deze opslag was een soort vault. Dus zo goed als nooit gebruikt.