Festplatte voll obwohl noch Speicherplatz da ist (volume1)

[Whitesheep]

Hi,

Ich habe aktuell immer wieder ein Problem mit meiner Syno und finde keine Lösung außer einen Neustart, der dann für ein paar Tage hilft.

Die Syno “denkt” das volume1 voll ist was aber nicht stimmt.

Filesystem          Size  Used Avail Use% Mounted on
/dev/md0            2.3G  1.2G  1.1G  51% /
none                7.9G     0  7.9G   0% /dev
/tmp                7.9G  1.1M  7.9G   1% /tmp
/run                7.9G  4.3M  7.9G   1% /run
/dev/shm            7.9G  4.0K  7.9G   1% /dev/shm
none                4.0K     0  4.0K   0% /sys/fs/cgroup
cgmfs               100K     0  100K   0% /run/cgmanager/fs
/dev/md3            139G   23G  116G  17% /volume5
/dev/vg1/volume_1    29G   11G   18G  38% /volume1
/dev/vg1/volume_10  2.8T  1.2T  1.6T  45% /volume10
/dev/vg1/volume_6   192G  158G   35G  83% /volume6
/dev/vg1/volume_2   2.4T  938G  1.5T  40% /volume2
/dev/vg1/volume_7   1.9T  1.6T  320G  84% /volume7
/dev/vg1/volume_8   912G   86G  827G  10% /volume8
/dev/vg1/volume_3   912G  400G  513G  44% /volume3
/dev/vg1/volume_9   912G  499G  414G  55% /volume9
/dev/vg1/volume_4   624G  607G   18G  98% /volume4
/dev/vg1/volume_1    29G   11G   18G  38% /opt

Wenn dieser Zustand erreicht ist fangen an Services wie cloudsync oder hypberbackup abzustürzen und lassen sich auch nicht mehr starten auch kann ich nicht mehr auf das volume1 schreiben werder über vi, nfs, smb oder sonstiges überall bekomme ich den Fehler das die Festplatte voll ist.

Das einzige was den Fehler zeitweise behebt ist ein Neustart der syno.

Hat jemand eine Idee was das Problem sein könnte?

 

[Syno-OS]

und was sagt 'mount'?
Volume1 'ro' oder 'rw' eingebunden?
11GB ist nicht gerade 'viel' Platz in der heutigen Zeit

 

[Whitesheep]

/dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)

mount sagt rw wobei ich den ssd flag nicht nachvollziehen kann da es keine SSD's sind

 

[Whitesheep]

Mir ist grade eingefallen es gab mail einen SSH Cache kann sein dass das SSD Flag noch von dieserzeit übrig ist

 

[Whitesheep]

Ich weis nicht ob die info was hilft aber vielleicht kann damit jemand was anfangen

Mit "touch" kann man noch files erstellen. moven kann ich sie aber nicht. Und der error output vom mv kann komische zeichen mit drin.

root@hssynonode-p01 [/volume1]
$ touch test
root@hssynonode-p01 [/volume1]
$ ls -la
total 29112
drwxr-xr-x   1 root         root              896 Sep 15 15:00 .
drwxr-xr-x  34 root         root             4096 Sep 15 14:46 ..
drwxr-xr-x   1 ActiveBackup ActiveBackup      354 Sep 15 11:35 @ActiveBackup
-rw-------   1 root         root         10545435 Jul 21 14:58 @apprise.core.gz
drwxr-xr-x   1 root         root              110 Sep  8 13:57 @appstore
-rw-------   1 root         root             5635 Jul 15 21:08 @check_by_ssh.core.gz
-rw-------   1 root         root            41606 Jul 15 22:23 @check_ping.core.gz
drwxr-xr-x   1 root         root               56 Sep  8 13:57 @cloudsync
drwxr-xr-x   1 root         root               18 Jul  5 01:30 @database
drwx--x--x   1 root         root                0 Aug 18 22:39 @docker
drwxrwxrwx+  1 root         root               48 Sep 15 02:17 @eaDir
-rw-------   1 root         root            46598 Jul  8 10:19 @find.core.gz
drwxrwxrwx   1 root         root              672 Jul  9 08:44 @img_bkp_cache
-rw-------   1 root         root            91553 Jul 21 15:10 @master.core.gz
-rw-------   1 root         root           199474 Jul 21 14:49 @nagios.core.gz
d---------+  1 root         root               12 Jul 22 15:25 NetBackup
-rw-------   1 root         root            29390 Jul  8 10:19 @notify-service-.core.gz
d---------+  1 root         root              164 Jul 24 11:11 opt
-rw-------   1 root         root            21496 Jul 15 22:21 @ping.core.gz
-rw-------   1 root         root            14765 Jul 21 15:10 @runsv.core.gz
drwxr-xr-x   1 root         root               24 Jul  5 01:30 @S2S
drwxr-xr-x   1 root         root               72 Sep 15 02:17 @sharesnap
-rw-------   1 root         root             5356 Jul 15 22:23 @sh.core.gz
-rw-------   1 root         root          9711758 Sep 15 11:42 @syno-cloud-sync.core.gz
-rw-------   1 root         root          1856273 Sep 15 12:55 @syslog-ng.core.gz
-rw-------   1 root         root          1514678 Aug 17 09:51 @syslog-ng.core.gz.11677
-rw-------   1 root         root           629241 Aug 17 09:52 @syslog-ng.core.gz.19575
-rw-------   1 root         root           719218 Aug 18 13:10 @syslog-ng.core.gz.25167
-rw-------   1 root         root           758899 Aug 17 10:00 @syslog-ng.core.gz.28080
-rw-------   1 root         root          1750697 Sep 15 14:59 @syslog-ng.core.gz.32440
-rw-------   1 root         root          1819048 Sep 15 14:11 @syslog-ng.core.gz.9956
-rw-r--r--   1 root         root                0 Sep 15 15:00 test
drwxrwxrwt   1 root         root               36 Sep 15 11:44 @tmp
root@hssynonode-p01 [/volume1]
$ mv test test.txt
mv: cannot move âtestâ to âtest.txtâ: No space left on device

 

[Whitesheep]

Habe die Syno jetzt mal wieder neugestartet und direkt in die /var/log/messages geschaut.
Die ersten "No space left on device" sind bereits beim Booten zu finden.

1.
mv: cannot move '/volume1/@tmp' to '/volume1/@tmp.del/1600182259': No space left on device

2.
2020-09-15T17:05:37+02:00 hssynonode-p01 synoimgbkptool: [18626]repository.cpp:2208 Error: rename /volume1/@img_bkp_cache/@eaDir/@tmp to /volume1/@img_bkp_cache/@eaDir/@tmp.clear/JGccJ4 failed
2020-09-15T17:05:37+02:00 hssynonode-p01 synoimgbkptool: Error: No space left on device

Habe mir daraufhin mal die Ordner angeschaut die er moven wollte und keiner von beiden ist "zu groß" beide haben weniger als 500MB was bei 18GB freiem Speicher kein Problem sein sollte.

Spoiler: du output

root@hssynonode-p01 [/volume1]
$ du -sh ./*
52M     ./@ActiveBackup
12K     ./@S2S
11M     ./@apprise.core.gz
463M    ./@appstore
8.0K    ./@check_by_ssh.core.gz
44K     ./@check_ping.core.gz
470M    ./@cloudsync
4.0K    ./@database
0       ./@docker
420K    ./@eaDir
48K     ./@find.core.gz
234M    ./@img_bkp_cache
92K     ./@master.core.gz
196K    ./@nagios.core.gz
32K     ./@notify-service-.core.gz
24K     ./@ping.core.gz
16K     ./@runsv.core.gz
8.0K    ./@sh.core.gz
8.0K    ./@sharesnap
9.3M    ./@syno-cloud-sync.core.gz
904K    ./@synoabk-ctl.core.gz.18099
1.8M    ./@syslog-ng.core.gz
1.5M    ./@syslog-ng.core.gz.11677
616K    ./@syslog-ng.core.gz.19575
704K    ./@syslog-ng.core.gz.25167
744K    ./@syslog-ng.core.gz.28080
1.7M    ./@syslog-ng.core.gz.32440
1.8M    ./@syslog-ng.core.gz.9956
0       ./@tmp
0       ./NetBackup
13G     ./opt

Habe mal das Logfile angehängt vielleicht findet ja jemand etwas das weiter hilft.

Danke schon mal an alle die einen Blick rein werfen.

 

[Whitesheep]

Habe noch etwas gefunden...
Möglicherweise das problem? Habe aber noch nichts gefunden um es zu bestätigen oder zu lösen.


$ btrfs filesystem df /volume1
Data, single: total=24.21GiB, used=6.37GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=2.88GiB, used=2.84GiB
GlobalReserve, single: total=38.11MiB, used=0.00B

 

[Whitesheep]

Sieht aus als wäre es das gewesen...
Nachdem ich per Google nichts gefunden habe wie man Manuel den Metadata bereich vergrößern kann ohne das volume neu zu bauen habe ich das Logfile Archiv das auf volume1 lag auf ein anders volume gemoved. Um so extrem viele kleine datein von dem volume zu bekommen.
Dies brachte 1.2GiB an Metadata Speicher zurück und nach einem erneuten reboot läuft die Syno wieder sauber, ohne fehler in /var/log/messages.
Für die Logfiles werde ich jetzt ein ext4 volume anlegen da btrfs scheinbar nicht für große mengen kleiner files geeignet ist zumindest nicht auf der Syno.

Hoffe es hilft jemandem der auf das selbe problem stößt.