• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Mit SSD-Cache große Dateien vollständig cachen?

Kessl

New Member
Hi
Ich plane mein NAS (Linux) neu aufzusetzen und zu vergrößern. Nun habe ich eine Idee und wüsste gerne ob sich das mit existierenden Cache Lösungen realisieren lässt. (bcache, lvmcache, enhanceIO. Gibt es eine vierte?)
Im Prinzip möchte ich verhindern dass die Festplatten (drehende) immer wieder anlaufen wenn eine große Datei mehrfach am Tag geöffnet wird und ich möchte diese große Datei vollständig in einen SSD-cache laden sobald der erste Zugriff auf die Datei erfolgt.
Hat jemand zufällig etwas ähnliches schon mal versucht und kann mir sagen mit welchem der 3 cache-tools (oder einem vierten) ich beim Testen vermutlich am meisten Erfolg hätte?
Danke schon mal
Gruss
 
Dazu, ob das wirklich so funktionieren kann, wie Du Dir das vorstellst, kann ich Dir nichts sagen, aber die 4. Variante wäre dann z. B. ZFS

Siehe: https://schroederdennis.de/dateisystem/zfs-cache-arc-l2arc-log-zil-performance-guide/

Ich würde da auf jeden Fall raten, die SMART-Werte zu kontrollieren. Denn wenn sich die Platten regelmässig schlafen legen - dass muss man AFAIK auch konfigurieren - und dann doch immer wieder aufwachen, dann verschleißt dass die Platten. Smart-Wert: Load-Cycle-Count
 
ZFS ist glaube ich ein bisschen Kanonen auf Spatzen, aber ich werde am Wochenende mal reinschnuppern.

Und eben damit die Platten nicht alle Nase anlaufen möchte ich ja den cache. Das doofe ist, dass testen wohl recht zeitaufwendig werden wird, daher hatte ich auf existierende Erfahrungen gehofft.
 
Wäre evtl. ein RAM Laufwerk ein Ansatz...vorausgesetzt, du hast a) genug RAM und b) das File würde überhaupt ins RAM Drive passen...
 
dass testen wohl recht zeitaufwendig werden wird
Ja. Ich würde schon sagen, dass das insgesamt zeitaufwändig sein werden könnte, da nach und nach die Elemente/Dienste/Daemons zu identifizieren, die Plattenzugriffe auslösen alle zu finden und dabei Probleme zu lösen.
daher hatte ich auf existierende Erfahrungen gehofft.
Ich würde jetzt schon eher sagen, dass das SSF mehr aus teils deutlich professionellen Anwender:innen im Bereich Hosting und Serverbetrieb besteht. Da würde ich sagen ist der Bedarf und folglich auch die Erfahrung mit der Thematik nicht so groß. Ansonsten rate ich zum einen zu Geduld; vielleicht kommt die Tage ja noch irgend einer.

Zum Anderen würde ich bei der Thematik raten, da eher mal im deutschen Debianforum (debianforum.de)vorbei zu schauen. Da ist die Quote der engagierten Heimanwender, die so etwas auch eher interessiert, doch deutlich höher. Ich meine mich zu erinneren, dass es da doch den ein oder anderen Thread zu genau dem Thema bereits geben dürfte.
 
Last edited:
Warum bekommt diese Datei nicht einfach eine dedizierte SSD und gut ist`s? Ist kein Unterschied zum Vorhaben, lediglich das erst-/einmalige Verschieben der Datei in den "Cache" entfällt und es dreht erst gar keine HDD an...
 
HSM = Hierarchical Storage Management

El cheapo HSM on Linux using LVM​


Ich finde das einen interessanten, wenig komplexen Ansatz.

Mal auf's wesentliche heruntergebrochen:

Es gibt z. B. 2 physical Volumes in einer Volume Group. Eines ist die Platte(redundant) und eines ist die SSD(auch redundant). Die am häufigsten gelesenen Datenblöcke der Volume Group bzw. des Logical Volumes werden in regelmässigen Intervallen auf die SSD-verschoben. Wird also wirklich nur ein Bruchteil der Festplattenkapazität regelmässig gelesen, landet also alles auf der SSD und die Festplatte wird nur noch sehr selten angesteuert, wenn etwas bisher noch nicht gelesen wurde.

Wie aufwändig das mit dem SystemTap ist, ist mir unklar.
 
Last edited:
https://unraid.net/product als "NAS" ist genau darauf ausgelegt, dass die Festplatten so lange und oft wie möglich schlafen, hierzu wird ein SSD (Raid1) Cache verwendet. Unraid (wie der Name schon sagt) ist kein klassisches Raid, sondern erreicht die Redundanz auf einem anderen Weg, die auch bei (selteneren) Schreibvorgängen auf das Array nur eine Platte und die 1 oder 2 Redundanz Platten aufwachen lässt. Man kommt aber definitiv bei typischen Zugriffen auf die letzten Dateien tagelang ohne Aufwachen der Platten aus.
 
mdadm mit write mostly könnte noch eine dreckige Alternative sein: https://raid.wiki.kernel.org/index.php/Write-mostly
RAID1 aus HDD und SSD. Lesen primär von der SSD, schreiben auf die HDD.

Ich wäre aber auch eher bei Joe's Ansatz. Wenn man für so ein Schmarn eh schon Caching SSDs vorhält, nur weil man eine eingeschränkte Auswahl an Daten cachen will. Dann kann man sich das Caching auch sparen und die SSDs für genau dieses Datenset als primären Speicher verwenden.
 
...write-mostly...
Sehr interessant. Danke für den Hinweis.

...unraid...
Das wurde ja afaik hier auch schon öfters erwähnt. Jetzt habe ich mir es nochmal angeschaut. Ist bestimmt für viele Benutzer interessant, die wollen dass es funktioniert und sich um nix kümmern müssen. Die Leistungsmerkmale, die im Übrigen genau auch mit den Anforderungen des TE hier übereinstimmen, werden da bestens erfüllt. Wem Open Source Software(OSS) ansonsten nicht wichtig ist, der ist damit bestimmt gut bedient.

Die Frage, die bei mir da aufkam ist:

Was werkelt da unten drunter? Insgesamt ist ja ein Linux drunter, quasi die proprietäre Unraid-Distribution. D. h. die nehmen da ganz viel von dem, was schon da ist und bauen halt Ihre eigenen Tools und Ihre GUI dazu und passen das Linux-System so an, wie sie's brauchen. So weit alles Super. Das Herzstück von Unraid ist aber, so scheint mir, der Speichergerätetreiber selbst und dass ist ja jetzt nichts, was ich so von Linux irgendwie kenne. Das Bildchen mit der Parity über mehrere Platten unterschiedlicher Größe erklärt ja schön, wie das technisch abläuft.

Aber ein Speichergerätetreiber ist jetzt was, wo ich doch gerne etwas sehr verlässliches haben möchte. Da möchte man wirklich eine Software haben, die in jeder möglichen oder total bescheuerten Situation die Datensicherheit gewährleistet. Ebenso sehe ich, wenn da z. B. eine neue Platte dazu kommt, dass dann die Parity vom Gesamtsystem - also üblicherweise 1-2 Parityplatten - neu berechnet werden muss. Da würde ich vermuten, dass ein Unraid-Storage in so einer Migrationsphase recht anfällig sein könnte, wenn gerade dann eine Platte ausfällt.

Abgesehen von meiner persönlichen grundsätzlichen Präferenz von OSS würde ich da sagen, dass ich gerade bei Gerätetreibern die hohe Expertise von der Linux-Kernel-Entwickler-Community o. ä. und den offenen Review-Prozess sehr schätze - als jemand, der in seiner lange zurück liegenden Berufsausbildung selbst nur ein paar kleine C-Progrämmchen geschrieben hat und fast schon ehrfürchtig zu eben jenen Kernel-Entwicklern aufschaut, die solche ultrastabilen Eckpfeiler von Linux Systemen bauen. Und da sind dann auch meine Zweifel, ob solche closed-source Entwicklungen ebenso zuverlässig und robust gebaut sind. Auch persönliche Aussagen wie Na. Ich habe damit jetzt noch nie Probleme gehabt sorgen bei mir da jetzt nicht für so wirklich für die Auflösung dieser Zweifel.

Weiss da jemand, ob der Unraid-Treiber vom Hersteller(LimeTech) selbst programmiert wurde, oder ist das ein Treiber von irgend einem anderen vorhandenen Projekt?

In diesem Thread schreibt d4f ja etwas dazu:

Wenn ich mich nicht täusche ist Unraid Hybrid Pool "nur" ein JBOD mit Parität, will heissen es gibt kein Striping und damit keine Performance-Verbesserung durch Parallelität. Der Vorteil ist natürlich dass man wild zusammenstückeln kann und dann eine SSD für write-cache/Pseudo-Tiering, die impliziten Einschränkungen ergeben aber auch Nachteile.

D. h. hört sich ja schon fast so an, als ob da irgend etwas vorhandenes genommen wird.

---

Mit ausreichend viel Backup kann man da bestimmt schon mal einiges abfangen.

So dass bisschen, was ich bis jetzt zu Unraid ergoogelt habe macht aber insgesamt schon einen sehr soliden Eindruck.
 
Last edited:
Das wurde ja afaik hier auch schon öfters erwähnt. Jetzt habe ich mir es nochmal angeschaut. Ist bestimmt für viele Benutzer interessant, die wollen dass es funktioniert und sich um nix kümmern müssen. Die Leistungsmerkmale, die im Übrigen genau auch mit den Anforderungen des TE hier übereinstimmen, werden da bestens erfüllt. Wem Open Source Software(OSS) ansonsten nicht wichtig ist, der ist damit bestimmt gut bedient.
Jep. Genau für Home NAS Betreiber ist es gedacht, deren Festplatten aus Stromverbrauchsgründen praktisch immer schlafen sollen. Man kann quasi aus allem nen Unraid Server stricken was der Fundus so hergibt, oder auch eine neue Kiste darauf ausrichten.

Was werkelt da unten drunter? Insgesamt ist ja ein Linux drunter, quasi die proprietäre Unraid-Distribution. D. h. die nehmen da ganz viel von dem, was schon da ist und bauen halt Ihre eigenen Tools und Ihre GUI dazu und passen das Linux-System so an, wie sie's brauchen. So weit alles Super. Das Herzstück von Unraid ist aber, so scheint mir, der Speichergerätetreiber selbst und dass ist ja jetzt nichts, was ich so von Linux irgendwie kenne. Das Bildchen mit der Parity über mehrere Platten unterschiedlicher Größe erklärt ja schön, wie das technisch abläuft.
Ja, im Prinzip ists eine eigene Unraid Distribution, basierend auf Slackware, wie https://wiki.unraid.net/Building_an...ID is a file server,the files on those drives. berichtet. Darunter laufen Linuxpakete, die man bei den Release Notes ( https://forums.unraid.net/topic/129247-unraid-os-version-6111-available/ ) auch immer wieder aktualisiert sieht. Neben einem NAS ist Unraid auch ein wirklich tauglicher Docker Host und QEMU KVM Virtualisierer, im "App Store" (kostenfrei) gibt es tonnenweise für Unraid hergerichtete Pakete von quasi allem was man sich vorstellen kann.

Ja, der Speichergerätetreiber ist das Herzstück und ja, das ist spezifisch, aber auch ziemlich genial. Im Endeffekt liegt ein File nur auf einer Platte - und die 1-2 Parity Platten sorgen dafür, dass diese Platte redundant abgesichert ist. Dadurch muss zum Lesen aber auch nur eine Platte (und nicht das ganze Array) hochgefahren werden, was die Sache extrem energieeffizient macht.

Auf https://unraid.net/blog/unraid-14th-birthday-blog wird gesprochen von: "‘cluster aware’ extension to ‘shfs’ - the Unraid User Share File System. User shares can span selected array devices and the cache pool."

Aber ein Speichergerätetreiber ist jetzt was, wo ich doch gerne etwas sehr verlässliches haben möchte. Da möchte man wirklich eine Software haben, die in jeder möglichen oder total bescheuerten Situation die Datensicherheit gewährleistet.
Naja, da der Treiber die Basis der Firma darstellt, und seit vielen Jahren existiert und weiterentwickelt wird, sollte hier schon eine gewisse Stabilität existieren.

Ebenso sehe ich, wenn da z. B. eine neue Platte dazu kommt, dass dann die Parity vom Gesamtsystem - also üblicherweise 1-2 Parityplatten - neu berechnet werden muss. Da würde ich vermuten, dass ein Unraid-Storage in so einer Migrationsphase recht anfällig sein könnte, wenn gerade dann eine Platte ausfällt.
Nö. Man precleared eine Platte (d.h. nullt die) vorher (das dauert sehr lange), dann ist sie in einem definierten Zustand und kann dann sehr schnell in ein Array aufgenommen werden. In dieser Zeit sind die Daten immer noch redundant geschützt. Da Daten nur auf einer Platte lagern wären (selbst wenn nicht redundant gesichert) nur die Daten auf dieser einen Platte weg, nicht die Daten auf allen anderen Platten. Aber wie gesagt, das Problem existiert so nicht.

Und da sind dann auch meine Zweifel, ob solche closed-source Entwicklungen ebenso zuverlässig und robust gebaut sind. Auch persönliche Aussagen wie Na. Ich habe damit jetzt noch nie Probleme gehabt sorgen bei mir da jetzt nicht für so wirklich für die Auflösung dieser Zweifel.
Wie Du schon sagtest: sowas gibts aber als OSS nicht. Daher muss man entweder der Firma vertrauen, die es jetzt auch schon viele Jahre gibt, oder halt nicht.

Weiss da jemand, ob der Unraid-Treiber vom Hersteller(LimeTech) selbst programmiert wurde, oder ist das ein Treiber von irgend einem anderen vorhandenen Projekt?
Ist, wie oben erwähnt, anscheinend an shfs angelehnt.

Mit ausreichend viel Backup kann man da bestimmt schon mal einiges abfangen.
Redundanz schützt vor Backup nicht.

So dass bisschen, was ich bis jetzt zu Unraid ergoogelt habe macht aber insgesamt schon einen sehr soliden Eindruck.
Jo, ists. Allerdings gibt es auch Nachteile:
- Lizenz hängt an der ID und OS läuft vom USB Stick (wenn dieser kaputt geht, kann man einen neuen Stick von einem USB Backup, das man jederzeit machen kann wiederherstellen und die Lizenz auf diesen Stick umziehen).
- Kostet Geld - je mehr HDs im System umso mehr Geld. Die Lizenz hängt, wie gesagt, an der Stick ID.
- Das Funktionsprinzip des HD Treibers sorgt dafür, dass Leseraten (sofern die Daten nicht auf den Cache SSDs liegen) die Geschwindigkeit einer einzelnen Platte nicht übersteigen können (da die Daten nur auf dieser einen Platte liegen und nicht auf allen).
- Schreiben direkt aufs Array ist ziemlich langsam (ca 80 Mbytes/s), da hier die Parity berechnet werden muss. Daher ist ein SSD Cache eigentlich Pflicht, je größer umso besser.
- Die Benutzerverwaltung ist NUR auf "Home Use" ausgelegt, es gibt keine Gruppenverwaltung (!), nur einzelne User und auch keine Anbindungen an externe Userverwaltungen (LDAP, AD, etc.). Für ne Handvoll Nutzer zu Hause ok, für Firmen nicht geeignet.

Hat also Nachteile, aber die Vorteile eines sehr energieeffizienten NAS, eines guten Docker und KVM Hosts und tonnenweise Appunterstützung sind es m.E. für einen Homeserver wert.
 
Nö. Man precleared eine Platte (d.h. nullt die) vorher (das dauert sehr lange), dann ist sie in einem definierten Zustand und kann dann sehr schnell in ein Array aufgenommen werden. In dieser Zeit sind die Daten immer noch redundant geschützt. Da Daten nur auf einer Platte lagern wären (selbst wenn nicht redundant gesichert) nur die Daten auf dieser einen Platte weg, nicht die Daten auf allen anderen Platten. Aber wie gesagt, das Problem existiert so nicht.

D. h. eine genullte Platte ist bzgl. der Prüfsumme neutral, d. h. verändert die resultierende Prüfsumme nicht? (Anhand der Erklärung der einfachen Prüfsummenmethode scheint das so zu sein).

Redundanz schützt vor Backup nicht.

Ähem. Pardon? Meinst Du: Redundanz ersetzt kein Backup? Mein Punkt war: Wenn der Treiber doch unter bestimmten Bedingungen doch Datenkorruption erzeugen sollte, dann kann man mit vielen regelmässigen Backups evtl. noch auf saubere Datenbestände zurück greifen, wenn so etwas passieren sollte.

Kostet Geld - je mehr HDs im System umso mehr Geld. Die Lizenz hängt, wie gesagt, an der Stick ID.

Die Preise finde ich wirklich sehr human. Die Tatsache, dass das nach so vielen Jahren immer noch so ist, schafft da für mich schon Vertrauen.

Was ich mich ansonsten noch so Frage, ob die Prüfsummen auch tatsächlich in den Treiber integriert sind. D. h. dass bei jedem Lesen auch die Daten tatsächlich verifiziert werden oder ob dafür ein extra Prüflauf erforderlich ist. Evtl. müsste man hier dann als FS noch btrfs setzen, was das ja tut.
 
D. h. eine genullte Platte ist bzgl. der Prüfsumme neutral, d. h. verändert die resultierende Prüfsumme nicht? (Anhand der Erklärung der einfachen Prüfsummenmethode scheint das so zu sein).
Erklärung aus dem Unraid Forum:
"Unraid only requires a clear disk when you are adding it to a new slot in an array that already has valid parity. This is so parity will remain valid. A clear disk is all zeros, and all those zeros have no effect on the parity result.
If you don't preclear a disk when adding it to a new slot in an array with valid parity, then Unraid will clear it for you. So, preclear is never necessary.
Much older versions of Unraid would take the array offline when clearing a disk, so preclear was created to clear the disk before (pre) adding it to a new slot."


Eine Platte mit lauter Nullen verändert die Parity nicht (da ja nur eine 0 hinzukommt).
Man kann die Platte auch ohne Preclear hinzufügen, dann ist das Vorgehen eher ähnlich einem klassischen Raid Rebuild.

Um eine Platte hinzuzufügen, nimmt man das Array offline, fügt die Platte ein und schaltet das Array wieder online. Wenn die Platte precleared ist, ist das Array wieder da und fertig.

Ähem. Pardon? Meinst Du: Redundanz ersetzt kein Backup? Mein Punkt war: Wenn der Treiber doch unter bestimmten Bedingungen doch Datenkorruption erzeugen sollte, dann kann man mit vielen regelmässigen Backups evtl. noch auf saubere Datenbestände zurück greifen, wenn so etwas passieren sollte.
Ja, kurze Ausdrucksweise für "Redundanz macht Backup nicht überflüssig".

Das gilt ja immer und für jegliches System. Es gibt übrigens auch einen Parity Check, den man z.b. 1x im Monat zeitgesteuert laufen lassen kann. Da werden dann kaputte Bits o.ä., also Fehler die über den Check der Parität erkannt werden, korrigiert. Neben diesem Check kann man auch noch ein SSD TRIM regelmäßig laufen haben.
Die Preise finde ich wirklich sehr human. Die Tatsache, dass das nach so vielen Jahren immer noch so ist, schafft da für mich schon Vertrauen.
Jo, denke auch dass das ok ist. Was halt immer gilt (wie bei anderen Softwareprodukten auch): nimm nie eine X.X.0 Version, sondern frühestens die X.X.1. Das Forum ist sehr aktiv und Probleme werden sehr schnell erkannt und dort gepostet.

Was ich mich ansonsten noch so Frage, ob die Prüfsummen auch tatsächlich in den Treiber integriert sind. D. h. dass bei jedem Lesen auch die Daten tatsächlich verifiziert werden oder ob dafür ein extra Prüflauf erforderlich ist. Evtl. müsste man hier dann als FS noch btrfs setzen, was das ja tut.
Die Parity wird beim SCHREIBEN aufs Array natürlich geändert, insofern laufen da die eine Daten und die beiden Parity Platten (bei Redundanz von 2 Platten). Die Prüfsummen werden beim o.g. Parity Check (alle Festplatten laufen komplett durch) regelmäßig kontrolliert, meines Wissens NICHT beim Lesen (passiert das bei anderen Raids überhaupt?). BTRFS kann (neben anderen FS) pro Platte verwendet werden, auch verschlüsselt. Aufgrund der Funktionsweise können sogar unterschiedliche Dateisysteme auf den Platten eines Arrays verwendet werden (nicht unbedingt sinnvoll, aber wohl machbar).
 
Vorweg; selbst enterprise-grade Storage Auto-Tiering hat signifikante Nachteile und Schwächen, einfach weil genau wie bei Automatikkupplung das System die Bedürfnisse nicht vorhersagen kann. Alle offenen Lösungen stehen diesen kommerziellen Tierung-Lösungen zusätzlich sowohl in Stabilität als auch Funktion sehr weit hinterher.

Nun habe ich eine Idee und wüsste gerne ob sich das mit existierenden Cache Lösungen realisieren lässt. (bcache, lvmcache, enhanceIO. Gibt es eine vierte?)
Im Prinzip möchte ich verhindern dass die Festplatten (drehende) immer wieder anlaufen wenn eine große Datei mehrfach am Tag geöffnet wird
In dieser Form wird es mit den genannten Produkten nicht funktionieren. Ursache ist dass alle entweder als writeback oder writethrough cache funktionieren; sie ergänzen nicht deine Festplatte sondern halten eine Pufferkopie der Daten vor. Im Hintergrund wird trotzdem immer wieder Datenzugriff auf die Platte erfolgen.
Die Produkte sind ausschliesslich dafür gedacht um Zugriffe auf die Festplatte zu beschleunigen. EnhanceIO ist verbuggt und instabil, aber BCache ist durchaus in der Lage die Nachteile von HDD's in vielen Szenarien grösstenteils zu kaschieren.
 
Back
Top