OCFS2(unsupported): Frage zu Belegung

S

sgw

Member
Proxmox Subscriber
Apr 5, 2024
150
15
18
www.oops.co.at
Ich hab hier 3 PVEs in einem Cluster, die Nodes greifen per FC auf ein MSA 2060 SAS Storage zu.

Ich kann mich ad hoc nicht mehr erinnern, was genau der zwingende Grund war, dass ich damals auf OCFS2 gehen musste, jedenfalls muss ich in diesem Cluster mit diesem Setup leben.

Wir bekommen letztens Warnungen vom Storage, Belegung zu hoch, etc

Es gibt dort einen Pool A, Belegung 7,0 TB von 7,6 TB (aus Sicht des MSA-Controllers) : 92 % Belegung

In selbigem Pool existiert ein einzelnes Volume mit 7 TB. Soweit konsistent.
Keine Snapshots auf MSA-Ebene.

Ich kann mich nicht dran erinnern, dem OCFS2-FS eine Größe gegeben zu haben.

Aus Sicht eines PVE sieht das so aus:

/dev/mapper/msa2060_lun1 7.0T 3.8T 3.2T 55% /mnt/ocfs2/PVE001

also weit nicht voll.

Dennoch war es so, dass durch Entfernen von Snapshots in PVE die Belegung auf MSA-Ebene runter ging.

Kann/muss ich irgendwelche Bereinigung im OCFS2 machen, um "Belegung in PVE" und "Belegung in MSA" wieder auf gleich zu bringen?
Filesystem-Check? Nach unmount auf allen drei Nodes?

Auf dem MSA läuft immer wieder eine Datenträgergruppenbereinigung, die dürfte aber nicht wirklich was frei spielen.

Wir würden natürlich lieber die 3.2 TB nutzen, als jetzt schon zusätzliche Platten kaufen zu müssen.
Momentan wirkt es auf mich so, als ob ich nur noch ~500GB Luft habe, bis das MSA den Pool als voll betrachtet.

Ich hoffe, ich konnte verständlich machen, was mein Problem ist, danke für jegliche Hinweise dazu.
 
Hallo @sgw,

die Diskrepanz zwischen MSA-Belegung (92%) und OCFS2-Sicht (55%) ist ein klassisches Thin-Provisioning-Problem. OCFS2 gibt gelöschte Blöcke nicht automatisch an den MSA zurück.

1. TRIM/Discard — vermutlich die Hauptursache:
Code: 
# Einmalig freien Speicher an den MSA zurückgeben:
fstrim -v /pfad/zum/ocfs2-mount
Dauerhaft in /etc/fstab mit der Option discard einbinden. Vorher prüfen ob der MSA 2060 SCSI UNMAP unterstützt (sollte bei SAS der Fall sein).

2. PVE-Snapshots prüfen:
Du hattest ja schon beobachtet, dass Snapshot-Entfernung in PVE die MSA-Belegung senkt. Prüfe ob auf allen Nodes noch alte Snapshots existieren — jeder Snapshot hält auf MSA-Ebene Copy-on-Write-Daten.

3. MSA-seitig prüfen:
  • Unter Volumes → Statistics: "Allocated Pages" vs. "Written Pages" vergleichen
  • Prüfen ob das Volume Thin-Provisioned ist (Volume Properties)
  • Ggf. einen Volume-Reclaim auf MSA-Ebene anstoßen

4. OCFS2-Filesystem prüfen:
Code: 
tunefs.ocfs2 -Q /dev/sdX   # Filesystem-Details

Mit großer Wahrscheinlichkeit löst fstrim das Gröbste.
 
  • Like
Reactions: news
@Bu66as wow, danke für die detaillierte Antwort!

Der fstrim hat ~302 GB frei gegeben, das ist mal was für den Anfang.

Die Belegung in der MSA-GUI ist danach nicht sofort runter gegangen, aber evtl hat das mit der noch laufenden Datenträgergruppenbereinigung (seit gestern abends ..) zu tun (?)

  • PVE-Snapshots: haben wir bereits durchgesehen, da existiert nur einer, und der ist nicht allzu groß. Aber ich gehe das nochmals durch.
  • MSA: es existiert ein Snapshot zu dem Volume aus 2021(!). Vermutlich wurde der bei der Umstellung/Migration erstellt oder so. In der GUI sehe ich aber nicht, wie ich den entfernen könnte (EDIT: Evtl falsch interpretiert, evtl ist das gleich dem Volume, beide heißen auch identisch).
  • "Unter Volumes → Statistics: "Allocated Pages" vs. "Written Pages" vergleichen": den Punkt finde ich bislang nicht, da muss ich mich noch umsehen.
Danke erstmal für die Ansätze.
 
Last edited:
Die 302 GB durch fstrim sind ein guter Anfang. Dass die MSA-GUI nicht sofort aktualisiert: Ja, die laufende Datenträgergruppenbereinigung kann das verzögern. Der Controller muss die UNMAP-Befehle erst verarbeiten — nach Abschluss der Bereinigung sollte sich die Anzeige aktualisieren. Gib dem ein paar Stunden.

Der Snapshot von 2021 ist vermutlich der größte Hebel. Wenn das ein echter Volume-Snapshot ist (nicht nur ein Alias auf das Volume selbst), hält der seit 4+ Jahren sämtliche geänderten Blöcke vor. Das können bei aktiver VM-Nutzung locker Terabytes sein.

Prüfen kannst du das per SSH auf den MSA oder per CLI:

Code: 
show snapshots

bzw. in der Web-GUI unter Volumes → Volume-Übersicht — ein Snapshot hat dort typischerweise ein eigenes Icon und zeigt einen "Master Volume"-Verweis. Wenn Volume und "Snapshot" identisch heißen und es nur einen Eintrag gibt, ist es vermutlich kein separater Snapshot sondern das Volume selbst.

Falls es ein echter Snapshot ist und du ihn nicht mehr brauchst:

Code: 
delete snapshot <snapshot-name>

Vorsicht: Vorher sicherstellen, dass keine Replikation oder Rollback-Abhängigkeit darauf besteht. Das Löschen gibt den gesamten Snapshot-Pool-Space auf einen Schlag frei.

Zu den Statistics: Im MSA-Webinterface unter Pools → Pool A → Volumes → (Volume auswählen) → Performance/Statistics. Je nach Firmware-Version kann das auch unter Provisioning → Volume Details sein. Du suchst dort nach "Allocated Pages" (vom Controller reserviert) vs. "Written/Mapped Pages" (tatsächlich beschrieben). Die Differenz zeigt dir, wie viel durch Thin-Provisioning-Overhead und Snapshots verbraucht wird.

Für die Zukunft: Einen fstrim per Cronjob (wöchentlich oder täglich) einrichten, damit sich das nicht wieder aufstaut:

Code: 
# /etc/cron.weekly/fstrim-ocfs2
#!/bin/bash
/sbin/fstrim -v /mnt/ocfs2/PVE001 >> /var/log/fstrim-ocfs2.log 2>&1

Alternativ prüfen ob discard als Mount-Option in der /etc/fstab gesetzt ist — dann passiert das automatisch bei jedem Löschen. Bei OCFS2 mit FC-Backend funktioniert das in der Regel zuverlässig, kostet aber minimal I/O.
 
danke!

Ganz kurz: `show snapshots` zeigt nix an. Ergo vermute ich einen Alias, wie Du sagst.

Die genannten Web-GUI-Punkte hab ich nicht, die Controller behaupten, am Stand zu sein (IN210P002), die vorhandenen Firmware-Updates für einige Disks können damit ja wohl nix zu tun haben.

Cronjob werde ich einbauen, danke. Ich warte nun mal die Bereinigung ab, etc.
 
@sgw,

gut, dass show snapshots nichts zeigt — dann liegt da zumindest kein alter Snapshot-Overhead rum. Die 302 GB von fstrim sind rein die bisher nicht zurückgemeldeten Blöcke.

Wenn die Datenträgergruppenbereinigung durch ist, würde ich nochmal fstrim -v /mnt/ocfs2/PVE001 laufen lassen — manchmal werden nach dem Cleanup-Durchlauf auf MSA-Seite weitere Blöcke freigegeben, die dann wiederum per UNMAP zurückgegeben werden können.

Zu den Statistics: Bei der IN210P002-Firmware (das ist eine GL220-basierte) sind die detaillierten Volume-Page-Statistiken nur per CLI verfügbar:

Code: 
show volume-statistics PVE001

Falls der Befehl existiert, siehst du dort Allocated vs. Mapped Pages. Wenn nicht — ist bei der Firmware-Version leider nicht vorhanden, dann bleibt dir nur die Pool-Belegung als Indikator.

Gib Bescheid wie es nach der Bereinigung aussieht — wenn die Lücke zwischen OCFS2-Sicht und MSA-Belegung weiterhin groß bleibt, müssten wir tiefer schauen.
 
Ich zeig mal die entsprechende Ausgabe (das Volume heißt im MSA-Kontext "SSD01"):

Bash: 
HPE MSA Storage MSA 2060 SAS
System Name: xxx
System Location: xxx
Version: IN210P002
# show volume-statistics
Name   Serial Number                    Bps                IOPS             Reads            Writes           Data Read        Data Written     Allocated Pages  % Performance  % Standard     
  % Archive  % RC    Reset Time               
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SSD01  00c0ff530bf10000b018186001000000 6815.7KB           266              1994667405       5896487149       365.1TB          124.6TB          1673851          100            0             
  0          0       2025-03-13 09:04:55       
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Success: Command completed successfully. (2026-02-23 15:04:39)

Wie gesagt, ich warte mal Scrub etc ab bis morgen früh zur neuerlichen Sichtung.
Danke inzwischen.
 
Die Allocated Pages bestätigen das Bild: 1.673.851 Pages × 4 MiB (Standard-Pagesize MSA 2060) = ~6,39 TiB — das deckt sich mit den ~7,0 TB auf Pool-Ebene.

OCFS2 meldet 3,8T belegt → ca. 2,5 TiB sind stale-Allocations, die vom Filesystem freigegeben aber dem MSA nie per UNMAP zurückgemeldet wurden. Die 302 GB von fstrim waren also nur ein Bruchteil — vermutlich weil die laufende Bereinigung den Controller blockiert hat.

Nach Abschluss der Bereinigung nochmal:

Code: 
fstrim -v -m 4m /mnt/ocfs2/PVE001

Das -m 4m passt den Minimum-Extent auf die MSA-Pagesize an — kleinere Fragmente kann der Controller sowieso nicht freigeben. Da sollten dann deutlich mehr als 302 GB zurückkommen, potenziell im TiB-Bereich.
 
  • Like
Reactions: Johannes S
Sehr informativ, danke. Leider noch keine Bewegung, der Scrub vom Sonntag dauerte vorhin immer noch an.
Habe den abgebrochen, da tat sich nix in der Anzeige der Belegung, auch nicht nach fstrim (diesmal wurden etwa 200GB frei gegeben).
Nun ist der nächste Scrub gestartet worden. Vermutlich müssen wir mal so einen Lauf komplett abwarten?

Den adaptierten `fstrim -m 4m` hab ich noch nicht abgesetzt, damit warte ich auf den fertigen Scrub, nicht wahr?
 
Ja, genau — den Scrub komplett durchlaufen lassen. Der Controller verarbeitet die UNMAP-Befehle erst beim Bereinigungslauf, und solange der läuft (oder abgebrochen wird), staut sich das. Die bisherigen ~500 GB via fstrim sind beim Controller angekommen, aber noch nicht in freigegebene Pages umgesetzt worden.

Reihenfolge:
  1. Aktuellen Scrub komplett abwarten — nicht abbrechen
  2. Danach MSA-Belegung prüfen — die sollte jetzt schon um die ~500 GB gesunken sein
  3. Dann fstrim -v -m 4m /mnt/ocfs2/PVE001 absetzen
  4. Nächsten Scrub abwarten (startet je nach Konfiguration automatisch oder manuell anstoßen)
  5. Danach nochmal show volume-statistics und Pool-Belegung vergleichen

Der -m 4m sollte beim nächsten Durchlauf deutlich mehr bringen, weil der Controller dann nicht mehr mit einem parallelen Scrub beschäftigt ist und die UNMAPs sauber abarbeiten kann.
 
Grade miterlebt, wie der langlaufende Scrub von 99% auf erledigt sprang. An der Belegung laut MSA-GUI hat sich leider nichts verändert dadurch: aktuell leider 94% voll.

Ich hab dann gleich mal einen fstrim (noch ohne `-m 4m` ) abgesetzt, der meldete freigegebene 76GB, keine 10 Minuten später startet soeben der nächste Scrub (1.3. , 11:13h).

Ich denke, der sollte nun schneller durchlaufen?
 
  • Like
Reactions: Johannes S
Der Scrub dauert schon wieder seit gestern an. Die Belegung steigt langsam, unangenehm.
Ich frage mich, ob es notwendig oder hilfreich wäre, das OCFS2-fs auf allen drei Nodes gleichzeitig zu unmounten?
Nicht dass ich das gern tun würde, bräuchte klarerweise Downtime aller VMs etc.
 
Dass die MSA-Belegung nach Scrub-Abschluss unverändert bei 94% steht obwohl ~500 GB per UNMAP gemeldet wurden, ist auffällig. Die Datenträgergruppenbereinigung ist primär ein Integritätscheck (Parity-Verify) — die UNMAP-Verarbeitung läuft davon eigentlich unabhängig.

Prüf mal direkt per CLI, ob sich die Allocated Pages verändert haben:
Code: 
show volume-statistics SSD01
Vergleich mit dem Wert von vorhin: 1.673.851 Pages. Wenn der gesunken ist, hat der Controller die UNMAPs verarbeitet und die GUI hinkt nur hinterher. Wenn er gleich geblieben ist, werden die UNMAPs nicht umgesetzt — dann müssten wir prüfen ob Thin-Provisioning-Reclaim auf dem Volume überhaupt aktiv ist.

Zusätzlich:
Code: 
show pools
Das zeigt dir die Pool-Belegung per CLI — oft aktueller als die Web-GUI.

Zum aktuellen Scrub: Ja, der sollte deutlich schneller durchlaufen. Danach fstrim -v -m 4m /mnt/ocfs2/PVE001 wie besprochen, und direkt danach nochmal show volume-statistics SSD01 zum Vergleich.
 
  • Like
Reactions: Johannes S
Das ist besorgniserregend — die Allocated Pages sind nicht gesunken sondern gestiegen: von 1.673.851 auf 1.727.919, das sind +54.068 Pages ≈ +211 GiB. Die fstrim-UNMAPs werden vom Controller offensichtlich nicht in freigegebene Pages umgesetzt.

Wenn der aktuelle Scrub durch ist, bitte diese Ausgaben posten:
Code: 
show volumes SSD01
show pools
show disk-groups
Wir müssen sehen ob auf Volume-/Pool-Ebene Thin-Provisioning-Reclaim (bzw. Zero-Detect/UNMAP-Handling) überhaupt aktiv ist. Bei manchen MSA-2060-Konfigurationen muss das explizit eingeschaltet sein, sonst nimmt der Controller die UNMAPs zwar entgegen, verwirft sie aber.

Angesichts der Dringlichkeit (über High Threshold, Belegung steigt weiter): Falls kurzfristig Luft geschaffen werden muss und VMs mit ungenutzten/überdimensionierten Disks existieren — qemu-img convert einer qcow2 auf sich selbst (shrink) oder gezieltes Aufräumen innerhalb der VMs wären Sofortmaßnahmen, die unabhängig vom UNMAP-Problem wirken.
 
Bu66as said:
Das ist besorgniserregend — die Allocated Pages sind nicht gesunken sondern gestiegen: von 1.673.851 auf 1.727.919, das sind +54.068 Pages ≈ +211 GiB. Die fstrim-UNMAPs werden vom Controller offensichtlich nicht in freigegebene Pages umgesetzt.

Wenn der aktuelle Scrub durch ist, bitte diese Ausgaben posten:
Code: 
show volumes SSD01
show pools
show disk-groups
Wir müssen sehen ob auf Volume-/Pool-Ebene Thin-Provisioning-Reclaim (bzw. Zero-Detect/UNMAP-Handling) überhaupt aktiv ist. Bei manchen MSA-2060-Konfigurationen muss das explizit eingeschaltet sein, sonst nimmt der Controller die UNMAPs zwar entgegen, verwirft sie aber.

Angesichts der Dringlichkeit (über High Threshold, Belegung steigt weiter): Falls kurzfristig Luft geschaffen werden muss und VMs mit ungenutzten/überdimensionierten Disks existieren — qemu-img convert einer qcow2 auf sich selbst (shrink) oder gezieltes Aufräumen innerhalb der VMs wären Sofortmaßnahmen, die unabhängig vom UNMAP-Problem wirken.
Click to expand...
Kannst Du bitte endlich aufhören hier jeden Tag hier Kistenweise AI Slop abzuladen. Langsam geht mir das wirklich auf den Keks. Ich dachte Du verstehst den Wink mit dem Zaunpfahl aber irgendwo ist auch mal Feierabend.
 
  • Like
Reactions: Johannes S
@fstrankowski, ja fair enough — ich neig dazu zu ausführlich zu antworten, da hast du nicht ganz unrecht. Versuch ich in Zukunft kürzer zu halten. Ist jedenfalls alles handgeschrieben, auch wenns vllt nicht so aussieht ;)
 
Bu66as said:
@fstrankowski, ja fair enough — ich neig dazu zu ausführlich zu antworten, da hast du nicht ganz unrecht. Versuch ich in Zukunft kürzer zu halten. Ist jedenfalls alles handgeschrieben, auch wenns vllt nicht so aussieht ;)
Click to expand...
Dem kann ich nur widersprechen. Ich würde sogar so weit gehen und unterstellen, dass der Account @Bu66as teilweise vollkommen automatisiert "antwortet".
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back