DS918+ - SSD Cache hat TBW-Grenze erreicht und sind jetzt unbrauchtbar

[gaulo23]

Hallo zusammen

Welcher Wert sagt mir denn, wieviel Prozent meine Platte schon verbraucht hat. Mich würde mal interessieren, wie lange meine SSD´s noch laufen.

 

[s24-asm]

Hier:

 

[Ansorg]

Was für ein %&/§$ mit den SSDs :-(

hier hat sich letztens auch eine 960 EVO mit "Critical Failure" verabschieded. Laut Samsung Magician 59.3 TBW. Bin noch im RMA, schaut aber nach Austausch aus.

Die zweite, gleich-alte, läuft noch. Mit angeblich 100% Lebensdauer - kann ja irgendwie nicht sein. Welches der SMART Attribute entspricht denn diesem TBW Wert?

Weiß noch nicht ob ich den Lese+ Schreibcache wieder aktiviere wenn der Austausch da ist. Performance war in einigen Szenarien schon deutlich besser. Aber dieses Drama mit den kaputten SSDs macht keinen Spaß :-(

Grüße
Jens

 

[s24-asm]

Bin noch im RMA, schaut aber nach Austausch aus.

Meine hatten sie "geprüft" und für i.O. befunden. Aber jedes Testprogramm zeigt den Fehler an. Auch der Magician. Deshalb ist das ja so ärgerlich mit Samsung, daß sie's einfach als "ok" zurückschicken.

Scheint's hat aber Synology auch irgendwas am Algorithmus geändert. Hab die WD jetzt seit fast drei Monaten und sie stehen noch bei 100%. Allerdings war letztens plötzlich eine "verschwunden" und das Volume dann degraded. Cache entfernen ging nicht, Shutdown auch nicht. Nur Stecker ziehen und hoffen... Nach dem Neustart war die SSD wieder da und das Volume konnte wieder bereinigt werden.

So ganz ausgereift ist das alles wohl nicht...

 

[StefanKöln]

Danke für dieses Forum. Mich hat es jetzt bei einer 256GB EVO 960 erwischt bei 8500 Stunden. Ich glaubte schon irgendwas ist defekt. aber hier scheint der defekt ja eher auf der synology seite zu sein

 

[StefanKöln]

Alter Thread aktuelles Problem. Leider habe ich jetzt den Cache deaktiviert und bekomme ihn auch nicht mehr aktiviert. Was für ein geschisse von Synology. Gibt es denn irgendwas neues oder an wen kann ich mich mal wenden?

 

[RichardB]

Neues gibt es nichts.
Wenden kannst Du Dich an den Syno-Support und die werden Dir antworten, dass dies eine Sicherheitsmaßnahme ist, die der Integrität Deiner Daten dient.

Du kannst auch versuchen, Dich an den Hersteller zu wenden. Ev. tauschen sie den Riegel aus, oder machen eine Runderneuerung.

 

[StefanKöln]

Ich bin mal gespannt. Ich habe jetzt die SSD ausgebaut und in einen anderen PC eingebaut. Das Samsung Magican liefert aktuell 49.0 TBW. Das ist auf jeden Fall noch unter den 100. Mal schauen was der Call bei Samsung macht.

 

[RichardB]

Wahrscheinlich werden die erklären, dass das Ding eh in Ordnung ist und Du DIch an Synology wnenden sollst. Und Synology wird erklären, dass siehe oben ...

 

[StefanKöln]

Hi Richeárd, das kann Samsung nicht machen, da auch im Magican die Platte als "defekt" angezeigt wird.

 

[cmdr_tom]

Ich mutmaße, dass der Fehler bei dir aus dem SMART Wert "Percentage Used" resultiert. Die Syno interpretiert den als 100% der Lebenszeit erreicht und deklariert das Modul als unbrauchbar. Das zeigt, dass Synology die ganze SSD Cache Thematik echt schlecht angegangen ist. RMA bei Samsung aufmachen, dann bekommst du einen neuen. Würde mir aber überlegen, den wieder in der Syno zu verwenden. Ich habe inzwischen 5 Module getauscht innerhalb von 2 Jahren. Ich hab es jetzt aufgegeben und betreibe nur noch den letzten übrig gebliebenen als Lesecache. Wenn der auch am Ende seiner Lebenszeit ist laut der Syno Smart Überwachung, fliegt der raus.

 

[mgutt]

Ich bin mal gespannt. Ich habe jetzt die SSD ausgebaut und in einen anderen PC eingebaut. Das Samsung Magican liefert aktuell 49.0 TBW. Das ist auf jeden Fall noch unter den 100. Mal schauen was der Call bei Samsung macht.

Egal wie schlecht Synology die Erkennung für einen Defekt umgesetzt hat, so scheint mir das eigentliche Problem eher die fehlende Persistenz des Caches zu sein. Ich mein wie kann es sein, dass man so hohe TBW Werte erreicht?

Offensichtlich wird jede Operation erst auf die SSD geschrieben und danach entschieden ob die Datei überhaupt eines Caches würdig ist. Damit ist die Performance natürlich mega, weil jede Datei nach dem Hochladen bereits beim 1. Zugriff aus dem Cache kommt, aber sinnvoll erscheint mir das nicht. Das ist nicht der Sinn eines Caches bzw dafür sind SSDs einfach nicht gebaut. Meiner Ansicht nach sollte natürlich das OS auf der SSD laufen und dann sollten sonstige Dateien erst ab dem 3. Zugriff aus dem Cache kommen (1. Zugriff = von HDD + loggen, 2. Zugriff = von HDD + auf SSD kopieren, 3. Zugriff = von SSD). Zumindest sollte genau so etwas einstellbar sein. Und als Schreibcache würde ich sie gar nicht verwenden. Hier sollte Synology lieber dafür sorgen, dass man 64 oder sogar 128 GB RAM verbauen kann. Berücksichtigt man die laufenden Kosten der SSDs, wäre das sogar günstiger.

 

[s24-asm]

Ich glaub, das liegt auch am SSD-Hersteller. Meine Samsung waren nach rund 47 TBW "critical" und für den Cache unbrauchbar. Samsung hielt sie für völlig ok und hat gar nichts getauscht. Jetzt hab ich SN750 von WD drin und die haben nach 6 Monaten und knapp 32 TBW noch exakt 100% laut der DS.

 

[mb01]

Die TBW kann ich gerade nicht auslesen, weil die SSDs noch in der DS918+ stecken, aber ich hab momentan mit meinen Samsung 860 EVO 250GB auch die Situation, dass versteckt in den Smart-Daten z.B. die "Percentage Used" bei ~40% angezeigt wird, aber der prominenter platzierte Wert für die "erwartete Lebensdauer" hingegen noch bei 100% liegt. Totales Kuddelmuddel ... ich würde eigenlich erwarten, dass die erwartete Lebensdauer zumindest in irgendeiner Weise mit der Percentage Used aus SMART korreliert, aber nada. Den anderen Fall hatte ich bei einer SATA-SSD auch schon, dass sie mit 0% Lebensdauer angezeigt wird, aber von den SMART-Daten alles im grünen Bereich ist.

 

[synfor]

Ich mutmaße, dass der Fehler bei dir aus dem SMART Wert "Percentage Used" resultiert.

Das Problem ist wohl eher Critical Warning mit dem Status FAILING_NOW

 

[s24-asm]

Egal wie schlecht Synology die Erkennung für einen Defekt umgesetzt hat, so scheint mir das eigentliche Problem eher die fehlende Persistenz des Caches zu sein. Ich mein wie kann es sein, dass man so hohe TBW Werte erreicht?

Mit Veeam Backup hab ich in 'nem halben Jahr 32 TBW. Allein das Merging der Forever Incremental Jobs erzeugt sehr viel I/O.

Die TBW kann ich gerade nicht auslesen, weil die SSDs noch in der DS918+ stecken, ...

Das zeigt die Syno an:


Das ist die Anzahl der Sektoren. Also durch 2 teilen, dann sind es die geschriebenen Kilobytes.

 

[Aevin]

Hi alle zusammen,

ich finde das Thema sehr interessant und hatte auch bereits mit einer SSD-Cachelösung geliebäugelt. Allerdings habe ich auch keine Lust nach kurzer Zeit die SSD's / M2 zu wechseln.
Spaßeshalber habe ich für meinen Server mal den SSD Cache Ratgeber durchgeführt.

Finde aber die Aussagen nicht so nachvollziehbar. Keine Ahnung welche Daten er da nimmt um die Zugriffe festzustellen. Da wäre eine genaue Auflistung der Dateien viel interessanter, denn ein Backup muss nicht gecacht werden.

 

[mgutt]

Keine Ahnung welche Daten er da nimmt um die Zugriffe festzustellen.

Als ich mal ein NAS neu aufgesetzt habe, hat er quasi alles als "heiß" bewertet. Daraus schließe ich, dass das Datei-Erstelldatum und das letzte Aufrufdatum beim Ratgeber zur Auswertung herangezogen wird. Dementsprechend wäre alles kalt oder archiviert, wenn es X Tage bzw Monate nicht mehr aufgerufen wurde.

Allerdings hat das null Aussagekraft. Er cached einfach alles was man gerade aufruft. Deswegen sagte ich ja, dass da die Persistenz fehlt.

Mit Veeam Backup hab ich in 'nem halben Jahr 32 TBW. Allein das Merging der Forever Incremental Jobs erzeugt sehr viel I/O.

Erfolgt Merging nicht auf dem Backup Server?!

Und warum I/O? Erstellt der etwa jedesmal Hashes von jeder Datei statt den Hash in einer Datenbank zwischenzuspeichern? Ohne Hashes könnte er ja einfach in den Datei-Index schauen. Da würde sich auch die SSD bedanken.

 

[s24-asm]

Erfolgt Merging nicht auf dem Backup Server?!

Und warum I/O? Erstellt der etwa jedesmal Hashes von jeder Datei statt den Hash in einer Datenbank zwischenzuspeichern? Ohne Hashes könnte er ja einfach in den Datei-Index schauen. Da würde sich auch die SSD bedanken.

Keine Ahnung, was sie da machen oder wie. Jedenfalls geht die Volume Utilization auf 100% und die bei den Disks auf etwa 50%.

 

[KGundermann]

... so scheint mir das eigentliche Problem eher die fehlende Persistenz des Caches zu sein. Ich mein wie kann es sein, dass man so hohe TBW Werte erreicht?

Offensichtlich wird jede Operation erst auf die SSD geschrieben und danach entschieden ob die Datei überhaupt eines Caches würdig ist.

Mich würde auch einmal interessieren ob es Informationen zum Cache-Algorithmus gibt.

- Arbeitet er auf Block- oder Dateiebene.??

Ich habe nur 1,5 TB an Daten (aktive VM-Ware Images) aber nach 1 Monat sollen jetzt schon 5 TB an Daten geschrieben worden sein ...

Es wäre großer Schwachsinn, wenn beim Zugriff auf das VM-Ware Image-Datei die Datei komplett in den SSD Cache geschrieben wird .