DSM 6.x und darunter Dsm 6.1.5

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Alle DSM Version von DSM 6.x und älter
Status
Für weitere Antworten geschlossen.
Habe auch das Update installiert und auch die Fehlermeldung das Universal Search nicht aktualisiert werden konnte. Hatte aber vor kurze auch erst ein Update für Universal Search installiert als es angeboten wurde.
 
Ich habe jetzt bei meiner DS215J auch endlich mal von der letzten 5er Version auf 6.1.5 aktualisiert. :) Nach dem Zwischenschritt 6.0x wurde dann direkt die 6.1.5 installiert. Anschließend waren einige Updates und "Reparaturen" der Anwendungen fällig, die aber einmal angestoßen dann selbständig und ohne Fehler durchgeführt wurden.

Bisher sind mir noch keine Probleme aufgefallen.
 
Update auf 6.1.5-15254 ohne Probleme bisher, läuft alles wie immer.
 
Ich kann das Update von Version DSM 6.1.4-15217 Update 5 auf die neue Version DSM 6.1.5-15254 Update nicht vornehmen.
Bei mir kommt immer die selbe Fehlermeldung, egal ob manuelles oder automatisches Update.

Fehlermeldung: Aufgrund des nicht ausreichenden Festplattenspeicherplatzes werden modularisierte Services nach dem Upgrade nicht mehr verfügbar sein. Es ist unbedingt empfehlenswert, vor dem Upgrade einigen Speicherplatz freizumachen, um Datenverluste zu vermeiden.
/volume1

Keine Ahnung warum er nörgelt.

Ein Anzeigen mit df -h ergibt:
Code:
root@SAN:/# df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/md0                2.3G  1.2G  1.1G  52% /
none                    990M  4.0K  990M   1% /dev
/tmp                    994M  472K  994M   1% /tmp
/run                    994M  2.8M  991M   1% /run
/dev/shm                994M  4.0K  994M   1% /dev/shm
none                    4.0K     0  4.0K   0% /sys/fs/cgroup
cgmfs                   100K     0  100K   0% /run/cgmanager/fs
/dev/mapper/cachedev_0  5.5T  5.5T   67M 100% /volume1

Ich habe 4 HDs, 2 als SSDs für Cache und 2 für die LUNs mit 5TB. Modell: RS815RP+

Vielleicht hat jemand eine Idee warum das passiert und wie ich das lösen kann.
Möchte vermeiden alles zu löschen und dann hin und her kopieren. :(
 
Zuletzt bearbeitet:
Nun...es scheint als wenn er das so anzeigt.
Sorry, verstehe es selbst nicht richtig, denn eigentlich sind die Laufwerke ja noch frei...
Ich habe vor 7 Monaten das SAN von einer Firma so installiert bekommen.
Von Anfang an, waren die Laufwerke auf 100% voll... (siehe Systemzustand im Screenshot #27)

image.png
 
Zuletzt bearbeitet:
also hier hat er schon von anfang an genörgelt aber die bisherigen Aktualisierungen haben immer funktioniert!
image (1).png
 
Mit der Konfiguration (LUN) bei dir kenne ich mich nicht aus. Ich nehme mal an, dass das so eine Art Container sind.

Nur wenn man sowas konfiguriert, würde ich eigentlich annehmen, dass man bei 5,5TB zur Sicherheit etwas mehr "Luft" lässt als nur 0,00001219% (67MB).

Im Verzeichnis volume1 sind ja auch die Pakete gespeichert. Und wahrscheinlich ist ein Paket zu groß.
 
Der mit der Luft lassen, hatte ich eigentlich von Anfang an auch gedacht. Das es besser wäre nicht 100% für die LUN1 und LUN2 zu nehmen.
Aber man sagte mir das wäre ok.
Wie man aber nun mal sieht ist der Systemordner auf 871 MB freigegeben und nur noch 66.1 MB verfügbar.

Momentan denke ich gibt es wohl keine andere Möglichkeit und ich muss den ganzen Kram nochmal neu machen und sollte mehr Speicher für das System zum updaten übrig lassen.
Da es einer meiner ersten Geräte sind, kenne ich mich leider damit noch nicht so gut aus.

Danke trotzdem für deine schnelle Antwort.

Vielleicht hat ja jemand noch eine andere Idee...
Ansonsten sehe ich da schwarz :( und bin wohl gezwungen alles neu zu installieren.. shit.
 
Mir fällt nur noch ein per SSH reinzuschauen und die Verzeichnisgrößen zu checken. Vielleicht ist ja irgendwo Müll (z.B. temporäre Dateien, Gedöns), die schlicht und einfach weg können.
 
Im Verzeichnis volume1 sind ja auch die Pakete gespeichert. Und wahrscheinlich ist ein Paket zu groß.

Jupp, das war auch mein erster Gedanke.
LUNs lassen sich nicht verkleinern, das ist mal Fakt.
Die LUNs enthalten hoffentlich nicht das Betriebssystem des Rechners, der das nutzt?
Ansonsten bliebe noch folgendes, um hier etwas Platz zu schaffen ...
Auf dem Rechner, der das LUN nutzt, die Daten lokal wegspeichern. LUN löschen und etwas kleiner wieder anlegen, dann die Daten wieder zurückschieben.
Das kannst Du nun mit einem LUN so machen, oder auch mit beiden, die hier genutzt werden.
So kannst Du dir die Neueinrichtung der DS ersparen.
Bei so einem Thema achte ich möglichst immer drauf, dass noch 50-100GB frei sind auf dem Volumen.
Für die Zukunft hilft Dir evtl. mein Blogbeitrag weiter? => http://www.synology-forum.de/blog.html?cp=28
Letztlich nutze ich Volume1 ausschliesslich für die DS und nicht für Userdaten.
 
Nach dem Update bekomme ich nun im Systemzustand Widget angezeigt das auf Volume 3 der Festplattenplatz zur Neige geht.
Dort sind noch knapp 3TB frei. War vor dem Update auch nicht der Fall.
Beim Speicher zeigt er auch Normal an.
Anscheinend hat sich da wohl ein Bug eingeschlichen.
 
DS716+II problemloses Update, allerdings mit der bekannten Fehlermeldung zu Universal Search. Läuft aber, auch die Suche.
 
DS 111 mit Update versorgt, wie bei allen andern konnte Universal Search nicht aktualisiert werden. Sonst alles okay.
 
DS213+ und DS 115j ohne Probleme
 
Danke Peter & Andi,

im Verzeichnis von /volume sind unter anderem die iSCSI LUNs zu sehen. Ich habe zwei davon.
Welche Dateien oder Pakete hier zu gross sind ist mir nicht ganz klar.

Logdatei von /volume1 ist hier: Anhang anzeigen volume1.txt

Der Log Ordner von /var/log scheint mir normal zu sein.

Code:
root@SAN:/# du -h /var/log/
4.0K    /var/log/healthtest
4.0K    /var/log/nginx
2.3M    /var/log/upstart
4.0K    /var/log/pstore
4.0K    /var/log/selfcheck
176K    /var/log/synolog
4.0K    /var/log/cluster
4.0K    /var/log/openvswitch
416K    /var/log/samba
15M     /var/log/

Das die iSCSI LUNs nicht verkleinert werden können scheint mit logisch.
Die LUN enthalten die Virtuellen Maschinen der beiden VMware Hosts (2 Stück). Ebenfalls ist dort vCSA 6.5 am laufen.
Das Betriebssystem VMware läuft auf beiden Hosts auf der SD Karte.
Auf einem anderen NAS von Synology RS217 habe ich ein Raid1 mit 5.5TB.
Es sind bei beiden Geräten (SAN / NAS) keine Diskgruppen angelegt nur die "Volume". Beim SAN mit den iSCSI LUNs gibt es noch 2 SSDs für SSD Cache Nutzung (2x Raid1 500GB).

Somit müsste ich wahrscheinlich alle VMs von den LUNs aufs NAS kopieren bzw. mit Veeam sichern und wieder herstellen.
Mal sehen wie ich das Problem für das nächste mal vorbeugen kann und für das System auf volume1 genug Platz übrig ist.
Ob ich ein zweites Volume (volume2) für die LUNs mit dem SSD Cache konfigurieren kann ist mir noch nicht ganz klar.

Wie viel sollte man für das System bzw. auch Aktualisierungen frei lassen?
50 - 100 GB wie du sagtest sollte ja genügen.

Mal gespannt was mein Händler der mir das System konfiguriert hat, mir dazu raten wird.
Denn bis jetzt scheint mir von vorne rein, dass die an so ein Problem entweder nicht gedacht haben oder es ist das erste mal das denen so etwas passiert ist.

Danke für eure Gedankenansetze.
 
Zuletzt bearbeitet:
Da du für Volume 1 RAID1 benutzt, sollte auch folgendes möglich sein: Du besorgst dir 2 neue größere Platten, ersetzt damit Stück für Stück die alten und vergrößerst dann zum Schluss das Volumen.
 
alle 4 Steckplätze sind ja schon belegt.
Wir haben 2x 5.5TB für die LUNs und 2x 500GB (SSD Platten) für den Cache. Das Modell RS815RP+ hat nur 4 Plätze ;)

Platz für die LUNs ist genug da und noch frei. Leider aber nicht mehr für das System um DSM zu aktualisieren.

5.5T 5.5T 67M 100% /volume1
 
alle 4 Steckplätze sind ja schon belegt.
Er dachte wohl an folgende Lösung:
  • 2x 8TB Platten kaufen
  • erste 6TB raus, dafür erste 8TB rein
  • Raid wird instandgesetzt
  • zweite 6TB raus, dafür die zweite 8TB rein
  • Raid wird wieder instandgesetzt
  • 2TB mehr Platz im Volume... ;)

Zu deinem Händler: Ich finde das schon etwas verantwortungslos (oder naiv) mit den 67MB. Das müsste eigentlich auch er einsehen und schon seinerseits für Lösungen sorgen.
 
OK, nun verstehe ich wie das mit den Platten gemeint war :) Danke!

Mich wundert es schon das der "professionelle" Händler daran nicht gedacht hat.
Bis jetzt hatte ich keine Probleme mit der Aktualisierung der DSM. Beim NAS hatte die aktuelle Version geklappt. Da ist ja auch das Volume anders konfiguriert und nicht schon mit 100% belegt.

Ich bin auch etwas enttäuscht wieso die daran nicht gedacht haben.
Von vornerein sollte man ja nicht fast alles (100%) für die LUNs freigeben. Sicherlich war vorher noch mehr Platz als 67MB vor einem Jahr, aber nun reicht es nicht mehr aus um die neuste Version zu aktualisieren. Das ist schon der Hammer! Morgen macht ich terz. :( und darf mich dann mit dem Mist rumschlagen...

Übrigends sind es heute 66MB und nicht 67MB, wie gestern:
Code:
/dev/mapper/cachedev_0  5.5T  5.5T   66M 100% /volume1
 
Zuletzt bearbeitet von einem Moderator:
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