Fehlender Speicherplatz beim ugreen Nas

[atze peng]

Hallo, ich habe mir ein Ugreen DXP4800 gekauft und bin soweit ganz zufrieden. Allerdings habe ich eine komischen Fehler.

Eins vorab: ich habe diesen Text bereits in einem ugreen Forum gepostet, dort aber keine Antwort erhalten. Vielleicht hat ja hier jemand eine Idee.

Aktuell habe ich eine HDD (6tb) für Daten. Diese wird noch zu einem RAID 1 mit einer weiteren 6tb HDD ergänzt wenn der Umzug aufs neue Nas abgeschlossen ist, aktuell steckt die noch im alten Nas. Zusätzlich habe ich eine neue 512gb SATA SSD hier zu liegen und wollte dir für die Apps nutzen. Also beide als einzelne volumes mit btrfs eingerichtet.

Aktuell habe ich meine Fotos mit auf die SSD gezogen damit sie mir in der Fotos App angezeigt werden. Allerdings fehlt mir irgendwie Speicherplatz. Auf der SSD sind ein paar wenige Apps installiert, unter anderem docker mit homeassistant und paperless. Die sind aktuell nur installiert, aber nicht eingerichtet und haben keine Daten erhalten.

Die Fotos nehmen 320gb ein. Allerdings habe ich jetzt eine Warnung erhalten, dass die SSD voll ist. Wenn ich auf Speicher gehe und mir die Verwendung der SSD anzeigen lassen sagt er, dass 320gb im Benutzerordner genutzt werden, das sind meine Fotos. Im freigegebenen Ordner sind es 1 mb und sonstige sind 10,7gb, das werden denke ich die Apps und docker sein.

Trotzdem zeigt er mir an, dass 461,5gb verwendet werden. Es sind keine snapshots oder sonstiges aktiviert und ich sehe auch keine andere Möglichkeit wo der Speicher hin sein könnte. Oder nehmen sie Miniaturansichten von den Fotos stolze 140gb ein, die mir nicht angezeigt werden?

Die Fotos und sync&backup app haben sich selbst ausgeschaltet (liegen beide auf der SSD). Wenn ich die starte dauert es ewig bin mir eine Fehlermeldung (Fehlschlag) gegeben wird. Ich habe testweise virtuelle Maschine deinstalliert (wurde noch nicht genutzt) und nach kürzester Zeit war der frei gewordene Speicherplatz wieder belegt.

 

[F1database]

Ich kenne Ugreen jetzt nicht konkret, aber bei einem Freund mit Synology war der Speicherfresser der Papierkorb der nicht geleert worden ist.
Eventuell auch hier ein Thema?

 

[KnolleJupp]

Beachtest du auch den Unterschied zwischen Gigabyte und Gibibyte:
Real nutzbar hat eine 512GB SSD "nur" ca. 476,8GB, abzüglich was das Dateisystem usw. davon noch selber verbraucht.

Wenn du da 320GB Fotos drauf hast, bleiben noch 156,8GB übrig usw.

Das Btrfs Dateisystem arbeitet zudem mit sogenannten Snapshots und die können u.U. viel Platz belegen, wenn man sie nicht bereinigt.

 

[atze peng]

Alle Papierkörbe sind leer, snapshots wurden keine erstellt und ich sehe auch keine Möglichkeit die zu bereinigen.

Dass bei einer 512gb Platte nicht 512gb belegt werden können ist mir klar. Allerdings sind wie beschrieben die kompletten 461 GB belegt obwohl die Fotos nur 320 GB einnehmen und sonst nur ca 10 GB für den Rest genutzt werden, bleibt also ein Delta von ca 130 GB.

 

[gaym0r]

Beachtest du auch den Unterschied zwischen Gigabyte und Gibibyte:
Real nutzbar hat eine 512GB SSD "nur" ca. 476,8GB

Hm? Meinst du 476 GiB? Ansonsten macht die Aussage nicht viel Sinn. Und solange Ugreen nicht den gleichen Quatsch wie Windows macht (Mit Gibibyte rechnen, aber Gigabyte anzeigen), ist das eher nicht das Problem.

 

[atze peng]

Dort steht nur GB. Ob es nachher die Abkürzung für Gibibyte oder Gigabyte ist, ist doch auch vollkommen egal.
Kapazität des Datenträgers: 461,5GB
Fotos: 320,9GB
Sonstiges: 10,7GB
Verfügbar: 64KB

 

[Mr. Poe]

hmmm, wird die ssd vllt als cache für die hdds benutzt und die 140gb sind reservierter speicher für den cache?

 

[atze peng]

Nein, kein Cache eingerichtet.

 

[JumpingCat]

Kannst du per ssh auf die Kiste und dich mit du durchhangeln?

 

[atze peng]

Ich kann per SSH drauf zugreifen, habe damit aber keine Erfahrung.

 

[Krik]

Greife per SSH darauf zu und dann sieh dich um. Meine Beispiele unten habe ich von meiner DXP2800 kopiert. Das sollte alles bei dir genau gleich funktionieren.

Kurze Übersicht:
du - disk usage - verbrauchten Speicherverbrauch anzeigen
df - disk free - freien Speicherplatz anzeigen

Erst mal schauen, wo wie viel belegt ist:
df -hl
-h bedeutet, die Größen in von Menschen lesbaren Format angezeigt zu bekommen (also z. B. 2K statt 2048)
l bedeutet, dass er nur lokale Dateisysteme anzeigt.

krik@Alpha:~$ df -hl
Filesystem                                      Size  Used Avail Use% Mounted on
udev                                            3.8G     0  3.8G   0% /dev
tmpfs                                           770M   12M  758M   2% /run
/dev/mmcblk0p4                                  959M  959M     0 100% /rom
/dev/mmcblk0p6                                  3.9G  2.5G  1.3G  68% /ugreen
/dev/mmcblk0p1                                  256M  123M  133M  49% /boot
overlay                                          19G  959M   17G   6% /
tmpfs                                           3.8G  1.1M  3.8G   1% /dev/shm
tmpfs                                           5.0M     0  5.0M   0% /run/lock
efivarfs                                        192K   88K  100K  47% /sys/firmware/efi/efivars
tmpfs                                           3.8G  5.3M  3.8G   1% /tmp
/dev/mmcblk0p7                                   19G  959M   17G   6% /overlay
/dev/mmcblk0p3                                  8.6M   31K  7.8M   1% /mnt/factory
tmpfs                                           1.0G     0  1.0G   0% /var/lib/nginx
/dev/mapper/ug_751D11_1760719433_pool1-volume1  7.5T  2.3T  5.3T  30% /volume1
/dev/mapper/ug_751D11_1760719433_pool1-volume1  7.5T  2.3T  5.3T  30% /home
tmpfs                                           770M     0  770M   0% /run/user/1000

Meine Platten sind unter /volume1 und /home gemountet, wie bei dir wahrscheinlich auch. Wie man links am Namen erkennt, sind das die gleichen Platten bzw. der gleiche Speicherpool.

Ok, jetzt schau ich im /volume1-Verzeichnis nach, wo die Speicherfresser sind.
du -h --max-depth 1 /volume1 | sort -h
-h bedeutet, die Größen in von Menschen lesbaren Format angezeigt zu bekommen (also z. B. 2K statt 2048)
--max-depth 1 bedeutet, dass er nur ein Verzeichnis in die Tiefe geht und ausgibt
/volume1 ist der Ort, wo er gucken soll
| nimmt die Ausgabe vom Programm von der linken Seite und leitet sie an das Programm auf der rechten Seite als Eingabe weiter
sort -h nimmt das Ergebnis von du und sortiert es nach der Größe, wobei auf das von Menschen lesbare Format geachtet wird (also 2K sind weniger als 10G)
Streng genommen kannst du den | sort -h-Teil weglassen. Er macht es aber einfacher, die Ausgabe zu erfassen.

krik@Alpha:~$ du -h --max-depth 1 /volume1 | sort -h
du: cannot read directory '/volume1/@tmp': Permission denied
du: cannot read directory '/volume1/@docker': Permission denied
du: cannot read directory '/volume1/@FileManager': Permission denied
du: cannot read directory '/volume1/@thumbnail': Permission denied
du: cannot read directory '/volume1/@exif': Permission denied
du: cannot read directory '/volume1/@uninstall': Permission denied
du: cannot read directory '/volume1/@search': Permission denied
du: cannot read directory '/volume1/@syncbackup/cache/f7d247c90afb4d3ea77079c4a8657ac2/d2ceb5c7a3868aef7f1772bdbcfbc9f0a6113caa576a5cc7c35b8e28deb5dcf1': Permission denied
0       /volume1/@docker
0       /volume1/@exif
0       /volume1/@FileManager
0       /volume1/Scans
0       /volume1/@thumbnail
0       /volume1/@tmp
0       /volume1/@uninstall
0       /volume1/@upload
4.0K    /volume1/@search
4.0K    /volume1/@syncbackup
8.0K    /volume1/Downloads
847M    /volume1/@appstore
1.1G    /volume1/docker
47G     /volume1/Bilder
2.2T    /volume1
2.2T    /volume1/@home

Die Rechte-Fehler kannst du beheben, in dem du vor dem ganzen Kram noch ein sudo schreibst. Er verlangt dann, dass du dich mit deinem Passwort nochmal identifizierst.
sudo du -h --max-depth 1 /volume1 | sort -h


Jetzt weiß ich, dass in @home der meiste Speicherplatz verbraucht wird. Gut, gehen wir mal etwas mehr in die Tiefe, um die Speicherfresser zu identifizieren.

krik@Alpha:~$ du -h --max-depth 2 /volume1/@home | sort -h
0       /volume1/@home/krik/.local
4.0K    /volume1/@home/krik/#recycle
4.0K    /volume1/@home/<zensiert>
4.0K    /volume1/@home/<zensiert>/#recycle
322M    /volume1/@home/krik/Dokumente
33G     /volume1/@home/<zensiert>
33G     /volume1/@home/<zensiert>/#recycle
105G    /volume1/@home/krik/Lesestoff
825G    /volume1/@home/krik/Media
1.3T    /volume1/@home/krik/Software
2.2T    /volume1/@home
2.2T    /volume1/@home/krik

Und dann hangelst du dich so lang.

 

[atze peng]

Ich habe eine Antwort vom Ugreen Support bekommen. Nach dem Einschicken eines Diagnoseprotokolls kam bei raus, dass es Probleme mit btrfs gab.

Ich habe die ssd formatiert und auf Empfehlung vom Support auf exf4 umgestellt. Nun scheint alles zu funktionieren. Ist schon echt lächerlich, dass deshalb innerhalb von zwei Tagen über 28% des Speichers belegt werden.

Hier die Erklärung des Supports:



Sehr geehrter Kunde,

vielen Dank für Ihre Rückmeldung.

In bestimmten Szenarien, insbesondere auf kleineren SSDs, auf denen mehrere Anwendungen, Docker-Container, Indexierungsdienste oder Foto-Miniaturbilder laufen – kann Btrfs im Hintergrund zusätzliche Metadaten- oder Datenblöcke anlegen. Dadurch kann es dazu kommen, dass die sichtbare Dateigröße deutlich kleiner ist als die tatsächlich belegte Speichermenge – genau wie in Ihrem Fall.

Wenn Sie weiterhin Btrfs verwenden möchten, empfehlen wir, regelmäßig einen Btrfs-Balance-Vorgang durchzuführen, besonders dann, wenn:

• viele kleine Dateien erstellt oder gelöscht werden (z. B. durch Docker, Apps, Datenbanken),
• häufig Indexierung oder die Erstellung von Miniaturbildern stattfindet.

Für SSD-Volumes, auf denen Apps oder Docker-Container installiert sind, empfehlen wir ext4, da dieses Dateisystem für solche Workloads einfacher, stabiler und wartungsärmer ist (kein regelmäßiges Balancing nötig).

Gerne unterstützen wir Sie weiter, falls Sie noch Fragen haben.

Mit freundlichen Grüßen