DSM 6.x und darunter DiskStation 218+ Speicher wird nicht freigegeben (alle Papierkörbe leer, keine Snapshots, keine Cloud)

[the quick brown fox]

Hallo,

Ich habe auf volume1 meiner DS drei Geteilte Ordner. "Server" (143GB), "Server 2" (94GB) und "Archiv" (1.6tb). Die Festplatte hat eine Kapazität von 5.3tb. Trotzdem habe ich nur noch 277GB frei auf dem volume. Ich habe alle Papierkörbe deaktiviert, die @recycle Ordner gelöscht, alle Snapshots entfernt, aber es wird einfach kein Speicher freigegeben. Ich nutze keine Synology Cloud (App ist garnicht installiert). Ich habe schon eine Datenbereinigung durchgeführt und das Gerät neu gestartet, ohne Ergebnis.

DSM 6.2.4-25556

 

[Fusion]

Welche Apps sind denn installiert?

 

[the quick brown fox]

Nur die Basis-Apps. Systemsteuerung, EZ-Internet, DSM Hilfe, Paket-Zentrum-Ressourcen-Monitor, Speichermanager, Protokoll-Center, Sicherheitsberater, Support-Center, iSCSI Manager, Filestation, OAuth Service, Snapshot Replication.

EDIT: Habe mich per shell angemeldet. Das Terminal gibt bei "du -sh" für die Ordner die gleiche Datengröße an, wie die DSM-Oberfläche. Viel mehr kann ich nicht erfahren, weil sämtliche Disktools wie lsblk nicht installiert sind.

 

[peterhoffmann]

Check der Größen auf /volume* :

du -hd 1 /volume*/ | sort -h -r

 

[Fusion]

Habe primär nachgefragt, weil viele sagen 'cloud station nicht installiert' und nachher stellt sich raus, dass sie Drive Server installiert haben, was das gleiche in grün ist.

Nach der Auflistung bliebe fast nur noch snapshots die gelöscht und doch (noch) nicht gelöscht sind.

 

[the quick brown fox]

Da bekomme ich jede Menge stale file handle und permission denied errors und die Größen stimmen überhaupt nicht.

725G /volume1/
724G /volume1/Archiv-3
901M /volume1/Server
84M /volume1/@appstore
26M /volume1/@tmp
8.7M /volume1/@SynoFinder-log
112K /volume1/@USBCopy
76K /volume1/@eaDir
48K /volume1/Server 2
44K /volume1/@S2S
24K /volume1/@sharesnap
24K /volume1/@database
12K /volume1/@SynoFinder-etc-volume
0 /volume1/NetBackup
0 /volume1/@autoupdate

 

[Fusion]

Bist du per 'sudo -i' als root Benutzer unterwegs? Dann sollten die Fehlermeldungen nicht kommen.

 

[the quick brown fox]

Cloud Station und Drive Server waren nie installiert auf dieser DS.

Hier mal der Inhalt von volume1:

total 8796
drwxr-xr-x 1 root root 340 Apr 22 09:41 .
drwxr-xr-x 24 root root 4096 Apr 22 09:41 ..
drwxr-xr-x 1 root root 76 Mar 30 12:11 @appstore
drwxrwxrwx+ 1 root root 46 Apr 22 09:43 Archiv-3
drwx------ 1 root root 0 Apr 20 16:50 @autoupdate
-rw------- 1 root root 323195 Apr 21 12:54 @cnid_dbd.core.gz
drwxr-xr-x 1 root root 76 Apr 17 2020 @database
drwxrwxrwx+ 1 root root 124 Apr 22 10:15 @eaDir
drwxrwxrwx+ 1 root root 12 Nov 16 14:08 NetBackup
drwxr-xr-x 1 root root 88 Apr 22 09:41 @S2S
drwxrwxrwx+ 1 root root 670 Apr 22 10:43 Server
drwxrwxrwx+ 1 root root 140 Apr 22 10:43 Server 2
drwxr-xr-x 1 root root 124 Apr 22 10:15 @sharesnap
-rw------- 1 root root 8679367 Jan 21 18:35 @synocontentextr.core.gz
drwxr-xr-x 1 SynoFinder SynoFinder 50 Apr 20 16:56 @SynoFinder-etc-volume
drwxr-xr-x 1 root root 404 Apr 21 16:17 @SynoFinder-log
drwxrwxrwt 1 root root 34 Apr 22 10:15 @tmp
drwxr-xr-x 1 root root 12 May 4 2020 @USBCopy

Ich finde in keinem der geteilten Ordner irgendwelche Snapshots.

 

[Fusion]

Mal noch 'df -lah'

 

[the quick brown fox]

Bist du per 'sudo -i' als root Benutzer unterwegs? Dann sollten die Fehlermeldungen nicht kommen.

Sorry, gleiches Ergebnis. Leider.

 

[the quick brown fox]

Mal noch 'df -lah'

root@DiskStation:~# df -lah
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 997M 1.2G 45% /
none 911M 0 911M 0% /dev
none 0 0 0 - /dev/pts
none 0 0 0 - /proc
none 0 0 0 - /sys
/tmp 915M 1.5M 913M 1% /tmp
/run 915M 3.8M 911M 1% /run
/dev/shm 915M 4.0K 915M 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
cgroup 0 0 0 - /sys/fs/cgroup/cpuset
cgroup 0 0 0 - /sys/fs/cgroup/cpu
cgroup 0 0 0 - /sys/fs/cgroup/cpuacct
cgroup 0 0 0 - /sys/fs/cgroup/blkio
cgroup 0 0 0 - /sys/fs/cgroup/memory
cgroup 0 0 0 - /sys/fs/cgroup/devices
cgroup 0 0 0 - /sys/fs/cgroup/freezer
none 911M 0 911M 0% /proc/bus/usb
none 0 0 0 - /sys/kernel/debug
securityfs 0 0 0 - /sys/kernel/security
/dev/md2 5.3T 5.0T 278G 95% /volume1
/dev/md3 5.3T 2.9T 2.4T 55% /volume2
none 0 0 0 - /config

 

[Fusion]

Also 2 Festplatten mit eigenem Speicherpool und Volume?

Und welche Fehler bekommst du konkret bei der Ansicht nach?
du -xhd 1 /volume1/ | sort -h -r

 

[the quick brown fox]

Also 2 Festplatten mit eigenem Speicherpool und Volume?

Und welche Fehler bekommst du konkret bei der Ansicht nach?
du -xhd 1 /volume1/ | sort -h -r

Ja, zwei Festplatten mit jeweils eigenem Pool, ganz Basic.

Hier die Ausgabe:

root@DiskStation:~# du -xhd 1 /volume1/ | sort -h -r
du: cannot access ‘/volume1/@database/synolog/.WEBDAVXFERDB’: Stale file handle
127M /volume1/
84M /volume1/@appstore
26M /volume1/@tmp
8.7M /volume1/@SynoFinder-log
112K /volume1/@USBCopy
76K /volume1/@eaDir
44K /volume1/@S2S
28K /volume1/@database
12K /volume1/@SynoFinder-etc-volume
0 /volume1/@autoupdate
root@DiskStation:~#

 

[Fusion]

Kannst mal nur 'du -xhd 1 /volume1' machen, irgendwie gefällt mir die Ausgabe nicht.

 

[the quick brown fox]

Kannst mal nur 'du -xhd 1 /volume1' machen, irgendwie gefällt mir die Ausgabe nicht.

Okay, selbes Ergebnis, Reihenfolge anders.

root@DiskStation:~# du -xhd 1 /volume1
du: cannot access ‘/volume1/@database/synolog/.WEBDAVXFERDB’: Stale file handle
28K /volume1/@database
8.7M /volume1/@SynoFinder-log
44K /volume1/@S2S
76K /volume1/@eaDir
84M /volume1/@appstore
112K /volume1/@USBCopy
0 /volume1/@autoupdate
12K /volume1/@SynoFinder-etc-volume
26M /volume1/@tmp
127M /volume1

 

[Fusion]

Man sollte das nicht nebenher machen. Hätte mich gewundert wieso nur die @ Objekte aufgetaucht sind, aber bei Parameter X (one Filesystem) kein Wunder.
Aber den 'du -hd 1 /volume1' hatten wir ja glaube schon.

Nur komisch, dass man die Differenz bei dir nicht sieht. Bei mir ist die Belegung zwischen df und du übereinstimmend.

 

[the quick brown fox]

Man sollte das nicht nebenher machen.

Das kann man sagen. Mein Kollege (die DS bedient zwei Arbeitsplätze) wird ganz nervös, wenn er grüne Ziffern auf meinem Bildschirm sieht im Wissen, dass ich da irgendetwas an unserem Dateiserver fummel. Nicht ganz unberechtigt, mein Wissensstand hat den Level "genug um gefährlich zu sein und Dinge kaputt zu machen."
So wie es aussieht werde ich mein Problem nicht los, zumindest nicht ohne den laufenden Arbeitsbetrieb zu gefährden. Es läuft auf Wochenendarbeit hinaus. Im schlimmsten fall muss ich Pool1 neu anlegen. Man hat ja Backups. Leider haben wir sehr viel Kleinkram im Datenbestand, das dauert immer ewig per rsync.
Ich danke dir soweit schonmal vielmals für deine Unterstützung!

 

[stefan_lx]

hast du im iSCSI-Manager irgendwelche LUNs erstellt?
die nehmen zwar mehr oder weniger Platz weg, aber sind nicht direkt in der Oberfläche zu sehen...

Stefan

 

[Fusion]

Also bis auf den @sharesnap stimmen bei mir die Belegungszahlen. Dort zeigt er wegen der ganzen btrfs ref-links eine utopische Belegung von 17T auf einem 9T Volumen an.
Aber den Ordner hattest du ja glaube schon geprüft.

Den iSCSI Gedanken hatte ich auch, hatte ihn aber vorher verworfen, da der ja default installiert ist auch wenn man ihn nicht nutzt. Aber @stefan_lx ist definitiv besser nachzufragen.

 

[the quick brown fox]

hast du im iSCSI-Manager irgendwelche LUNs erstellt?
die nehmen zwar mehr oder weniger Platz weg, aber sind nicht direkt in der Oberfläche zu sehen...

Stefan

Nein, leider auch nicht. Es ist einfach mehr als merkwürdig alles. Es war so, dass ich per Filestation einen großen Stapel Files aus dem Recycle-Ordner entfernt habe (entfernen wollte?), was erst sehr lange gedauert hat, mit sehr langsamem Fortschritt. Aber plötzlich war er dann mittendrin auf einmal fertig und die Dateien verschwunden. Nur der Speicher war immer noch belegt. Dachte erst das wär lediglich ein Problem mit DSM, aber der Speicher ist laut entsprechender terminalausgabe ja tatsächlich noch belegt.
Ich habe soetwas noch nie erlebt, aber auch noch nie mit einem Dateisystem wie ZFS oder Btrfs gearbeitet. Aber ich werde das Problem heute per Neuanlegen des Pools und Neuaufspielen der Daten beseitigen und hoffen, dass das nicht nochmal passiert. In Zukunft werde ich es tunlichst vermeiden, irgendwelche Dateioperationen in der Filestation zu erledigen.