[glusterfs] features.barrier blijft "enable"?!?

[NaliXL]

Wij hebben een tweetal dedicated machines voor gluster en samba draaien. Er draaien 3 gluster volumes op, glusterfs 3.8 (die hoop ik nog te upgraden, maar wil eerst de nodige voorzorgsmaatregelen treffen en dat kost tijd).

We hebben recent wat stabiliteitsproblemen gehad (samba server accepteert plotseling geen netwerkverbindingen meer, zelfs niet nadat de samba service is herstart. Een volledige server reboot lost het wel op). Het leek te maken te hebben met oplocks i.c.m. bepaalde windows applicaties, en het is tot nu toe niet meer voorgekomen na enkele aanpassingen in smb.conf: de opties

code:

strickt locking = yes
inherit owner = yes
acl group control = yes

heb ik weggehaald.

Fin, vandaag op de server bezig en na een gluster volume info viel mij op dat voor één volume features.barrier op enable staat. Ik ben niet bezig met een snapshot, dus vreemd. Ik kan ook bestanden schrijven naar dat volume (ook groter dan het intern geheugen van die machine), dus dubbel vreemd. De timeout voor de barrier staat op 120 seconden. Maar na 120 seconden is de barrier nog steeds enabled.

Mijn vragen:
1. Is dit een false positive, hoe kan ik dat uitsluiten?
2. Kunnen de recente problemen met samba hiermee te maken hebben?

Heb uiteraard al het nodige op google gezocht, maar alleen gevonden dat er in een veel oudere gluster versie een bug zat waardoor barrier op enable bleef staan, maar dat heeft denk ik geen betrekking meer op 3.8. Verder is eigenlijk de enige info die ik kan vinden dat de barrier alleen bij snapshots aangezet wordt en automatisch weer uit zou moeten gaan na de timeout.

Edit: Het lukt ook niet om de barrier met de hand uit te zetten:

code:

gebruiker@server:~$ sudo gluster volume barrier volumenaam disable
volume barrier: command unsuccessful : Failed to reconfigure barrier.

[ Voor 6% gewijzigd door NaliXL op 06-09-2018 16:39 . Reden: Nieuwe relevante info toegevoegd. ]

[Brahiewahiewa]

NaliXL schreef op woensdag 5 september 2018 @ 12:58:
… 2. Kunnen de recente problemen met samba hiermee te maken hebben?
...

Dat ligt wel voor de hand, ja.
Als je brick ten onrechte barrier enabled heeft, dan houdt-ie alle acknowledgements op file operations tegen
Je windowsserver-clients hanteren een veel lagere time-out dan die 120 seconden
En windows clients zijn dan niet te beroerd om het nog een keer te proberen, en nog een keer, en nog een keer ….

[NaliXL]

Misschien begrijp ik dan verkeerd hoe die barrier werkt, maar het enige wat ik erover kan vinden uit de gluster docs:

During snapshot creation some of the fops are blocked to guarantee crash consistency.

Dus als die barrier inderdaad nog enabled is, dan ben ik wel erg benieuwd over welk soort fops er dan gesproken wordt. Want ik kan eigenlijk gewoon alles doen met die share, en het lijkt ook daadwerkelijk opgeslagen te worden (in plaats van dat het bijvoorbeeld tijdelijk in werkgeheugen wordt opgeslagen).

Edit: de oplocks zijn een probleem dus, bedankt @Brahiewahiewa. Maar ik hoop wel dat iemand mij kan helpen de root cause te vinden, want er is bijzonder weinig over de barrier feature te vinden online.

[ Voor 16% gewijzigd door NaliXL op 06-09-2018 16:29 . Reden: Reactie op brahiewahiewa ]

[Brahiewahiewa]

NaliXL schreef op woensdag 5 september 2018 @ 19:52:
Misschien begrijp ik dan verkeerd hoe die barrier werkt, maar het enige wat ik erover kan vinden uit de gluster docs:

[...]


Dus als die barrier inderdaad nog enabled is, dan ben ik wel erg benieuwd over welk soort fops er dan gesproken wordt. Want ik kan eigenlijk gewoon alles doen met die share, en het lijkt ook daadwerkelijk opgeslagen te worden (in plaats van dat het bijvoorbeeld tijdelijk in werkgeheugen wordt opgeslagen).

Ja, dat kun je nu, met de aanpassingen in smb.conf. Maar als je die aanpassingen terug draait ga je weer uit je op-locks lopen. Je hebt met de aanpassingen een symptoom bestreden, maar niet de root cause aangepakt