Synology DiskStation Manager 6.2.2-24922-5 veröffentlicht
von caschy | 6 Kommentare
Synology hat für einige seiner Netzwerkspeicher ein Update veröffentlicht. Konkret geht es dabei um ein paar Geräte, die M.2 NVMe SSDs verbaut haben, bzw. diese aufnehmen könnten. Für diese NAS-Geräte wird der DiskStation Manager in Version 6.2.2-24922-5. verteilt. Synology selber spricht auf den Changelog-Seiten lediglich von einer verbesserten Kompatibilität und dass das Update die DiskStations in den nächsten Tagen erreichen soll. Falls jemand von euch nicht warten möchte, so kann er das Update von Hand für sein NAS herunterladen und installieren, die entsprechenden Downloads sind auf dem FTP von Synology im Ordner mit den kritischen Updates zu finden. Das Update erfordert einen Neustart der Synology DiskStation.
Wird geladen ...
Wie bei den anderen „Versionen“ wo ich eine Fehlermeldung zwecks „nicht möglichem Downgrade“ bekomme?
Etwas OT:
Ich hatte vor dem Kauf meiner DS218+ mit der DS718+ geliebäugelt, wurde jedoch durch die Berichte auf
https://idomix.de/das-problem-mit-dem-synology-ssd-cache-und-samsung-m-2-sata-ssds und
https://idomix.de/was-aus-dem-ssd-cache-meiner-diskstation-wurde verschreckt. Ein System, das wegen EOL SSD nicht mehr brauchbar ist, kann keiner brauchen.
Kann ja sein, dass Synology das mit diesem Release behoben hat aber Dominik schreibt auch, dass er dank der schnellen Iron Wolf Platten, den Verlust der SSD kaum bemerkt. Ich habe zwar keine Vergleich, wie es mit SSD läuft, kann aber sagen, dass sowohl die private 218+ und die RS818+ in der Firma auch ohne SSD schnelle Zugriffe garantieren.
Wie sieht das bei euch aus: habt ihr eine Diskstation mit SSD? Wie lange im Einsatz und was sagt der Speichermanager für eine Lebenserwartung der SSDs?
Moin,
an sich ist der Punkt gegeben: du hast keinen Engpass dann benötigst du es nicht 😉
der eigentliche Grund aus meiner Sicht ist nicht der Durchsatz, das hat @MarcGutt ja bereit erwähnt. Das kann man mit Spindeln lösen. Mehr Platten = mehr Durchsatz bis die Leitung dicht ist. Bei IOPS sieht die Sache ganz anders aus. Beruflich habe ich mit Speichersystemen (nicht Synology) zu tun da stecken nur NVMe drin und sind mit 100Gbit/s angebunden. Die Leitung wird gar nicht ausgelastet und trotzdem sind die „Platten“ ausgelastet weil viele kleine „Dateien“ geschrieben werden.
Bei ähnliche Szenarien hilft auf der Synology einfach das Cachen auf SSD. Der Client bekommt die Rückmeldung „alles geschrieben“ und kann weiterarbeiten, den Rest macht die Synology. Zuhause benötige ich es nicht. Im beruflichen Umfeld KANN es sinn machen z.B. wenn ich eine DB für Exchange darauf laufen lasse mit 20k-Benutzern.
Die Problematik besteht noch immer, aber ich bezweifle, dass sie den Endanwender in diesem Maße trifft.
Synology misst den Wear Level der SSDs und berechnet daraus prozentual, wieviel Lebensdauer noch verbleibt. Geht die SSD gen Null wird der weitere Betrieb verweigert. Ich habe das selbst schon bei einigen SSDs gesehen und kann das von iDomix insoweit bestätigen.
Aber…
Damit eine handelsübliche SSD so durch ist, vergeht eine ganze Zeit. Beispiel: Mittelständler mit Fileserver, auf den täglich 180 User zugreifen, SSD Cache besteht aus 2x 850 EVO 500GB. Es dauerte 18 Monate bis die SSDs auf unter 10% liefen. 18 Monate, in denen täglich zig Gigabyte Daten durch den Cache liefen.
In meiner 918+ laufen 2x 250GB 970 Evo und dort sind sie chronisch unterfordert. Halt ein zu großes NAS in der Familie für Plex, Drive, Fotos und so weiter. Dort ist der Wear Level der SSDs immer noch bei 100%. Nach über sechs Monaten wohlgemerkt.
In der Realität ist es eben nicht immer so eindeutig. Was immer iDomix mit seinen SSDs gemacht hat, er hat sie ordentlich belastet. Genau das war ja auch Sinn und Zweck des Caches. Denn schneller macht der SSD Cache den Zugriff schon, das ist meine Erfahrung von vielen Kundengeräten, auch meinem eigenen.
Was strittig ist und wo iDomix Recht hat, ist, dass man nicht weiß, ob Synology die SSDs über Gebühr belastet, sprich ob irgendwelche Routinen des NAS die SSDs auf Dauer so schnell klein kriegen. Das steht weiter zur Debatte. Auch, ob es nur SATA oder auch PCIe SSDs betrifft. Weiß man nicht.
Dass Ironwolf Festplatten den SSD Cache ersetzen können, wage ich zu bezweifeln. Der Cache spielt gerade bei sehr vielen Usern seinen Vorteil aus, wenn oft verlangte Daten ohne Plattenzugriffe ausgeliefert werden können. Auch das Verhalten der GUI empfinde ich als flüssiger. Kann aber auch Einbildung sein.
Mal schauen was mit DSM 7 da noch so passiert.
Meiner Ansicht nach ist der SSD Schreibcache nicht clever genug programmiert. Nehmen wir mal an jemand lädt ein paar kleine Dateien auf das NAS. Diese gehen nun diesen Weg:
SMB -> SMB RAM Cache -> SSD Cache -> HDD
Der SSD Cache ist in dieser Situation überflüssig, denn der RAM wird ja bereits als Cache genutzt. Erst wenn die Summe aller Dateien den RAM übersteigt oder eine Datei dabei ist, die größer ist als der (verfügbare) RAM, dann schreibt er zwar immer noch (Chunks) in den RAM, aber wartet bis die ältesten Daten auf die HDD geschrieben wurden bzw im Fall des SSD Caches wird denke ich der SMB Prozess von der SSD das „Ok“ erhalten und dann zeitversetzt auf die HDD schreiben.
Da erkennt man ja bereits ein Optimierungspotential. Nämlich immer dann wenn der RAM eben nicht überlastet ist, könnte der SSD Cache außen vor bleiben. Außerdem könnte man dem Kunden eine Statistik anzeigen in dem ihm zB angezeigt wird, dass wenn er x GB RAM installiert, dass er dadurch x GB Traffic auf der SSD einspart.
Wo man ebenfalls optimieren könnte, wäre der Lesecache. Ich verstehe zB nicht warum jede Datei ab dem 1. Zugriff dort landet (was ja ebenfalls eine Schreib-Operation resultiert). Meiner Ansicht nach sollte das einstellbar sein. Ich würde dann nur Dateien zulassen, die mindestens 2x in einen Zeitraum X aufgerufen wurden. zB dürfte er so die Plex Filmcover und regelmäßig angehörten MP3s auf der SSD bereithalten, aber nicht einen kompletten Film, den ich vor einer Woche geschaut habe. Damit wirkt der Cache zwar erst später, aber dafür wird er viel mehr geschont.
Zuletzt wünsche ich mir aber wie so viele, dass man die SSDs einfach als Volume nutzen kann. Statt nämlich den Cache zu nutzen, würde ich einfach alle die Dateien darauf ablegen, die ich schnell bewegt haben möchte. Aber Synology will wohl nicht, dass man einfach so mal eben 2 neue Bays freigeschaltet bekommt 😉
@Martin
Wozu man bei 1G einen SSD Cache braucht, verstehe ich eh nicht. Außer man hat irgendeine datenbanklastige Anwendung darauf laufen, aber selbst dann wäre es sinnvoller das Geld statt in zwei SSDs in eine potentere CPU und mehr RAM zu stecken, bevor man über SSDs nachdenkt. Aber selbst bei 10G sehe ich keinen nennenswerten Mehrwert. Hat man genug Bays, dann lastet man auch das mit normalen HDDs aus. Zumindest im Lesezugriff schafft das die DS1618+ mit 6 Platten im RAID5/6.
Mich stört viel mehr, dass man nicht mehr als 32GB RAM verbauen kann. 64GB wären für mich ideal und im Gegensatz zu SSDs ein unkaputtbarer Schreibcache.