Festplattenplatz von /dev/md0 auf RC18015xs+ Systemen

Status
Für weitere Antworten geschlossen.

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

seit geraumer Zeit bemerken wir ein sehr merkwürdiges Phänomen in unserem RC18015xs+ HA Cluster. Die Synology Partition /dev/md0 läuft kontinuierlich "zu", bis sie voll ist, nach einem Reboot ist alles wieder "normal". Interessant dabei ist offensichtlich, dass der Plattenplatz auf der Partition nicht von Datei belegt wird, sondern die Belegung einfach von dem abweicht, was an tatsächlichen Dateien dort abgelegt ist:

bash-4.3# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.3G 886M 60% /

bash-4.3# cd/; du -h --max-depth=1 -x .
11M ./etc
9.2M ./etc.defaults
4.0K ./initrd
55M ./var
57M ./.syno
4.0K ./mnt
16K ./.system_info
32K ./.old_patch_info
4.0K ./lost+found
201M ./root
732M ./usr
5.8M ./var.defaults
1.1G .

Da fehlen glatte 200 MB. Wenn ich jetzt ein paar Tage warte, wird das mehr. Wir haben verschiedene Syno Geräte im Einsatz und bei keinem System zeigt sich dieses Verhalten.

Hat jemand eine Idee, womit das zu zusammenhängt?

Beste Grüße

Markus
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.715
Punkte für Reaktionen
1.022
Punkte
754
Was hast Du denn im root-Home (/root) liegen? 201MB würde ich da zumindest nicht erwarten.
 

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Ich habe im /root extra 200MB leere Files angelegt, die ich löschen kann, falls das Volumen wieder voll ist. So zu sagen als "Manövermasse"
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
13.999
Punkte für Reaktionen
264
Punkte
373
Hallo,
poste bitte mal ein komplettes listing von / (ls -la). Evtl. schreibt etwas in einem mount point an dem nichts hängt.

Gruß Götz
 

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo Götz,

das habe ich auch zuerst gedacht, aber leider wurde ich da eines Besseren belehrt ;(

bash-4.3# ls -la
total 72
drwxr-xr-x 21 root root 4096 Dec 7 15:47 .
drwxr-xr-x 21 root root 4096 Dec 7 15:47 ..
-rw-r--r-- 1 root root 99 Dec 5 09:18 .aha_upgrade
lrwxrwxrwx 1 root root 7 Sep 12 06:17 bin -> usr/bin
drwxr-xr-x 7 root root 0 Dec 5 09:21 config
drwxr-xr-x 12 root root 19200 Dec 5 09:23 dev
drwxr-xr-x 45 root root 4096 Dec 8 04:12 etc
drwxr-xr-x 41 root root 4096 Dec 5 09:21 etc.defaults
-rw-r--r-- 1 root root 25 Dec 5 09:20 .flash_version
drwxr-xr-x 2 root root 4096 Aug 17 00:30 initrd
lrwxrwxrwx 1 root root 7 Sep 12 06:17 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Sep 12 06:17 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 7 Sep 12 06:17 lib64 -> usr/lib
drwx------ 2 root root 4096 Aug 17 00:30 lost+found
drwxr-xr-x 2 root root 4096 Aug 17 00:30 mnt
drwxr-xr-x 3 root root 4096 Sep 12 06:17 .old_patch_info
-rw-r--r-- 1 root root 116 Jul 1 19:09 .pearrc
dr-xr-xr-x 348 root root 0 Dec 5 09:19 proc
-rw------- 1 root root 1024 Jul 1 14:57 .rnd
drwx------ 4 root root 4096 Dec 7 16:08 root
drwxr-xr-x 26 root root 1400 Dec 7 16:58 run
lrwxrwxrwx 1 root root 8 Sep 12 06:17 sbin -> usr/sbin
drwxr-xr-x 4 root root 4096 Sep 12 06:20 .syno
dr-xr-xr-x 12 root root 0 Dec 5 09:20 sys
drwxr-xr-x 2 root root 4096 Jul 1 14:57 .system_info
drwxrwxrwt 16 root root 1700 Dec 8 08:12 tmp
drwxr-xr-x 12 root root 4096 Aug 17 00:12 usr
drwxr-xr-x 17 root root 4096 Dec 5 09:22 var
drwxr-xr-x 14 root root 4096 Sep 12 06:17 var.defaults
drwxr-xr-x 1 root root 370 Dec 5 09:21 volume1

Ich ermittele gerade, um wieviel MB der Speicherplatz nun eigentlich sinkt, denn das interessante ist dass es wie gesagt nahezu identische Systeme bei uns gibt, auf denen das nicht der Fall ist.

Ich habe also irgendwie die WebStation oder MariaDB Pakete im Verdacht........ lsof wirft auch eine einige Files raus, die als "göffnet, deleted" markiert werden:

bash-4.3# lsof | grep deleted
cron 4873 root 5u REG 0,243 0 1441343 /tmp/tmpfHvp1fI (deleted)
sh 4875 root 1u REG 0,243 0 1441343 /tmp/tmpfHvp1fI (deleted)
sh 4875 root 2u REG 0,243 0 1441343 /tmp/tmpfHvp1fI (deleted)
consumer. 4880 root 1u REG 0,243 0 1441343 /tmp/tmpfHvp1fI (deleted)
consumer. 4880 root 2u REG 0,243 0 1441343 /tmp/tmpfHvp1fI (deleted)
syno_aha_ 5580 root 1u CHR 136,1 0t0 4 /dev/pts/1 (deleted)
syno_aha_ 5580 root 2u CHR 136,1 0t0 4 /dev/pts/1 (deleted)
synoahamo 5581 root 1u CHR 136,1 0t0 4 /dev/pts/1 (deleted)
synoahamo 5581 root 2u CHR 136,1 0t0 4 /dev/pts/1 (deleted)
docker-co 8242 root 27u FIFO 0,16 0t0 14227020 /run/containerd/6f8736c973161277d40e4eb1468df2249fc9ad4efe1a8909016738373a6ee70f/init/control (deleted)
php56-fpm 8390 root 3u REG 0,15 0 53697 /tmp/.ZendSem.4Mvoa6 (deleted)
mysqld 9209 mysql 1w REG 0,29 633600 4920008 /volume1/@database/mysql/DBserver.err.1 (deleted)
mysqld 9209 mysql 2w REG 0,29 633600 4920008 /volume1/@database/mysql/DBserver.err.1 (deleted)
mysqld 9209 mysql 8u REG 0,15 0 56579 /tmp/ibIgoJug (deleted)
mysqld 9209 mysql 9u REG 0,15 0 56580 /tmp/ibflF9P3 (deleted)
mysqld 9209 mysql 10u REG 0,15 0 56581 /tmp/ibNCVzbR (deleted)
mysqld 9209 mysql 11u REG 0,15 0 56583 /tmp/ibIsrnVr (deleted)
mysqld 9209 mysql 15u REG 0,15 0 53669 /tmp/ibh1hMHg (deleted)
mysqld 9209 mysql 76u REG 0,15 148502 86081 /tmp/ML0v6xPV (deleted)
httpd 9290 root 24w REG 9,0 164249580 34 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 9290 root 32w REG 9,0 4075741 26223 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 9290 root 33w REG 9,0 42460147 26641 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
cron 11074 root 5u REG 0,243 0 1441432 /tmp/tmpf2WUssy (deleted)
sh 11079 root 1u REG 0,243 0 1441432 /tmp/tmpf2WUssy (deleted)
sh 11079 root 2u REG 0,243 0 1441432 /tmp/tmpf2WUssy (deleted)
consumer. 11084 root 1u REG 0,243 0 1441432 /tmp/tmpf2WUssy (deleted)
consumer. 11084 root 2u REG 0,243 0 1441432 /tmp/tmpf2WUssy (deleted)
php56-fpm 12809 http 3u REG 0,15 0 53697 /tmp/.ZendSem.4Mvoa6 (deleted)
php56-fpm 12828 http 3u REG 0,15 0 53697 /tmp/.ZendSem.4Mvoa6 (deleted)
php56-fpm 13538 http 3ur REG 0,15 0 53697 /tmp/.ZendSem.4Mvoa6 (deleted)
httpd 17557 http 24w REG 9,0 164249580 34 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 17557 http 32w REG 9,0 4075741 26223 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 17557 http 33w REG 9,0 42460220 26641 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 17558 http 24w REG 9,0 164249580 34 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 17558 http 32w REG 9,0 4075741 26223 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 17558 http 33w REG 9,0 42460220 26641 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
syslog-ng 20735 root 5u REG 0,16 16384 25968 /run/syslog-ng.persist (deleted)
cron 26186 root 5u REG 0,243 0 1440537 /tmp/tmpfARifYv (deleted)
sh 26190 root 1u REG 0,243 0 1440537 /tmp/tmpfARifYv (deleted)
sh 26190 root 2u REG 0,243 0 1440537 /tmp/tmpfARifYv (deleted)
consumer. 26203 root 1u REG 0,243 0 1440537 /tmp/tmpfARifYv (deleted)
consumer. 26203 root 2u REG 0,243 0 1440537 /tmp/tmpfARifYv (deleted)
httpd 29920 http 24w REG 9,0 164249580 34 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 29920 http 32w REG 9,0 4075741 26223 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
httpd 29920 http 33w REG 9,0 42460220 26641 /var/log/httpd/user-XXXXXXXXXXXX_access.log.1 (deleted)
 
Zuletzt bearbeitet:

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.103
Punkte
248
Da es sich um ein entsprechendes Business-Gerät handelt -> Ticket bei Synology aufmachen, dafür ist der Support da.
 

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Das stimmt und ein Ticket habe ich auch bereits auf gemacht. Allerdings sind das ja auch keine Wunderheiler und ich wollte erstmal schauen, ob hier jemand eine Idee hat - denn der Support möchte natürlich auf das unser System (weil wohl auch keinen konkreten Ansatz) und da habe ich schon ein irgendwie mulmiges Gefühl :rolleyes:

Wenn ich nichts finde, werde ich diesen Weg natürlich gehen....
 

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.103
Punkte
248
Najo, ich sag mal so: vorerst passiert eh nichts weiter, als dass denen die Logs geschickt werden (wo die liegen weisste ja selbst) bzw. weiss der Support ja vielleicht schon um diesese Phänomen.

Tendentiell gäbe es ja schon ein paar Möglichkeiten:
- ggf. ist ein Mountpoint offline und die Daten werden nun direkt ins ungemountete Verzeichnis geschrieben
- Irgendein Dienst läuft Amok (hast Du die Indizierung an, oder ggf. auch Dateizugriffsprotokoll? Die beiden würde ich als erstes checken)

Alternativ (aber nicht in Bezug auf md0):
- Wenn die Versionierung an (bis X mal) ist und irgendwer schmeisst seine PST-Dateien auf's Gerät (sind ja nicht immer die kleinsten...). Die ändern sich ja mit jeder Mail die ankommt und so wird dann eben alles zugemüllt... da können auch flott mal ein paar TB flöten gehen, allerdings liegen die Kopien dann normalerweise mit auf dem Daten-Volume und nicht auf dem DSM-System-Volume.
 

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Die Logs hatte ich denen schon geschickt, als das Ganze zum ersten Mal auftrat. Der Support will jetzt auf das System schauen.

Aber mittlerweile bin ich ein Stück weiter. Ich habe mir lsof aus dem IPKG Archiv extrahiert und dabei gesehen, dass WebStation Logs noch offen sind (siehe oben), obwohl die eigentlich von Logrotate weg rotiert werden sollten. Dann habe ich festgestellt, dass die Entwickler die Apache mustache Config Files beim letzten Versionswechsel auch in Bezug auf die Apache Logs geändert haben.

Darüber hinaus verhält sich der Speicherplatzschwund "verkehrsabhängig" - heißt Nachts deutlich weniger als über Tag. Ich werde also jetzt mal die WebStation Einträge neu konfigurieren und Logrotate anpassen und dann nochmal schauen. Fakt ist: Die "aktuelle" WebStation Config schreibt Access und Error Logs nach /var/log/httpd und das ist ein wenig "ungewöhnlich".

Ich gebe Feedback, ob es das war....

Beste Grüße

Markus
 

VDMKL

Benutzer
Mitglied seit
27. Aug 2013
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Nachdem ich nun einige Stunden abgewartet habe kann ich mit an Sicherheit grenzender Wahrscheinlichkeit sagen, dass es wohl die WebStation war, mit ihren rotierten Logs. Für die Diagnose war das Kommando lsof sehr wichtig, was in der DSM leider nicht enthalten ist - aktueller Stand. Daher habe ich das entsprechende IPKG Archiv geladen:

http://ipkg.nslu2-linux.org/feeds/optware/

und das File http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/lsof_4.82-1_i686.ipk heuntergeladen und mit tar -zxf lsof_4.82-1_i686.ipk einfach entpackt. Die Binary dann einfach ins Home Verzeichnis des Benutzer hochgeladen und schon kann man mit Hilfe eines Admin Benutzers und sudo sehen, wo der Hase im Pfeffer liegt......

Grüße

Markus
 

dil88

Benutzer
Contributor
Sehr erfahren
Mitglied seit
03. Sep 2012
Beiträge
29.715
Punkte für Reaktionen
1.022
Punkte
754
Danke für den guten Hinweis! Ich hoffe, Du hast jetzt wieder Ruhe.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat