selbstbau NAS Cache zuweisen

[reeneex]

Moinsen,

ich habe ein Selbstabu NAS mit einem Supermicro X11sca-f Mainboard. AUf diesem sind 2 Plätze für NVMe die ich beide nutze.

NVMe0n1 ist eine 500GB Samsung auf der das Betriebssystem OMV7 läuft
NVMe1n1 ist eine 1TB XPG Gammix auf der die ganzen Benutzerordner und die Container liegen

Angeschlossen sind momentan 6 HDD´s a 4TB in einem RAID6 und ich habe noch 2 S-ATA Anschlüsse direkt am Board und 4 weitere über einen Controller frei.

Nun habe ich aus einer vorherigen Installation 2 120GB SSD´s und eine 54GB SSD übrig. Eine davon würde ich gerne als dezidierten Cache für das RAID installieren um die Geschwindigkeit etwas zu boosten.
Alternativ, eventuell die Samsung nachträglich partitionieren und dort einen Cache platzieren? OMV braucht nicht viel Platz,

Frage dazu, geht das überhaupt? Wenn ja, wo finde ich Infos dazu.


Vielen Dank für Eure Zeit und Hilfe.

 

[Demon_666]

In der Doku von OMV?

 

[phm666]

Du könntest dir mal bcache anschauen. Das ist eigentlich genau dafür entwickelt worden. OMV sollte das auch können. Erfahrung habe ich aber leider auch keine damit.

 

[reeneex]

danke, das werd ich versuchen

 

[DFFVB]

Habe kürzlich mit OMV rumgespielt und bin über keine Caching Optionen gestolpert. Die Frage bei Cache ist auhc immer: a) Read Cache oder b) Write Cache? Bei Unraid bspw. kann man einen Cache definieren, der dann regelmäßig verschoben wird. Keep in mind: Bei Write Cache, geht die Lebensdauer der SSDs auf absehbare in den Keller. TrueNAS hat hierfür dedizierte Caches und Konzepte. Wäre ggf auch aufgrund von ZFS eine Idee darauf zu migrieren.

 

[reeneex]

ZFS ist ein Datei system, oder? OMV nutzt ext4. Da wäre der Umzug nicht soeinfach

 

[DFFVB]

Korrekt ZFS ist das wahrscheinlich fortgeschrittenste Dateisystem auf dem Markt. Es ist Copy on Write, das beduetet es schriebt erst wenn Blöcke geändert werden, und ermöglicht so bspw. Snapshots, die praktisch keien Platz wegnehmen. Ferner hat es Fehlerkorrektur, und Deduplication. Der Umzug ginge freilich nur, wenn Du genügned "Zwischenspeicher" hättest.

 

[reeneex]

kacke, hab gerade erst alles neu aufgesetzt von OMV 6 zu 7
Meine Frau erschiest mich. die musste jetzt eine woche ohne NAS auskommen.

Hab gerade ein bissl gelesen. Meine Hardwae sollte TrueNAS scale unterstützen. Nur beim RAM muss ich mal schauen ob der ECC ist

 

[Banned]

Nur beim RAM muss ich mal schauen ob der ECC ist

Wäre gut, ist aber keine notwendige Bedingung.

Soweit ich mich erinnere, bietet TrueNAS aber keine Cache-Funktion im klassischen Sinne, außer das hat sich mittlerweile geändert.

EDIT:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Donnerkind]

Es ist Copy on Write, das eduetet es schriebt erst wenn Blöcke geändert werden

Ähh, Nicht ganz. Jedes Dateisystem schreibt, wenn Blöcke geändert werden. ;-)
Copy on write bedeutet, dass geänderte Blöcke an eine neue Stelle auf dem Datenträger geschrieben werden statt die alte Version zu überschreiben. Es legt also beim Schreiben eine Kopie an (daher copy on write). Und gerade das ermöglicht es, ohne Aufwand Snapshots anzulegen; weil die alte Version eines Blocks erhalten bleibt und weiterhin referenziert werden kann.

 

[wern001]

was erhoffst Du dir bei 2-4 leute mit SSD-Cache?

 

[andy_m4]

Wegen ZFS und Cache bzw. Performance-Optimierung und so.
Also generell und bei üblicher Last so im privaten Rahmen muss man sich darum keine Gedanken machen. Da sind die autotuned-Vorgaben schon ganz passend.
Ansonsten kann man natürlich am in-RAM-Cache drehen.

Darüber hinaus gibt es noch 3 on-disk Beschleunigungsmethoden.

Das ist einmal den L2ARC auf ein möglichst schnelles Device zu legen. Das beschleunigt dann insbesondere Lesezugriffe.
Außerdem kann man diesen Cache persistent machen. Cache dient ja darum, das häufig gelesene Blöcke auf nen schnellen Zwischenspeicher gehalten werden, so das beim erneuten lesen aus diesem Zwischenspeicher bedient werden kann
Das setzt woraus, das es vorher schon Lesezugriffe gab. Die Persistenzfunktion sorgt dafür, das der Cache auch über einen Reboot hinaus befüllt bleibt und sich der Cache nicht erst erneut "warmlaufen" muss.

Dann gibts noch das sogenannte ZIL (ZFS intent log)
Das beschleunigt Schreibzugriffe. Die Idee dahinter ist, das man nicht direkt in den Pool schreibt, sondern zunächst eine Art Journal in einem (wiederum schnellen) Zwischenspeicher. Und von da aus kümmert sich dann ZFS darum, das die dann in den Pool wandern.

Dann gibts noch das Metadata Special Device.
Auch hier wird wieder zur Beschleunigung ein schneller Speicher genommen und darin aber nicht Dateien selbst gespeichert, sondern nur dessen Metainformationen (wie heißt die Datei, wie groß ist die Datei; wo liegen die dazugehörigen Blöcke usw.) Und wenn die Datei klein genug ist, wird die auch durchaus mal als ganzes da rein gepackt.

Eine übrige SSD kann man also durchaus für solche Dinge verwenden. Muss man gucken, was am meisten Sinn macht. Dem L2ARC ne SSD zu spendieren ist keine grundsätzlich verkehrte Idee (zpool add mypool cache devname wobei mypool der Poolname ist dem man den Cache zuordnen will und devname der Device-Name der SSD/Partition den man als Cache benutzen will). Wieviel das bringt, hängt natürlich von verschiedenen Faktoren ab (wenn der Netzwerkdurchsatz der limitierende Faktor ist, kann man so viel rumcachen wie man will und es wird nicht viel bringen). Bevor die Hardware nutzlos vor sich hingammelt, kann man das natürlich machen.