Storage läuft aus auf VM mit openSUSE

[tomm1984]

Hallo,

ich habe auf einer VM openSuse Leap 15.1 laufen und hatte anfänglich nur etwa 240 GB Festplatten-Speicher konfiguriert. Während einer Installation lief jedoch der Storage voll und die Installation brach ab. Daraufhin erweitert ich die virtuelle Festplatte und dann die Partition; neue Größe knapp 400 GB.

Die Installation bricht allerdings an derselbe Stelle ab und Linux wirft diverse Fehlermeldungen, dass

• root
• srv
• home usw.

lediglich nur noch 0 Byte zur Verfügung haben.

Der Disk-Manager sowie andere Tools sagen jedoch aus, dass noch genügend Platz frei ist.

Ich frage mich, ob ich die neue Speichergröße den Usern noch irgendwie "mitteilen" muss ... sozusagen da noch die alte Grenze drin hängt.

Über Hilfe freue ich mich jetzt schon :-). Danke

 

[Eishunter]

Welches OS mit welcher Virtualisierungslösung wird genutzt ?
240GB bzw. 400GB für eine VM sind schon richtig viel.
Wie ist die HDD der VM konfiguriert dynamisch oder fest ?

 

[Ebrithil]

Du musst auch noch das Dateisystem vergrößern, die Partition selber reicht da nicht

Laut https://www.thegeekdiary.com/how-to-resize-expand-a-btrfs-volume-filesystem/ müsste btrfs filesystem resize max / funktionieren

 

[tomm1984]

@Eishunter : Moment, bitte. Ich schaue mir zunächst den Tipp von @Ebrithil an

 

[Eishunter]

@tomm1984 - danke für deine NICHT erhaltene Rückmeldung

 

[tomm1984]

@Ebrithil : Ich musste erstmal die VM restoren, da gar nichts mehr ging ...

Zwischen der ersten Zeile und der letzten sehe ich keinen Unterschied. Das Kommando "+10g" gibt schon eine merkwürdige Rückmeldung. Ich würde daraus schließen, dass das BTRFS schon vergrößert war.

 

[lokon]

lediglich nur noch 0 Byte zur Verfügung haben.

Ein bekanntes Problem / "Bug" bei BTRFS und vermutlich wegen "thin provisioning" dessen.

Das Problem tritt mit BTRFS auf, wenn eine Anwendung zB in KDE den freien Speicher überwacht und die Kopieroperation gar nicht erst startet.

Es lässt sich vermutlich replizieren, wenn eine Disk mit BTRFS neu formatiert wurde und dann Daten >50% Kapazität auf einmal kopiert werden.
Außerdem kommt es bei nahezu vollständigem Speicherverbrauch zu solchen Fehlern.
Beides hier schon öfters passiert.

Symptom: btrfs fi usage <btrfsfilesystem>
zeigt volle Metadata und Data-Bereiche an.
ABER:
Der "unallocated space" ("Unallocated" bei obigem Kommando) ist groß genug : ca. 1/2 der BTRFS Partitionsgröße.

Software die leeren Speicher prüft bricht hier u.U. ab.

"Hotfix" / "Hack": über Kommandozeile per dd oder cp eine große Datei erzeugen/kopieren.
Eventuell geht auch ein rebalance des btrfs-trees - das braucht aber sehr lange lt Manpage
Damit sollte "irgendwann" auch ein neuer Chunk aus dem "unallocated" genommen werden und als Speicher für Metadata/Data zur Verfügung stehen.

df -h ist bei BTRFS nicht so nützlich
Anwendungen die sys/statvfs.h benutzen wie KDE (über Core-KIO) sind vermutlich potentiell auch betroffen.

Technischer Hintergrund: Wenn das Dateisystem sehr kompliziert wird, dann ist es schwer verlässlich zu sagen welche Eigenschaften es hat.
- Kompression, Snapshots, Daten in Metadaten, andere Organisationsweisen und Algorithmen usw.
BTRFS nutzt zB keine Inodes
Ähnliche Probleme mit freiem Speicherplatz gibt es bei Netzwerkprotokollen - bei SMB gibt es dfree command zur Manipulation der freien Speicheranzeige, wenn komplizierte Dateibäume in Samba freigegeben werden.

Quelle: siehe BTRFS FAQ , Bugtickets bei KDE (bugs.kde.org)

Ergänzung (9. September 2020)

BTRFS schon vergrößert war

Es gibt bei BTRFS "unallocated" - nicht belegten Speicher.
Das ist Speicher bevor entschieden wurde, ob er mit Data oder Metadata Blocks/Chunks belegt wird.

 

[tomm1984]

@lokon : okay, super + danke. Den "Hack" probiere ich gerade schon aus.

dazu noch eine Frage: Gibt es eine bestimmte Regel bzgl. der Größe der Datei? Also, muss sie bspw. so groß sein, dass sie den "alten Wert" überschreitet oder was triggert das neue Einlesen der Werte / das Verschieben der Grenze ... oder wie auch immer man "das" nennen kann?

Und noch eine Frage aus Neugierde: Ist es relevant, dass der Kopiervorgang per Terminal gestartet wird oder ginge es bspw. auch via WinSCP?

 

[lokon]

Für "Data" : Vielleich so in Richtung der Größe der kompletten "Metadata"-Größe - die bewegt sich im niedrigen 1-2 stelligen GB Bereich.
Ein "Metadata"-Chunk wird von BTRFS benötigt und alloziert - aus dem "unallocated" Bereich, wenn viele kleine Dateien erstellt/kopiert werden.
Rechnerisch vermutlich eine Zahl um auf über "100%" der Belegung zu kommen - bei Metadata ist diese Zahl aber nicht so richtig genau, da das ja die Verwaltungsinformationen des Dateisystems sind - Dateien kleiner als 4KB können in Metadata gespeichert werden - also darüber könnte man das vermutlich auch annähern.

winscp würde vermutlich auch funktionieren, da dabei afaik auch keine "intelligente" Abfrage gemacht wird

Q/Weiterlesen: BTRFS Features

 

[mkossmann]

Opensuse auf BTRFS ? Da würde ich auch mit "snapper list" schauen ob es nicht mehr benötigte Snapshots gibt um Platz freizuschaufeln.

 

[tomm1984]

@mkossmann : genau scheint es zu sein

@lokon : ich habe es letzte Nacht mit der Dateigröße übertrieben (weil ich ja nicht wusste wie groß "groß" ist) und einfach mit vier großen Dateien die gesamte Platet vollgeschrieben. Beim Löschen habe ich dann gemerkt, dass der Platz gar nicht freigegeben wird und so bin ich - über kurz oder lang - beim Trashbin und vor allem bei den Snapshots gelandet.

So, wie das verstehe, hat openSUSE Snapper und irgendwie auch Yast-Snapper im Bauch. Snapper erstellt einen Snapshot nach Zeit (ich glaube alle Stunde per default) und Yast-Snapper einen bei Veränderungen am System - beides ungunstig for solch große Installationen und vor allem während der Installation. Letztlich habe ich dann die Snapshots deaktiviert und gelöscht (https://www.simplified.guide/suse/snapper-disable-snapshots).

@lokon : Danke für Deine Tipp! Er hat mir insofern weitergeholfen, dass ich dadurch auf die Snapshots gestoßen bin. Leider bin ich erstmal nicht mehr dazu gekommen, dass zu prüfen; vertage das aber, weil es mich selbst interessiert.

Ich würde jedoch darauf tippen, dass eben auch die /.snapshots nicht in der einen, oben genannten, Größenberechnung berücksichtigt wird und de facto trotzdem der Speicher ausläuft.

Vielen Dank soweit in die Runde!

 

[sedot]

Zu Snapper schau mal hier:
https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-snapper.html