nikeee

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by nikeee

  1. Ja, ziemlich genau das wäre mein Backup-Plan gewesen. Sicher, dass es bei dem von dir verlinkten Artikel nicht um clientseitiges Caching vom sshfs geht? Bin zwar nicht so ein Fan von FUSE, aber zur Not gibt's sicher auch irgendein random FUSE-File-System, das genau das macht. Damit kann man dann transparent zu der eigentlichen Anwendung cachen. Edit: Gerade gefunden: Es gibt auch 2 richtige Kernelmodule, die sowas können: BCache und fscache, beide sind Teil von Linux. Bei dem ranzigen Fuse-FS von oben sind auch noch 5 andere verlinkt, die man probieren kann. /Edit Genau solche Lösungen wollte ich eigentlich vermeiten, da ich möglichst stets auf von Haus aus unterstützte Funktionen setzen will, allein aus Wartungsgründen. Deshalb würde ich auch den Write-Cache von Unraid verwenden, statt selbst irgendwas zu basteln. Da Read-Caches wohl ein Feature ist, was man von einer NAS-Firmware erwarten könnte, habe ich einfach mal nachgefragt. Synology war buchstäblich das erste Google-Suchergebnis von "nas ssd read cache", womit ich validiert hab, ob das ein Feature ist, das bei NAS erwartbar ist (hat nichts speziell mit dieser Firma zu tun, wollte es nur als Beispiel verlinken). Mir ist selbstverständlich bewusst, was das für eine Auswirkung auf die SSDs haben wird. Cache-Invalidation ist eines der "schwierigen" Probleme in der informatik. Da ich mit der reduzierten Laufzeit leben kann (ja, kann ich wirklich), wäre es mir egal, ob der Cache irgendwas fancyges wie FP-Growth-Analyse, einen LSM-Tree oder eine simple Cache-Eviction-Strategy der dutzenden existierenden verwendet (für mich würde auch ein simpler LRU-Cache mit Mindesthaltedauer reichen; in meinem Fall im Speziellen verändern sich die Daten auch nicht, das würde es noch deutlich vereinfachen). Sowas muss man im Jahr 2021 auch eigentlich nicht mehr selbst implementieren. Hat sich dahingehend aber wohl erledigt. Viele Grüße
  2. Meine initiale Frage zielte explizit auf einen SSD-Schreibcache aus, nicht auf den RAM (die Möglichkeit habe ich selber später auch noch eingeworfen). Ich hab 3 Fragen gehabt, von denen wurden 2.5 beantwortet und wollte die Sache abschließen. Damit man nicht großartig suchen muss, hab ich kurze Antworten dazugeschrieben und noch ein paar Pointer zu StackExchange da gelassen. Wenn etwas technisch an meiner Zusammenfassung nicht stimmt, korrigiere mich gerne. @mgutt sehr guter Hinweis, danke! Ich werd mal schauen, ob das funktionieren wird. SMB werde ich bei dem Use-Case nicht einsetzen (eher (S)FTP und HTTP). Daher wird's vielleicht auch ein simpler Webserver mit aggressivem Caching. Das hatte ich nicht vor, deshalb hab ich hier gefragt. Keine Ahnung, wieso diese Aussage für diesen Thread relevant ist...? Schaltet mal ein Trigger-Level runter. Ich hatte ein Problem, hab den Use-Case dargestellt und wir haben gemeinsam Lösungen im Rahmen der Unraid-Plattform erarbeitet. Nicht mehr, nicht weniger. Viele Grüße
  3. Da unraid kein HW-Raid verwendet und Wissen über das konkrete Dateisystem hat, könnte es ja davon gebrauch machen und nicht nur Blöcke, sondern auf eine intelligentere Art Daten in den Cache schieben (z. B. über Zugriffsmuster oder durch Kopieren der gesamten Datei; wäre letztendlich nur ein Implementierungsdetail). Mir ist bewusst, wie ein Lese-Cache funktioniert. Ich fasse mal meine bisherigen Antworten aus dem EIngangspost für die Nachwelt zusammen, als tl;dr: Unterstützt unRAID einen Lese-Cache? Nein. Gibt's Alternativen, um das trotzdem in unRAID hinzubekommen? Nicht built-in. Ist Anwendungs- und OS-spezifisch. Ggf. einen Reverse-Proxy davorschalten, der das Caching zur Not selber managed (siehe Post von @Ford Prefect). Würde ggf. implizieren, dass man nicht die built-in-Services von Unraid zum Servieren nutzen kann. Man kann ein bisschen am File-Caching mit hdparm rumschrauben eventuell sogar mit noatime mounten. "Linux will cache as much disk IO in memory as it can."; Sehr waage Formulierung; ggf. gibt es über hdparm hinaus noch weitere Kernel-Settings dafür Ist es geplant? Offenbar nicht. Vielen Dank!
  4. Ich verstehe die Frage nicht. Caches sind nicht notwendigerweise so groß wie das Medium, wo die Daten liegen. Z. B. Synology unterstützt Lese-Caches, die haben aber auch einen richtigen RAID-Controller. Das Prinzip ansich sollte aber nicht beschränkt auf HW-Unterstützung sein. Welche Eviction-Strategie unterstützt wird, ist mir im Prinzip egal. Also kann ich davon ausgehen, dass unRAID einen Lese-Cache nicht untersützt und auch nicht unterstützen wird?
  5. Konkrete Geschwindigkeiten kann ich gerade nicht benennen. Was ich vorhabe, ist eine (S)FTP-Freigabe, über die mehrere Millionen kleine Dateien (ca. 0-100MB) über eine 10Gibit-Leitung serviert werden sollen. Habe keinen Zugriff auf die Konfiguration der Switche. Die Dateien sind größentechnisch zu viel, um in den SSD-Schreibcache zu passen. Die Abfragereihenfolge der Dateien kann ich nicht kontrollieren. Ich denke, ein LRU-Cache wäre ausreichend. Generell wäre es gut, wenn die Netzwerkkarte das Bottleneck wäre. Meine Befürchtung ist (getestet habe ich es nicht, Erfahrung habe ich auch nicht), dass durch die vielen kleinen Dateien die Bandbreite auf den HDDs extrem runter gehen könnte. Grundsätzlich würde ich es auch ohne Read-Cache versuchen wollen, aber es wäre gut, wenn es die Option gäbe. Kann man den RAM als Read-Cache verwenden? Oder braucht ein Read-Cache (egal ob im RAM oder auf einer SSD) grundsätzlich einenen HW-RAID-Controller (, welcher von unRAID nicht unterstützt würde)?
  6. Unterstützt unRAID einen Lese-Cache? Gibt's Alternativen, um das trotzdem in unRAID hinzubekommen? Ist es geplant?