L2ARC Cache For Unraid Array

[Mofarocker33]

Hallo zusammen,

 

Ich finde das Unraid System an sich wirklich gut, besonders auch wegen dem Schreib Cache, aber mit 10GbE und 16TB HDDs ist das davon lesen einfach eine fars (Ja so 240 Mb/s kriege ich raus). Also einfach daten von runter zu kopieren, ätzt bei so einem System.

 

Siehe Anhang...
 

Ich hatte ja schon mit dem Unraid 7 rumprobiert. Leider war der Schreibcache, also Mover nicht mehr verfügbar, dafür aber der L2ARC von ZFS.
Vorteil: Daten die Oft benutzt werden werde auf einer SSD ausgelagert.
Nachteil: Der ganze Pool Spinnt up, wenn eine außerhalb den L2ARC genutzt wird, wobei ich sagen muss, eigentlich jedesmal wenn ich auf eine Datei zugegriffen habe... -> also bei mit 6x16TB - doof und nicht Energie Effizient. Zudem kein Mover also kein Schreibcache mehr. Udn Ohne SSD als Schreibcache liege ich bei grandiosen 60 MB/s...

 

ZFS ist doch Open Source?
wenn ich den gesamten Pool in ZFS Formatiere, währe es dann nicht möglich auch einen L2ARC Cache herzustellen?
Es währe doch ein Killer Featur für Unraid.

Ja es währe natürlich Virtaul FS CPU lastig, aber ich würde es machen.
2xNVME als schreib-Cache und nochmal eine NVMe als Lese Cache für Hot Data. Das kann kein Synology und nur real Raid Controller oder Enterprise Storages, die auf Block Basis laufen.

 

Währe einfach ein Killer für anderes Systeme auf dem Markt!

 

Sagt mir einfach mal was ihr denkt, ich fänd es grandios cool!
Bleibt natürlich die Frage in wie fern das Umsetzbar ist im Virtuellen FileSystem.

Danke im Voraus.

Mir freundlicher Grütze
Der MoFgeRockTe

[alturismo]

3 hours ago, Mofarocker33 said:

ist das davon lesen einfach eine fars (Ja so 240 Mb/s kriege ich raus). Also einfach daten von runter zu kopieren, ätzt bei so einem System.

ich schätze mal du meinst Lesen vom array, was lesen von einer HDD entspricht und da ist dann die HDD das Limit wo die zu lesende Datei liegt ...

 

lass die Daten auf der nvme und du solltest schneller sein

 

3 hours ago, Mofarocker33 said:

Leider war der Schreibcache, also Mover nicht mehr verfügbar,

was auch immer du jetzt meinst, aber weder das eine noch das andere ist korrekt und hängt auch nicht miteinander zusammen ...

 

der "Schreibcache" ist ja nur ein pool welcher im Fuse Verbund als primary gesetzt ist

>> natürlich ist das da und verfügbar unter v7

 

der "mover" ist ein elementares Element um zu gegebener Zeit Daten vom cache pool >> ins array die Daten zu verschieben

>> natürlich ist das da und verfügbar unter v7

 

und hat auch nichts mit der Performance zu tun ob der mover da wäre oder nicht ... das ist ein scheduled Vorgang zum Daten verschieben, fertig.

 

also, mal zusammengefasst ... lokale Limits (Netzwerk Speed mal außen vor)

 

Lesegeschwindigkeit >>

array >> Daten liegen jeweils auf einer physischen Platte, NICHT striped ... Limit == Read Speed der jeweiligen Platte

>> >> sei es eine HDD im Array (150 - 250 MB/s), sei es eine SSD (500 - 600 MB/s), sei es eine nvme SSD (1000 - 7000 MB/s)

 

das Ganze bei "Standard setup" ... Array sind ja meist HDD's, Daten liegen nicht striped, kurz, es kann nur eine HDD lesend bereitstellen ...

cache's sind meist SSD / nvme's, entweder single oder raid1 konfiguriert, auch da liegt das Limit lesend bei einer der Festplatte ...

 

der mover verschiebt nur Daten, je nach Konfiguration ... meist jedoch "stumpf" vom cache >> array ... meist 1x täglich, fertig.

 

du meinst "wahrscheinlich" das mover tuning plugin welches für v7 anfangs nicht mehr kompatibel war, was jedoch mittlerweile erledigt ist ...

was jedoch auch nichts mit der performance an sich zu tun hat, ich steuere damit nur das mover Verhalten ... wann, ob, wieviel, ... verschoben wird.

 

Beispiel, ich halte Daten "länger" im cache vor anstelle die immer täglich auf das array zu packen

 

simples Beispiel

 

mein mover schaut stündlich nach, und ...

 

wenn cache > 90 % gefüllt ist

move Daten (vorher nicht)

>> sortiert nach Alter

>> nur bis der cache bei < 70 % steht (dann hör direkt auf)

 

 

Ergebnis, mein cache wird nicht "leer" moved ... sonder es werden ~ 21 -23 % frei gemacht (Delta 90 <> 70 zzgl. Overhead)

 

nochmals kurz, hat nichts mir performance zu tun ... sondern move Verhalten

ich lasse meine Daten länger auf dem cache weil ich keine spinups möchte bei aktuellen Daten.

 

zu deiner Frage

 

4 hours ago, Mofarocker33 said:

Währe einfach ein Killer für anderes Systeme auf dem Markt!

 

 

das Unraid Array mit dem "nicht striped Raid" (daher auch der Name UNRaid) ist ja das Killer feature ... effizient, anpassbar, bei Ausfall einer Platte im Array kein kompletter Datenverlust (auch ohne Parity) usw usw usw ...

 

was du willst ist eigentlich kein UNRaid sondern ein Standard striped Raid um alle HDD's parallel lesend zu nutzen und deine 10G auszunutzen ...

 

jetzt noch kurz zu dem Thema

 

4 hours ago, Mofarocker33 said:

Ohne SSD als Schreibcache liege ich bei grandiosen 60 MB/s...

 

ja, das ist normal im Standard effizienten setup, auch das lässt sich zumindest beschleunigen ...

 

settings, disk settings, tunable ...

 

steht im Standard auf auto (r, w, m) ... stell es auf reconstruct (turbo) ...

 

Standard read, write, modify ... wie du bereits siehst ... aufwändig, gerade bei physischen HDD'S ... aber zumindest effizient da schreibend nur 2 Platten parallel in Nutzung sind im Array (anstelle alle), die Parity und die beschriebene HDD (wie erwähnt, die Datei liegt effektiv nur auf einer HDD).

 

reconstruct ... geht viel schneller da jetzt alle Platten laufen, das modify und neu kalkulieren entfällt weil lesend immer alle Blöcke direkt gelesen werden können ... ändert nichts daran dass die Datei immer noch nur auf einer Platte effektiv liegt, aber für die Parity muss nicht "kreuz und quer" gearbeitet werden ... jetzt sind wir wieder am physischen Limit schreibend der langsamsten HDD (Parity oder die Daten HDD) angekommen, meist bei 120 - 230 MB/s ... aber schreibend sind dann immer alle Platten aktiv.

 

das alles ... steht auch in der Dokumentation, sollte man halt mal gelesen haben ...

 

Antwort zu deiner Frage, auf keinen Fall ... und bedarf es auch heute nicht.

 

wenn du mehr Tempo willst aus deinen HDD's und auf die Array features verzichten willst, pack die HDD's in ein zfs RaidX, nutze das striped Raid und du hast deine Geschwindigkeit und brauchst nicht noch cache hier und cache da ... und entscheide dich bewusst gegen die Unraid array features.

 

Geht ja schon ... noch mehr "Gebastel" und noch mehr wo hier dann hängen und Issues haben zu zfs .... braucht es sicher nicht 

 

meiner Meinung nach ...

[Mofarocker33]

Erstmal Danke @alturismo für die ausführliche Antwort.

 

Ja Unraid 7 - Hatte ich gemacht um die 6x16TB wirklich mal in ein ZFS Raidz2 zu Packen. War zwar cool, aber kost hat ne Menge Strom, weil immer alle angehen müssen.

 

Mit den Mover Tools hatte ich mal Probleme gehabt, daher wieder runter geworfen. Aber deine Einstellung gefällt mir, werde es daher mal damit Probieren. Die Samsung 990 pro 2TB sollte ja dann wirklich was bringen. Aber mit Unraid 7 und non Array sondern nur TFS Pool Funktionierte der Mover gar nicht mehr. Daher wieder zurück auf Array Design.

Parity Settings versuche ich auch mal. Um die SSD zu schonen hatte ich beim Backup Ordner, die SSD weg gelassen. Vielleicht bringt das wirklich was, denn beim Backup war halt dann das gesamte Array super in der Reaktion, also nicht. Ich versuche natürlich auch zwecks der Anker Solarbank 2 Pro auch irgendwo Festplatten Spinups mit meine Anwesenheit zu verbinden, um etwas Energie zu sparen.

Werde berichten, ggf. Editieren.

Meine Idee war halt wirklich ein mehr Parameter OneOnly Drive zu haben.

1. NVME
2. SSD S-ata oder schnelle HDD
3. Langsame HDDs
-> Was dann aber selbst vom Fuse wie du es nennst verwaltet wird. Welche Daten wo liegen. Also eigentlich nur ein Step mehr, als mit dem was du mir aufgezeigt hast, mit dem Mover tweak.

Danke nochmal.
Gruß
Mofa