RAID / Festplatten angeblich vollgelaufen

[Pasco]

Sehr geehrte Gemeinde,

seit ein paar Monaten habe ich ein RS3617RPxs (DSM 6.1.5-15254) im Einsatz. Aktuell sind sechs Festplatten verbaut, in einem RAID6 Verbund. Meine gesamte Kapazität beläuft sich also auf rund 36TB. Via iSCSI habe ich auf einem Windows Server 2012 R2 den Datenträger eingebunden. - So weit, so gut.

Nachdem alles eingerichtet war und es alles so eingestellt wurde, dass das System automatische Updates installiert, habe ich das Synology etwas aus den Augen gelassen und habe mir nur die Email Benachrichtigungen immer mal angesehen. Nun musste ich feststellen, dass angeblich die komplette Kapazität der Datenträger vollgelaufen ist. Jedoch sehe ich auf dem Datenträger in Windows das noch 33TB frei sind. Ich habe es mit Datenträgerbereinigung und RAID-Bereinigung versucht. - Leider keine Chance.

Google oder andere Foreneinträge, die in etwa in die gleiche Richtung gehen, habe mir leider nicht geholfen.

Hat jemand eine Idee?

SSH

12K     /volume1/@S2S
0       /volume1/@autoupdate
42M     /volume1/@database
35T     /volume1/@iSCSI
0       /volume1/@tmp

WIN Server


Synology

 

[Fusion]

Bekommst du denn jetzt Fehlermeldungen?
Oder kann Windows nicht mehr auf das LUN schreiben?
Vielleicht hat Windows einfach nur den gesamten Bereich des LUNs jetzt reserviert, auch wenn es ihn noch nicht genutzt hat?

 

[Pasco]

- Die einzige Fehlermeldung bekomme ich auf dem Synology, dass der Festplattenspeicherplatz zur Neige geht und das er zu 100% voll ist. - Keine Mails.
- Das ist ja das komische, ich kann weiter auf das LUN schreiben.
- Kann ich mir nicht vorstellen, wie würde Windows das machen? Das Synology müsste ja von Windows manipuliert werden, jedoch greife ich ja nur auf den Speicher zu.

 

[stulpinger]

Für mich sieht es so aus, dass für das iSCSI Laufwerk der gesamt Speicherplatz reserviert wurde:

35T /volume1/@iSCSI


Schau mal in den iSCSI-Einstellungen nach, soweit ich es in Erinnerung habe, gibt man beim Erstellen des Luns die Grösse an, die verwendet werden soll

 

[Fusion]

Dazu weiß ich zu wenig wie Windows Server iSCSI behandelt.
War nur eine Vermutung dass ähnlich wie man in einem Dateisystem den Speicher für Dateien vorbelegen kann ohne Inhalt dies vielleicht bei iSCSI geschieht, oder geschehen kann.
Zugegeben wäre das Blöd für ein Block-Level-Device Dienst, aber ...

oder wie @stulpinger schreibt dass es bei der Erstellung des LUNs geschieht, ob das direkt reserviert oder erst dynamisch belegt wird.

 

[Pasco]

Danke sehr für die Antworten.

Ich habe mir noch mal den iSCSI-Initiator von Windows angesehen. Jedoch kann man da nicht so viel einstellen. Da gebe ich nur die IP Adresse an, damit der IQN ermittelt werden kann und ein Verbindung ermöglicht wird.
Des Weiteren habe ich mich auch durch die Einstellungen auf dem Synology gearbeitet. Bei dem erstellen eines iSCSI LUN gebe ich die größe an, die verwendet werden soll. Da ich die komplette mir zur Verfügung stehende Speicherkapazität verwenden möchte, habe ich die gesamte Größe in GB angegeben, 35748 GB. Somit war mein LUN erstellt und ich kann keine erweiterten Einstellungen vornehmen.

Edit:
Sollte Windows den Speicherplatz reservieren, wieso hat Windows das nicht von Anfang an gemacht? Wieso tritt das Problem jetzt erst auf? Das Problem muss ja über eine Weile gewachsen sein. - So meine Vermutung.

 

[Matthieu]

iSCSI gibt über das Netz einen Speicherblock wie eine "entfernte Festplatte" frei. Die DS sieht nicht was sich darin abspielt - für sie ist der Platz schlicht verbraucht. Die Alternative ist Thin Provisioning wie hier beschrieben:
https://www.synology.com/de-de/know...LUN_with_thin_provisioning_on_my_Synology_NAS
Ich denke aber das setzt du nicht ein. Poste am besten mal deine iSCSI-Einstellungen.

MfG Matthieu

 

[Matthieu]

Dann ist das iSCSI-Device für die DS eine große Datei. Das ist technisch auch, bis auf die Kniffe beim Thin Provisioning, kaum machbar. Das sollte auch von Anfang an so gewesen sein.

MfG Matthieu

 

[Pasco]

Richtig, Thin Provisioning ist nicht aktiviert.

 

[Pasco]

Es fiel mir tatsächlich auch erst auf, als ich die Mail bekommen habe:

Sehr geehrter Benutzer,
DSM die automatische Aktualisierung wird abgebrochen. Bitte melden Sie sich bei NAS-****** an und lesen Sie die Benachrichtigung.
Mit freundlichen Grüßen

Dann habe ich mich angemeldet und die "volle" Platte gesehen. Trotzdem habe ich versucht, DSM zu aktualisieren, was jedoch jedes mal fehlschlägt. Ich bekomme die Meldung, dass das DSM nicht aktualisiert werden kann, da nicht genügend Speicherplatz vorhanden ist.

 

[Fusion]

DSM Aktualisierung bezieht sich aber eher auf die Systempartition und nicht das iSCSI LUN.

Kannst du per SSH Konsole nachsehen mit
df -h
und
du -xhd 1 /

 

[Pasco]

Vielen Dank für die Info, dass war mir so auch noch nicht bekannt.

df -h

Filesystem         Size  Used Avail Use% Mounted on
/dev/md0           2.3G  861M  1.4G  39% /
none               3.8G     0  3.8G   0% /dev
/tmp               3.8G  2.3M  3.8G   1% /tmp
/run               3.8G  4.2M  3.8G   1% /run
/dev/shm           3.8G  4.0K  3.8G   1% /dev/shm
none               4.0K     0  4.0K   0% /sys/fs/cgroup
cgmfs              100K     0  100K   0% /run/cgmanager/fs
/dev/vg1/volume_1   35T   35T     0 100% /volume1

du -xhd 1/

8.0K    ./.gnupg
16K     .

 

[Pasco]

Update:

Ich habe zwei weitere Platten in das Synology geschoben, ein RAID1 - Volume 2 erstellt, und exakt so eingebunden und konfiguriert, wie Volume 1. Aktuell kann man nur sehen, dass Windows nichts reserviert und das laut des Synology der Speicherplatz absolut frei ist. - 1% belegt. Ich werde das weiter beobachten um zu sehen, ob etwas passiert. Eine weitere Möglichkeit, die in betracht ziehe, wäre, die Daten von Volume 1 auf Volume 2 zu kopieren und dann das RAID6 - Volume 1 neu anlege.

 

[tproko]

Sonst schau dir mal im Detail an, wo der Platz velegt wird.
Evt. CloudStation mit Versionierung am laufen?

du -xhd 1 /volume1/*
Und dann immer weiter handeln, wo viele Daten sind. CloudStation wäre zB direkt unter volume1 ein ordner beginnend mit @ (Details gerade nicht zur Hand).

 

[Fusion]

Ist zwar ein Tippfehler beim du Befehl (Leerzeichen zwischen 1 und / fehlt glaube ich), aber das Systemvolume scheint nicht das Problem.
Normal landen Anwendungen (Paketzentrum) ja auf Volume 1 oder einem anderen Volume. Frage mich wie er das in diesem Fall, nur file-based iSCSI LUN, behandelt.
Vielleicht darf man einfach nicht 100% des Volumes dafür hernehmen und muss ein paar GB dafür 'frei' halten die nicht in das Provisioning für das LUN gehen.
Dann wäre das aber ein Bugreport Wert, wenn Synology da nicht drauf hinweist. Allerdings habe ich mir die diesbezügliche Hilfe auch noch nicht durchgelesen, vielleicht wird da schon was erwähnt.

 

[stulpinger]

Zitat: Da ich die komplette mir zur Verfügung stehende Speicherkapazität verwenden möchte, habe ich die gesamte Größe in GB angegeben, 35748 GB. Somit war mein LUN erstellt und ich kann keine erweiterten Einstellungen vornehmen.

D.h. auf Volume1 ist der komplette Speicherplatz belegt bzw. reserviert
Wie Fusion angemerkt hat, wäre es besser gewesen ein paar GB freizulassen

 

[Pasco]

Vielen Dank für eure Antworten

@Fusion, @stulpinger: Mein nächster Schritt, ich werde das Volume1 neu erstellen und ein paar GB frei lassen.
@tproko: CloudStation ist nicht installiert

Wenn ich mehr Informationen habe, lasse ich es euch wissen!

 

[Pasco]

Update: Ich habe das Volume1 - RAID6 neu erstellt und alle Daten wieder auf die Platten gespielt. Jetzt läuft es wieder einwandfrei. Das Volume2, welches ebenfalls ein LUN ist, zeigt keine Veränderung in der Speicherkapazität. Somit schließe ich für mich erstmal aus, dass Windows irgendetwas reserviert. Des Weiteren konnte ich auch erst, nachdem Volume1 neu erstellt wurde, das DSM aktualisieren!? Handelt es sich hierbei möglicherweise um ein Bug?

Vorübergehend sind meine Problem erstmal gelöst, auch wenn es für meinen Geschmack eher "quick and dirty" war.

 

[Fusion]

Das liegt doch jetzt eindeutig am Thin Provisioning, ob das gesamte LUN oder nur ein Teil für den DSM wie belegt aussieht.
Das umgehst du vermutlich wie eben jetzt mit einer reduzierten LUN Größe ( so dass noch Platz für Apps und Updates auf dem Volume bleibt) oder durch Thin Provisioning dass eben erst wenn das LUN wirklich voll ist ein "Problem" da wäre.
Ob man das als Bug oder Nachlässigkeit sieht, sei mal dahin gestellt, ein Hinweis wäre allerdings doch sehr entgegenkommend.
Würde das Synology trotzdem mal per Ticket melden.

 

[Pasco]

So, ich habe eine Antwort bekommen von dem Synology Support. Mein Hauptproblem lag wohl definitiv am Thin Provisioning. Aber das ich nicht updaten konnte, wenn die Platten voll sind, hat wohl folgenden Grund:

Es wird in der DSM 6.1 Version eine Datei auf dem Volume für das iSCSI System gespeichert, dies schlägt fehl, wenn kein Platz auf dem Volume ist, damit kann das Update scheitern. In der neuen DSM Version ist das Verhalten geändert worden, daher sollte es nicht mehr vorkommen.