Data HDD voll ?

davidche

New Member
Dec 1, 2024
10
1
3
Hallo zusammen,

habe folgendes Problem:

Ich habe einen ZFS Raid welches meine Filme und Serien beinhaltet. Jetzt ist es leider so, dass ich die letzte Zeit gemerkt habe das jellyfin etwas "humpelig" läuft.
Als ich auf Proxmox nach dem möglichen Grund nachsah, fiel mir auf das die DATA HDD auf 100% voll war. Dachte ich OK Frau oder ich haben nicht aufgepasst und es mit
den Filmen und Serien etwas übertrieben...
Also ein paar Serien und Filme von der Platte gelöscht. Allerdings ist diese immer noch voll laut der Proxmox Übersicht. Schaue ich allerdings speziell nach dem ZFS Pool stehen dort über 100 GB Frei.

Irgendwas schreibt die DATA HDD voll und ich weiß leider nicht wie ich das herausfinden kann.
Wäre über jeden Ansatz oder Hilfestellung froh.
 

Attachments

  • Bild 1.png
    Bild 1.png
    301.7 KB · Views: 11
  • Bild 2.png
    Bild 2.png
    316 KB · Views: 11
Hallo, es sollten immer 80% frei bleiben. Das macht man über zfs set quota= <pool>
Wenn man VDEV ZFS special device auf mirror SSD verwendet, hat man kein Problem mehr mit den Metadaten.
 
Hallo, es sollten immer 80% frei bleiben.
Das ist eine veraltete Regel, die für HDD und deren free space fragmentation performance basierte. Die Regel war damals schon eher so mäh.
Ich habe einen ZFS Raid
Was für ein RAID hast du genau?

Irgendwas schreibt die DATA HDD voll und ich weiß leider nicht wie ich das herausfinden kann.
Vermute mal CT Volumes. Was siehst du dort in Bild 2?
 
Nun wie aus den Bilder ersichtlich ist eine ein ZFS VDEV mit einer 4 TB HDD.
Also nichts mit alten Regeln, er erfährt nun real, was passiert, wenn es für die Meta- Und Daten eng wird!
 
Teile mal bitte
Bash:
zfs list -r -o space,refer,refreservation
zpool list
zpool status -vP
 
Hi erstmal und Danke für eure Rückmeldungen.
Hallo, es sollten immer 80% frei bleiben. Das macht man über zfs set quota= <pool>
Wenn man VDEV ZFS special device auf mirror SSD verwendet, hat man kein Problem mehr mit den Metadaten.

Das mit den 80% verstehe ich und das könnte auch durchaus Sinn ergeben.
Der letzterer Teil deiner Aussage ist für mich nicht verständlich, in dem Sinne das mir einfach know how fehlt.

Problem ist wenn ich jetzt einen Film/Serie zu meiner Bibliothek hinzufüge, komme ich wieder auf die 100% und das ganze System "schmiert ab".
Konnte mich gerade so Retten indem ich Backups lösche. In der Vergangenheit war es so, indem ich einfach Filme/Serien gelöscht habe und es klappte alles wunderbar. Die Frage ist letztendlich was dafür Verantwortlich ist, dass es eben so jetzt nicht mehr funktioniert.
Das ist eine veraltete Regel, die für HDD und deren free space fragmentation performance basierte. Die Regel war damals schon eher so mäh.

Was für ein RAID hast du genau?


Vermute mal CT Volumes. Was siehst du dort in Bild 2?

Genau genommen habe ich kein Raid sondern einen Mirror. Was mich dazu bewogen hat kann ich nicht mehr nachvollziehen, da
auf dem System lediglich Filme/Serien sind welche jederzeit wieder besorgt werden können.

Hab unten mal ein Bild von dem CT Volume eingefügt.

Das wurde von mir so ca. vor einem Jahr alles erstellt und lief dann Monatelang vor sich hin.
Ich weiß das ist nicht optimal aber ich gebe die Hoffnung nicht auf mit Hilfe das Ganze zu retten.
 

Attachments

  • Bild 3.png
    Bild 3.png
    252.7 KB · Views: 7
  • Bild 4.png
    Bild 4.png
    133.9 KB · Views: 7
Es ist mir vorher nicht aufgefallen aber du nutzt ein Directory Storage und daher auch eine Datei basierte .raw Disk :|
Das ist blöd weil das kein Dataset ist wie es bei ZFS sein sollte und auch keine Snapshots oder andere feine ZFS features unterstützt. Discard funktioniert nicht richtig und Langsam ist es teils auch.
Ich würde ein ZFS Storage erstellen und sie dorthin verschieben. Es ist auch keine gute Idee einer Disk mehr Platz zuzuweisen als du insgesamt hast.

Schau mal ob das etwas hilft
Bash:
pct list | awk '/^[0-9]/ {print $1}' | while read ct; do pct fstrim ${ct}; done

Ich würde auch mal das innerhalb des Containers laufen lassen (debian/ubuntu) und schauen ob du etwas löschen kannst
Bash:
df -hT
apt install gdu -y
gdu /
 
Last edited:
  • Like
Reactions: IsThisThingOn
Erstmal vielen Dank für deine Hilfe aber leider führte bis hierhin kein Ansatz zum Erfolg.


Es ist mir vorher nicht aufgefallen aber du nutzt ein Directory Storage und daher auch eine Datei basierte .raw Disk :|
Das ist blöd weil das kein Dataset ist wie es bei ZFS sein sollte und auch keine Snapshots oder andere feine ZFS features unterstützt. Discard funktioniert nicht richtig und Langsam ist es teils auch.
Ich würde ein ZFS Storage erstellen und sie dorthin verschieben. Es ist auch keine gute Idee einer Disk mehr Platz zuzuweisen als du insgesamt hast.

Schau mal ob das etwas hilft
Bash:
pct list | awk '/^[0-9]/ {print $1}' | while read ct; do pct fstrim ${ct}; done

Ich würde auch mal das innerhalb des Containers laufen lassen (debian/ubuntu) und schauen ob du etwas löschen kannst
Bash:
df -hT
apt install gdu -y
gdu /

Mit fstrim konnten so um die 20GB freigeschaufelt werden, was allerdings immer noch nicht reicht.

Habe mal noch ein paar Screenshoots von den einzelnen Containern gemacht. Ich kann darin nichts finden von enormer Größe, außer dem data Ordner, in welchem sich meine Filme/Serien befinden.

Wenn ich jetzt einen neuen ZFS Storage anlege dann sind die Daten auf dem Mirror wahrscheinlich weg oder ?
Und gibt es eine Möglichkeit die zwei HDD´s zu einer zusammen zu fassen ? Ich benötige eigentlich weder einen Mirror oder sonstige Backups davon.

Ich meine klar der Rechner wird erstmal eine Zeit lang glühen bis die Filme und Serien beisammen sind aber das wäre zu vernachlässigen.
Es geht mir Primär darum, nicht wieder Proxmox samt den Containern und allen Einstellungen aufsetzen zu müssen.

Sollte das ganze aber in irgendeiner Art und Weise zu retten sein, bin ich für weitere Vorschläge dankbar.
 

Attachments

  • Bild Proxmox.png
    Bild Proxmox.png
    343.7 KB · Views: 5
  • Bild 100.png
    Bild 100.png
    351.7 KB · Views: 5
  • Bild 101.png
    Bild 101.png
    358.8 KB · Views: 4
  • Bild 102.png
    Bild 102.png
    345.7 KB · Views: 5
Hallo,
da du eine VDEV als ZFS Mirror mit 2x HDDs hast, kann du das einmalig auflössen über die Konsole.
Dadruch verliert man die Redundanz (Mirror, Raid1) und die Sicherheit!

zfs detach IronWolf ata-ST4000N001-2MA101_<seriennummer>-part1

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-detach.8.html

Danach ist die Disk IronWolf ata-ST4000N001-2MA101_<seriennummer>-part1 nicht mehr Teil des ZFS Pools IronWolf und kann als VDEV ZFS stripe zum IronWolf hinzugefügt werden.

Dadurch verdoppelt sich die Größe des Pools.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-add.8.html

Aber man kann danach wieder den ZFS Pool IronWolf absichern, indem man zwei weitere gleiche Festplatten Irnwolf ST4000N001 wieder einspiegelt.

Dann erhält man eine Art Raid10 mit VDEV0 ZFS Mirror-0, VDEV1 ZFS Stripe und VDEV2 ZFS Mirror-1.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-attach.8.html

Das geht ohne Datenverlust, wenn man sich die Mühe macht das auszuprobieren.
Z.B. mit 2x SSD.
 
Lass auch mal laufen zpool trim IronWolf und zpool scrub IronWolf vorher zum aufräumen.
Der zpool scrub lauf, wird ein paar Stunden brauchen.
 
Last edited:
Hallo,
da du eine VDEV als ZFS Mirror mit 2x HDDs hast, kann du das einmalig auflössen über die Konsole.
Dadruch verliert man die Redundanz (Mirror, Raid1) und die Sicherheit!

zfs detach IronWolf ata-ST4000N001-2MA101_<seriennummer>-part1

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-detach.8.html

Danach ist die Disk IronWolf ata-ST4000N001-2MA101_<seriennummer>-part1 nicht mehr Teil des ZFS Pools IronWolf und kann als VDEV ZFS stripe zum IronWolf hinzugefügt werden.

Dadurch verdoppelt sich die Größe des Pools.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-add.8.html

Aber man kann danach wieder den ZFS Pool IronWolf absichern, indem man zwei weitere gleiche Festplatten Irnwolf ST4000N001 wieder einspiegelt.

Dann erhält man eine Art Raid10 mit VDEV0 ZFS Mirror-0, VDEV1 ZFS Stripe und VDEV2 ZFS Mirror-1.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-attach.8.html

Das geht ohne Datenverlust, wenn man sich die Mühe macht das auszuprobieren.
Z.B. mit 2x SSD.

Ich werde mir für nächste Woche eine externe HDD bestellen und die Daten dann doch erstmal sichern.
Denke das macht Sinn, so kann ich in Ruhe "ausprobieren" und das ganze vernünftig einrichten.
Für die Container sind backups bereits vorhanden, im schlimmsten Fall kann ich Proxmox neu aufsetzen.
 
Also nichts mit alten Regeln, er erfährt nun real, was passiert, wenn es für die Meta- Und Daten eng wird!
Naja, bei HDD hast du halt bereits ab 50% Platte voll eine Performance Einbusse, wenn du sie für blockstorage verwendest.
Einem RAIDZ2 mit 80 TB ist es hingegen ziemlich schnuppe, ob der pool bereits mit 90% (also 72TB) gefüllt ist.

Darum war die Regel halt schon immer Schwachsinn.