OCFS2(unsupported): Frage zu Belegung

S

sgw

Member
Proxmox Subscriber
Apr 5, 2024
140
11
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.
 
@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.
 
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.
 
You must log in or register to reply here.
Top Bottom
Back