Hat es Vorteile beim Aufsetzen eines TS-431KX mit RAID5 aus 3 (später vielleicht 4) Platten gleich QTS5.0 zu nehmen?
Kann ich den freien Slot für eine alte S-ATA SSD als Cache nutzen? Bringt das was oder verliere ich damit nur Redundanz? Die SSD könnte ja ausfallen.
Auf jeden Fall gleich mit 5.0 aufsetzen, QTS 4 ist tot.
Eine einzelne SSD als Cache nur lesend, nicht schreibend. Ob Dir das was bringt mag ich nicht beurteilen, Dein Netzwerk ist aber schneller als 1G, oder?
aber nicht 5.0.1 sondern 5.0.0 und kein Public Beta
Selbst ein Lesecache reisst bei Plattentod das Cachevolumen mit sich..hatten wir jetzt schon mehrfach..
Für den Effektiven Nullgewinn bei sequenziellen Operationen, bitte Cache vergessen.
Empfehle ebenfalls QTS 5.0.0.
Cache bringt für "normale" Datenhaltung nur wenig. Für Datenbanken sieht es da anders aus und virtuelle Maschinen vielleicht besser gleich direkt auf die SSD installieren.
Dein Netzwerk ist aber schneller als 1G, oder?
Bald!
Dann eben mal anders herum: Wie sieht der Einsatzzweck des NAS denn aus? Was soll der Cache den beschleunigen?
Lese- bzw. Schreib-Cache setzt man am Besten auch im RAID-Verbund ein. Also meiner Einer zumindest hat es nicht anders im Einsatz.
Selbst ein Lesecache reisst bei Plattentod das Cachevolumen mit sich..hatten wir jetzt schon mehrfach..
Für den Effektiven Nullgewinn bei sequenziellen Operationen, bitte Cache vergessen.
Das ein Lesecache irgendwas kaputt machen kann wenn er nicht mehr funktioniert ist komplett unlogisch - bizarr!
In der Theorie ja nicht. Aber die Praxis sieht da des öfteren anders aus. Da ich keinen ausschließlichen Lesecache im Einsatz habe oder je hatte - immer nur Lese- und Schreibcache - kann ich da auf keine eigene Erfahrung zurückgreifen. Kann es mir aber gut vorstellen.
Zugegeben, ich bin gerade auch etwas verwundert darüber, dass Lese-Cache zum Datenverlust führen kann. So wie man liest werden im Lese-Cache Kopien der eigentlichen Dateien abgelegt und genutzt. Daher wundere auch ich mich, dass dies zum Datenverlust führen soll.
Bei Schreib-Cache verstehe ich da ja noch.
Möglicherweise indirekt durch Systemcrash. 
Nein, weil man das Volume nicht mehr aktiv bekommt ohne den Cache und diesen nicht deaktivieren kann wenn das Volume inaktiv ist. Somit Katze - Schwanz - Prinzip.
Also Cache ohne RAID eigentlich sinnlos. Vom Schreibcache bekannt, aber in diesem Fall gilt dies auch für reinen Lesecache.
Nein, weil man das Volume nicht mehr aktiv bekommt ohne den Cache
Das Volume, auf dem die eigentlichen Daten liegen?
Jup. Hatten wir grad die letztens hier ein Beispiel dazu. RE: RAID5 zerschossen - was kann ich noch tun?
Krass 🙈
Bei QTS 5.x muss man sich halt dran gewöhnen, das einige Einstellungen, die man bei QTS 4.x direkt im System vornehmen konnten, bei 5.x dann über APPS gehen!
Bei mir lauft die 5.0.1 Beta 3 im Produktivsystem. Auch die Beta 2 lief wochenlang ohne Probleme. Kommt halt drauf an was du alles brauchst
Moin alerseits nach langer Stille. sorry meine Studienarbeiten rufen 
Evt noch meinen Senf zum Tema Cache. Gibt es ja als lese, schreib oder lese-schreib cache im QTS. QES und QTSHero nur als Lese Cache wegen ZFS struktur und daher total anderst.
Warum führt es in der Praxis auch zum Datenverlust im QTS? Mögliche Lösung und Ursache ist folgende:
Wie wird dein Cache angelegt?
Der Cache wird über eine eigenständige Disk oder Raidverbund angelegt und bindet sich in dein Dateisystem ein. Im optimalsten fall, hat der zur Verfügung stehende Superblock natürlich einen hohen Duchsatz (Bandbreite/IOPS) durch gute Disks und/oder dedizierte Schnitstellen. Daraus natürlich die abgeleiteten Rechte: Schreiben, lesen oder beides
Warum geht dein Cache überhaupt kaput ? Dein QTS entscheidet selbst, wenn du den Cache "ON" hast ob er eine Datei XY in den Cache legt. Daher weiss nur dein ex4 Dateisystem auf dem QTS aufgebaut ist welcher superblock Berreich für "Cache" ist und welcher für "Data" zur Verfügung steht.
Logischerweise stellt es dein Dateisystem für das du gerne Cache haben willst unter Dauerstress, und zwingt es im iNode register des Dateisystems die Register umzuflaggen, wenn jetzt eine Datei in "Cache" oder in "Data" verlegt wird und erzeugt somit viel Leistung.
Daher ist auch ZFS viel effizienter da das ZIL in das Ram geladen wird und wie eine Datenbank lesend abhandelt. Daher auch bei Benchmarks ZFS viel effizienter im lesen aber schwächer als ext4 im schreiben. Da vermutlich heutzutage die meisten 70-80% lesevorgänge haben eine gutze Wahl aber eben das ist wie Äpfel mit Birnen zu vergleichen....
nun zurück zum möglichen Crash Szenario:
Da deine Volume die du erzeugst "Virtuele gebunden Verzeichnisse im QTS sind" die sich über X Raids und Volumes hinwegziehen geht logischerweise beim Ausfall des einen oder anderen physischen Volumen oder gleich dem Raid das Virtuelle gebilde flöten. Daher Datenverlust und Systemcrash...!
Ich bin aber mit der Aussage einig, dass wenn noch ein superblock eines Raids intakt ist ein Recovery einer Datei aus dem caches möglich ist.
Es ist leider nicht immer alles stabil was Dynamisch/virtuell erstellt wird. Ich persöndlich empfehle auch eher QTier zu verwenden, da es besser Einstellbar ist und die oberste Ebene (Raid/superblock) eher der treibende Trigger ist, dass birgt weniger Risiken im iNode Register vom ext4 Dateisystem aber ist natürlich hier auch der gleiche Crash möglich.
Cache ist eher dazu gedacht die Schreib- Lese Latenzzeit von ext4 zu verkürzen (Gap zwischen dem Ext4 Dateisystem zum Server Memory, CPU und der Weitergabe an Periferie) und gerade bei IOPS lastigen Anwendungen wie bei Datenbanken und Streaming ein Gamechanger.
Da vermutlich heutzutage die meisten 70-80% lesevorgänge haben
Bei einem NAS, welches als Backup-Ziel eingesetzt wird, was bei NAS durchaus mal des öfteren vorkommen kann, wohl eher umgekehrt. Aber bei einem NAS für Backups Cache einzusetzen macht sehr selten Sinn.
