Erste Unraid Hardware

wern001 schrieb:
DDR5 On-Die ECC erkennt z.B keine doppel bit fehler so wie es bei Serverboards mit ECC CPU/RAM können.

Ob er die (innerhalb seiner Speicherchips) erkennt, weiß ich nicht; er könnte das sicherlich, nur kann es eben nirgendwohin gemeldet werden - deshalb sinnlos. Ein wesentlicher Unterschied gegenüber normalem ECC-RAM ist auch, dass der Weg zwischen CPU und RAM nicht geprüft wird.
Ansonsten ist es m.W. so, wie @SirKhan schreibt: Durch die noch höhere Speicherdichte und die höheren Geschwindigkeiten kam man um ECC innerhalb des RAM nicht mehr herum.

Ob dann ein wirklicher Vorteil gegenüber non-on-die-ECC besteht, ist die große Frage. Zwar werden bei DDR5 dann zumindest 1-Bit-Fehler im RAM korrigiert, andererseits steigt aber durch die höhere Speicherdichte u.U. auch das Risiko für Multi-Bit-Fehler (und durch die höhere Geschwindigkeit für Fehler zwischen CPU und RAM), so dass es im Endeffekt evtl. keinen Unterschied macht. Keine Ahnung. Das statistisch aufzuarbeiten, wäre sehr aufwändig bzw. langwierig, wird wohl niemand machen (obwohl es mich persönlich interessieren würde).


Ergänzung ()

alturismo schrieb:
entweder im cache direkt

Aber nur bis zum Reboot, oder?
 
Zuletzt bearbeitet:
Banned schrieb:
Aber nur bis zum Reboot, oder?
nope ... das ist kein RAM read cache ... im "klassischen" Sinn.

der UNRaid cache ist nichts weiter als ein zusätzlicher pool "vor dem HDD Array" wenn gewünscht welcher per FUSE im Verbund drin hängt ...

jetzt kann man beispielsweise sagen

Share1 > kommt auf den cache und bleibt auf dem cache (cache only)
Share2 > kommt auf den cache und wird bei "mover schedule" immer verschoben (Standard)
>> (hier folgt unten noch was)
Share3 > kommt auf den cache und wird bei "mover schedule" bei Bedarf verschoben (cache prefered)
>> sprich, je nach Platz auf dem cache ... und sollte dieser wieder frei werden wird vom Array wieder retour ...
Share4 > kommt direkt ins Array (HDD) und bleibt auf dem Array (Array only)

zu Share 2 > jetzt kann man noch "tunen" ... die meisten lassen den "mover" 1x täglich laufen (nachts) .... dabei wird dann wie beschrieben verschoben, im Tuning kann man jetzt aber beispielsweise sagen ...

Ordner1, 2, 3, ... immer ausnehmen ...
Dateityp 1, 2, 3, ... immer ausnehmen ...
Dateigröße < xy kb, mb, ... immer ausnehmen ...
oder
wenn der cache > 80 % gefüllt ist, dann mache den frei bis zu 50 % Füllrate (sortiert nach Alter) und lasse den Rest auf dem cache ...

also, der viel zitierte Unraid Cache ist kein RAM Cache sondern persistent Speicher ... normal SSD ...
wir reden nicht über den Standard Linux vm dirty ... oder irgendwelche tempfs ... im RAM

Beispiel einer Freigabe (Share 2 mit tuning)

1735221253534.png


Daten liegen auf HDD (Array) UND Cache (nvme ssd)

Beispiel (tiefer), die können überall sein ...

1735221391616.png


was aber am Frontend nicht erkennbar ist da "FUSE"

1735221468878.png


also hinter einer UnRaid Freigabe kann erstmal alles sein ... das konfiguriert man sich so wie man möchte

sei es nur cache, nur array, fuse (cache und array nach Typ a, b, ..), separate pool/s, ... usw usw ....
 
  • Gefällt mir
Reaktionen: Banned, fireblade_xx und Korben2206
Zurück
Oben