Mischbetrieb Array HDD und SSD


Recommended Posts

11 hours ago, Smolo said:

Was wäre der Grund dafür? Die SSD wird nur für ein Share verwendet und durch die Parity gesichert.

Hieruz gibt es einige Threads im Forum (auch auf Deutsch). Trimmen ist nicht möglich und der damit hergende Geschindigkeits verlusst der SSDs wäre ein Grund.

  • Like 1
Link to comment
11 hours ago, sonic6 said:

Hieruz gibt es einige Threads im Forum (auch auf Deutsch). Trimmen ist nicht möglich und der damit hergende Geschindigkeits verlusst der SSDs wäre ein Grund.

Danke für die Info, ich nehme das aktuell in Kauf da die Platte als ein reines Foto Datengrab genutzt wird. Crucial schreibt dazu als Beispiel übrigens "Alle SSDs von Crucial werden unter der Annahme entwickelt und getestet, dass sie ohne Trim verwendet werden. "

Link to comment

Geht es bei der SSD Geschichte nicht um Geschwindigkeiten (man Bremst die SSD beim schreiben aus, wozu ja der Cache da wäre) und der Stärkeren Belastung, sogar Probleme mit der Parity?

Es macht halt eigentlich keinen Sinn ein Array im "Mischbetrieb" zu fahren.

Link to comment
38 minutes ago, sonic6 said:

Es macht halt eigentlich keinen Sinn ein Array im "Mischbetrieb" zu fahren.

Ich werde das auch machen, weil für eine SSD als Parity hab ich schlicht keine Kohle (ich bräuchte größer als 18TB). Die SSD im Array liefert schnell (keine Spinup Wartezeit) und effizient die Dateien und beim Schreiben fängt wie gehabt der Cache ab. Auf die SSD im Array packe ich ja keine VM. Und fehlendes Trim ist beim reinen Lesen ja eh Wurst.

  • Like 1
Link to comment
2 hours ago, sonic6 said:

Sollte man vielleicht nen extra Thread zu aufmachen, aber geht es bei der SSD Geschichte nicht um Geschwindigkeiten (man Bremst die SSD beim schreiben aus, wozu ja der Cache da wäre) und der Stärkeren Belastung, sogar Probleme mit der Parity?

Es macht halt eigentlich keinen Sinn ein Array im "Mischbetrieb" zu fahren.

Sinn insofern das du für das reine Lesen von spezifischen Massendaten keinen Spinup von deinem kompletten Array hast. Bei 2TB Fotodaten die du z.B. an der Wand durchlaufen lassen willst verlierst du sonst jeden Vorteil von Unraid. Das gute ist ja das Unraid dir dafür ja die perfekte Möglichkeit bietet 🙂

Link to comment

Ich habe mich eher hierdrauf bezogen: 

Da gilt es ja schon ein wenig mehr zu beachten, als nur das Trimmen der SSD im Array.

Ihr sprecht von "sicheren Daten". Das Thema wirkt auf mich aber weitaus komplexer.

 

6 minutes ago, Smolo said:

Sinn insofern das du für das reine Lesen von spezifischen Massendaten keinen Spinup von deinem kompletten Array hast.

Ich weiß nicht wie dein Array konfiguriert ist, aber da scheint was nicht zu stimmen. Wenn ich Daten lese, wird nur die Platte angesprochen/hochgefahren, auf der auch die Daten liegen. Niemals das komplette Array.

 

Für den Fall des "schnellen" und "gesicherten" Datenzugriff gibt es doch die Pools mit btrfs-raid1 und "cache-prefer"?

 

Nein, ich sehe schon ein, dass da ein Gedanke hinter steckt und man verschiedene Vorgehensweisen hat, aber für mich "beißt" sich die "Aussage von limetech" und "sichere Daten" in einem Kontext.

Für mgutt sollte das alles kein Problem darstellen, aber nicht-so-erfahrene Nutzer sind dann 2 Monate später im Forum und haben Panik weil ihre Daten korrupt sind. Sehe ich schwierig.

Link to comment
52 minutes ago, mgutt said:

Die SSD im Array

Und was ist wenn die SSD intern Trim macht bzw gewisse routinen am Controller zum "aufräumen" drauf hat?

Dann stimmt bei jedem Parity check die Parität nicht, nur so als denkanstoß.

 

Natürlich ist es auch möglich das nichts passiert aber ich würd das nicht per se "empfehlen", wird auch von Limetech nicht empfohlen das so zu machen.

Link to comment
13 minutes ago, sonic6 said:

Ich habe mich eher hierdrauf bezogen: 

Die Jungs bei Limetech haben irgendwann mal eine SSD in der Hand gehabt, die nach einem Trim die Parity kaputt gemacht hat. Danach wurde Trim deaktiviert und parallel gesagt, dass SSDs nicht im Array empfohlen sind. Sie haben also den Workaround geliefert und von der Nutzung abgeraten, was einfach keinen Sinn macht. Es gab bisher auch keine Bemühungen eine Allow- oder Blockliste von trimfähigen SSDs aufzubauen. Es wäre sogar ohne weiteres automatisiert testbar. Stattdessen verweist man auf das müllige BTRFS, was regelmäßig über den Jordan geht, wenn der Server crasht oder der Strom ausfällt. Davon abgesehen habe ich Null davon, wenn ich 5 SSDs im RAID Dauerlauf habe. Das sind ja auch wieder 20W für nothing.

 

Ach ja. Ich habe schon zig SSD only Server gebaut. Allerdings alle mit Enterprise SSDs, die alle problemlos ohne Trim klar kommen. Und mich hat da noch kein Kunde angerufen, dass seine Parity kaputt sei. Ich erwarte bei Samsung und WD allerdings auch keine Probleme bei Consumer SSDs. Mehr dazu, wenn ich es getestet habe.

 

 

Link to comment
5 minutes ago, ich777 said:

Und was ist wenn die SSD intern Trim macht bzw gewisse routinen am Controller zum "aufräumen" drauf hat?

Dann stimmt bei jedem Parity check die Parität nicht, nur so als denkanstoß.

Eine SSD kann intern kein Trim. Und die Garbage Collection verändert keine Daten. Sie fasst Daten nur in andere Pages zusammen um freie Pages zu schaffen.

 

Das Problem ist einzig RZAT und DZAT. Siehe auch hier:

https://forums.unraid.net/topic/73110-ssd-array-for-unraid/?do=findComment&comment=923680

 

 

Und das ist wie gesagt ausschließlich ein Problem, wenn man Trim ausführt. Ohne Trim geht die Parity nicht kaputt.

Link to comment
  • mgutt changed the title to Mischbetrieb Array HDD und SSD
38 minutes ago, mgutt said:

Und das ist wie gesagt ausschließlich ein Problem, wenn man Trim ausführt. Ohne Trim geht die Parity nicht kaputt.

Das würde ich so nicht unterschreiben.

 

Wie gesagt, du kannst es gerne empfehlen aber ich würd das nicht.

Es heißt nicht das wenn es bei dir funktioniert das es bei jemand anders funktioniert, auch wenn derjenige die gleich SSD verwendet (Firmware, Revision usw).

 

Nicht jede SSD verhält sich gleich.

Link to comment
32 minutes ago, ich777 said:

Das würde ich so nicht unterschreiben.

Informiere dich was Trim macht und was die Garbage Collection macht. Wenn die GC Daten verändern würde, würde das ja heißen, dass sie einfach deine Dateien ändert. Das glaubst du dich nicht ernsthaft? Befrei dich mal vom Gedanken, dass eine SSD weiß welche Sektoren zu welcher Datei gehören. Das weiß sie nämlich nicht (deswegen gibt es ja überhaupt Trim). Es gibt zig verschiedene Dateisysteme, mit unterschiedlichen Versionen und RAID Varianten. Die kann eine SSD nicht kennen. Die kennt nur Sektoren.

 

Erst durch Trim erfährt die SSD welche Sektoren nicht mehr verwendet werden. Und erhält sie diesen Trim Befehl, dann verändert sie diese Sektoren in Nullen (RZAT) oder lässt die Daten wie sie sind (DZAT). In beiden Fällen werden die Pages für GC zum Aufräumen freigegeben.

 

Allerdings steht bei DZAT "shall" im Standard. Es kann also leider von Hersteller zu Hersteller unterschiedlich sein, was dann wirklich passiert.

 

Außerdem darf man nicht vergessen, dass diese Änderung nur auf dieser einen SSD passiert. Die Parity erfährt davon also nichts und wird nicht angepasst = kaputt.

 

DZAT wäre daher optimal für unRAID, weil die Sektoren nach wie vor die selben Daten zurückliefern = Parität bleibt valide. Aber genau das müsste man wegen dem "shall" je nach SSD erstmal testen.

 

dlandon schlug dagegen vor nur RZAT SSDs zu erlauben, aber genau das resultiert in dem Problem, dass man gar nicht weiß was die SSD nun alles genullt hat (sie gibt ja nicht die geänderten Sektoren zurück). Also wäre man gezwungen die Parity zu reparieren = macht keinen Sinn für unRAID, weil die Parität nach jedem Trim repariert werden müsste.

 

Daher drehte ich mich mit Limetech in dem Punkt im Kreis. Und ich sage nach wie vor, dass DZAT die einzige Lösung ist, aber da müsste man eben mit einer Allowliste an SSDs arbeiten.

 

Oder man lässt eben Trim weg, wie es bereits der Fall ist. Nur dann spreche ich mich ja nicht gegen SSDs aus. Ich mein welchen Sinn hat das. Man kann SSDs im Array zuordnen, es gibt extra die Deaktivierung von Trim, aber eigentlich sind SSDs gar nicht erlaubt. Sorry, aber dann bitte konsequent keine SSDs im Array erlauben.

Link to comment
24 minutes ago, mgutt said:

Informiere dich was Trim macht und was die Garbage Collection macht. Wenn die GC Daten verändern würde, würde das ja heißen, dass sie einfach deine Dateien ändert. Das glaubst du dich nicht ernsthaft?

Wie oft denn noch, ICH würde das nicht empfehlen.

 

EDIT: Nach nochmaligem lesen deines letzten Posts hab ich genug Gründe es nicht zu machen. :)

Link to comment
2 hours ago, ich777 said:

Nach nochmaligem lesen deines letzten Posts hab ich genug Gründe es nicht zu machen. :)

Dann muss ich mich irgendwie falsch ausdrücken.

 

Also ich fasse noch mal alles Wichtige zusammen:

 

Offizielle Aussage von Limetech:

https://forums.unraid.net/topic/53433-ssds-as-array-drives-question/?tab=comments#comment-522482

Quote

it should work to use SSD's in an unRaid P or P+Q array if TRIM is not used.  This is current behavior. 

 

übersetzt:

Quote

SSD sollten im Array funktionieren, solange kein Trim genutzt wird, was aktuell das Standardverhalten ist.

 

Ja sie haben "sollten" geschrieben. Also schauen wir mal welche User Probleme mit SSDs im Array haben. Bis heute kenne ich nur eine Meldung. Und die ist von JorgeB:

https://forums.unraid.net/topic/82620-all-ssd-unraid-pool/?tab=comments#comment-767384

Quote

I tested a number of different SSDs in the past and all but one worked fine ... the exception was the Kingston V300, if the server was shutdown for a couple of hours there would always be 2 or 3 sync errors on a parity sync

 

übersetzt:

Quote

Ich habe in der Vergangenheit einige unterschiedliche SSDs getestet und alle bis auf eine waren in Ordnung. Die Ausnahme war die Kingston V300, die nach dem Herunterfahren des Servers immer zu 2 bis 3 Parityfehlern führte.

 

Die Kingston V300 ist übrigens eine SSD, die bekannt für Freezes und RAID-Problemen ist.

 

Ich habe ihn dann mal gefragt ob er noch andere Fälle kennt und er macht wohlgemerkt seit vielen Jahren hier im Forum Support für Unraid:

https://forums.unraid.net/topic/47266-plugin-ca-fix-common-problems/?do=findComment&comment=947567

Quote
Quote

Are there any other reports?

Not that I'm aware of.

 

Er kennt also keinen anderen Fall und bei seinem Erlebnis mit der Kingston V300 wurde die Parität nicht mal im Betrieb verändert, sondern als sie vom Strom getrennt wurde, was logischerweise nichts mit Trim oder GC zu tun haben kann.

 

Vielleicht sollten wir wegen möglicher Korruption auch vor SMR HDDs im Array warnen. Die nutzen nämlich auch alle GC.

Link to comment
16 minutes ago, mgutt said:

Ja sie haben "sollten" geschrieben. Also schauen wir mal welche User Probleme mit SSDs im Array haben. Bis heute kenne ich nur eine Meldung

Sorry ich glaub ich muss mich mal klar ausdrücken:

Wer gibt support wenn mal was nicht funktioniert?

Limetech nicht, da werden die User nur zurück bekommen das SSDs im Array nicht supported werden.

Auch wenn du support gibst was ist wenn du mal nicht hier bist/sein kannst?

 

Ändert nichts daran das ich wie schon oben geschrieben ICH es nicht empfehlen werde, solange es offiziell nicht supported wird.

Link to comment

vielleicht sollten wir es jetzt auch lassen ;)

 

geht es technisch, ja

kann es Probleme geben, ja

- welche, sind ja ausgiebig angesprochen worden ...

 

was ist eine "Falle", Trim ... wurde angesprochen, muss jeder für sich entscheiden was er macht ;)

anscheinend ist das keine Falle da im array kein Trim erfolgen kann, Hinweis zu Trim unten lass ich trotzdem mal generell als Info stehen.

 

Hinweis hierzu, nutzt man die generelle Trim Funktion (ich denke wir alle empfehlen dies bei SSD/nvme cache's) ... werden ja in der Regel alle Platten trimmed ...

sprich, hier dann besser "manuell" trimmen bzw. gezieltes script schreiben was zu einem passt.

 

image.png.e177a508f2001c301785970f9ca87a5a.png

Link to comment
13 minutes ago, saber1 said:

Sollte das seit 6.9 nicht weggefallen sein, und vom OS automatisch gemacht werden..? 🤔

 

nicht das ich wüsste

 

seit 6.9 wurde das Thema bei BTRFS Pools umgestellt dass da kein Trim mehr notwendig ist.

 

bei XFS formatierten Platten ist Trim nach wie vor sinnvoll, daher auch das plugin ... so zumindest mein Kenntnisstand ;)

  • Like 1
Link to comment
1 hour ago, ich777 said:

Wer gibt support wenn mal was nicht funktioniert?

Seit wann gibt es Support auf Datenintegrität? Ich kann mich auch nicht erinnern, dass Limetech bei kaputten BTRFS RAIDs den Kopf hinhält. Und das hatten wir ja nun schon oft genug.

 

1 hour ago, ich777 said:

solange es offiziell nicht supported wird.

Wie genau darf man das denn interpretieren, dass SSDs dem Array zugewiesen werden können, Trim deswegen deaktiviert wurde und es keine Warnung gibt?

 

Squid, der nicht Limetech ist, warnt übrigens über CFP, weil JorgeB mit der, ich sage jetzt bewusst, defekten V300 das Problem hatte. Andere Fälle kennt der auch nicht.

Link to comment

Ich sehe das wie mgutt denn ein Support existiert so oder so nicht und solange es nicht verboten ist bzw. funktioniert eine SSD reinzuhängen sehe ich das weniger problematisch an.

 

Der Kollege hier hat auch mal Speed Tests mit SSD als Partiy und SSD Array Only durchgeführt aber er hat leider nichts weiter zum Trim Thema gesagt entweder aus Unwissenheit oder weil es kein Thema ist?

SSD Parity vs HDD Parity vs SSD Array in Unraid — SPX Labs

Video dazu

SSD Parity vs SSD Array in Unraid - YouTube

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.